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

[Luke Mather]

Agree that ultimately it's a question of how prescriptive the
specification wants to be about the API contract a library for 'core'
Noise should provide, and whether the core specification eventually
wants to describe a complete description of how to safely overlay _any_
Noise protocol over a lossy transport.

It feels simpler (and safer -- the CipherState inferface is quite a
low-level one to expose) to me to push that responsibility up to
individual higher-level protocol definitions (e.g. a
"NoiseDatagramSocket") than to further complicate the core spec.

If library safety is a concern, ultimately there's still going to be a
reasonable amount of risk associated with someone inexperienced directly
designing against the core of Noise.  IMO it is better to promote safe
implementations of higher-level protocols that are built around the core.

That said, there are some alignment issues if such a higher-level
protocol wanted to directly develop against the explicit method
signatures as defined in the core spec right now. Maybe something like a
separate `DatagramCipherState` (or better named!) interface to use, as
well as the subsequent modifications to the SymmetricState and
HandshakeState interfaces you'd have to make to pass through nonce values.

Luke

On 02/08/2018 20:03, Justin Cormack wrote:
> The spec is not necessarily directly an API specification, it is a
> specification of the protocol, so
> you are not required to expose it exactly as an API.
> 
> I do think that the spec could maybe say that you either provide
> EncryptWithAd() or
> EncryptWithAdAndNonce() but not both at the same time, and remove SetNonce.
> That would remove opportunities to mix them. Implementations that set nonces are
> probably much less generic. It seems a nicer interface than set,
> making it explicit if
> you are setting nonces that you always need to.
> 
> Justin
> 
> 
> On 2 August 2018 at 19:06, jake mcginty <me at jake.su> wrote:
>> The upcoming release of Snow is planning to drop the SetNonce-style API because, in my opinion, it feels too enabling for people practicing Unsafe Noncing®:
>>
>>     session.set_receiving_nonce(nonce)
>>     session.read_message(...)
>>
>> will instead become:
>>
>>     session.read_message_with_nonce(nonce, ...)
>>
>> and the user will be required upon finishing the handshake to choose a transport mode with either explicit or implicit nonces to prevent some footgunning: session.into_transport_mode() or session.into_stateless_transport_mode().
>>
>> I'd obviously like to keep from unnecessarily diverging from spec API, so I thought this would be a good opportunity to float this type of change for the main noise spec as well. Something like:
>>
>> * Remove SetNonce(nonce) from CipherState
>> * Add {Encrypt,Decrypt}WithAdAndNonce(nonce, ad, plaintext) (but that's a very long-winded method name)
>>
>> Thoughts?
>> _______________________________________________
>> Noise mailing list
>> Noise at moderncrypto.org
>> https://moderncrypto.org/mailman/listinfo/noise
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
> 

-- 
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