[noise] Practical safety of the spec's SetNonce API

[Luke Mather]

Hi Trevor,

> So we could have a "DatagramCipherState" object (or "RawCipherState"?
> "AEADState"?) that holds a key without a nonce.
> 
> Then we could move nonce handling into the higher-level objects.  Or
> we could keep a CipherState but have it store an AEADState alongside a
> nonce and do default nonce handling.  Then in the "Out-of-order"
> discussion, we could mention that applications are allowed to discard
> the CipherState and access the underlying AEADState.
> 
> I think I'd lean towards keeping the CipherState API as-is to minimize
> changes and because it's convenient to deal with a CipherState for
> both handshake and transport phases, but just add a lower-level
> object?

We could define two goals here:
1. Reducing the risk of misuse of Noise libraries;
2. Align the core spec with the requirements of layering on top of a
lossy transport.

W.r.t 1: as I said in previous email, personally I don't think
accidental misuse of setNonce() is a huge concern. Better off promoting
'safe' APIs at a higher level. A small win could be to rename the method
'overrideNonce()' to try to warn people away from it?  Or (for the
library) to provide an additional encapsulation of the two CipherStates
used for post-handshake messaging.

W.r.t 2: Ultimately the majority of the work you'd need to do to safely
layer Noise over a lossy transport is going to be specific to the
application, so I don't think the spec should try to do anything other
than the bare minimum of not getting in the way.

The separation of responsibilities of nonce and key management between a
CipherState sans setNonce() and a lower-level AEADState does feel cosily
clean.  A Noise 'cipher function' is quite close to an AEADState already
--- I haven't checked, but I imagine most Noise libraries will have
effectively created stateful cipher contexts with InitializeKey()-esque
methods to handle things like key scheduling, for instance.

We could try to formalise that, move CipherState#InitializeKey() etc
over to it, see if reducing CipherState to nonce management only doesn't
have any unexpected consequences, and say users can override or replace
its functionality under the existing nonce constraints.  It's a bit
cleaner, as setNonce() is effectively fighting against the existing
post-incrementing of nonces -- but the benefit is I think pretty small
given the extent of the changes.

Cheers,

Luke


-- 
Luke Mather
----------------------------------------------
Cerberus Security Laboratories Ltd.
Office:  +44 (0)117 214 1366 (Direct)
Web:     www.cerberus-laboratories.com
Twitter: @cerberuslabs

Cerberus Security Laboratories is a company registered in England &
Wales, Registered number: 10444272.
Registered Office: Woodlands Grange, Woodlands Lane, Bradley Stoke,
Bristol BS32 4JY. United Kingdom