[noise] Explicit nonces (for lossy transports)

[Trevor Perrin]

This is an interesting thread because Jason and Dan wrote thoughtful
emails that seem (to me, at least) quite opposed:

https://moderncrypto.org/mail-archive/noise/2017/001101.html

https://moderncrypto.org/mail-archive/noise/2017/001121.html

Jason argued that once you step outside TCP (or an ordered, lossless
transport) the requirements become so specific to use cases that we
shouldn't try building anything to help there, beyond allowing
explicit / unordered nonces.

Dan I think argues that it would be better if there was a general
crypto layer handling unordered, lossy connections, with everything
else built on top of that.

It would be great if there was some synthesis of those arguments that
pointed to practical projects we could work on.


Here's a few non-TCP Internet crypto cases we could think about:

 * DNS is a good example of a UDP protocol with proposals for adding
crypto in different ways (DNSCrypt, DNSCurve, the recent DPRIVE effort
for DNS over TLS/TCP, DNSSEC).

 * WebRTC has historically supported different crypto handshakes, with
DTLS the current recommended choice.

 * Google's QUIC is intended to replace TLS/TCP for HTTP, I think.
Originally it had its own crypto, but has become an IETF effort using
the TLS 1.3 handshake, then "exporting" keys from TLS and using them
with QUIC's own "Packet Protection" crypto [1,2].  The coupling with
TLS handshake is thus fairly loose.  From the QUIC transport spec,
7.2:
"""
Version 0x00000001 of QUIC uses TLS 1.3 as described in [QUIC-TLS]; a
different QUIC version number could indicate that a different
cryptographic handshake protocol is in use.  QUIC provides this stream
with reliable, ordered delivery of data.
"""

 * There are various efforts at improving network time sync (e.g. NTS,
roughtime, tlsdate).


Trevor


[1] https://datatracker.ietf.org/doc/draft-ietf-quic-transport/?include_text=1
[2] https://datatracker.ietf.org/doc/draft-ietf-quic-tls/?include_text=1



On Sat, Jun 17, 2017 at 11:22 AM, D. J. Bernstein <djb at cr.yp.to> wrote:
> There's a long history of turning HTTP-over-TCP and XYZZY-over-TCP into
> HTTP-over-crypto-over-TCP (HTTPS) and XYZZY-over-crypto-over-TCP and so
> on. From a software-engineering perspective, what has made this not too
> painful to implement is that crypto-over-TCP fits into essentially the
> same interfaces as TCP:
[...]