[noise] Replacing TLS with noise

[Rhys Weatherley]

On Fri, Dec 30, 2016 at 1:37 AM, Trevor Perrin <trevp at trevp.net> wrote:

> The spec mentions a "length field" and a "type field" which you could
> use for some minimal framing.  Basically, before each handshake
> message, you could include:
>  - 1-byte type (zero by default)
>  - 2-byte length
> [...]
>

I think it may be worth defining an extension for a full "transparent
socket-like layer using Noise" as this "how do I do TLS?" question will
keep coming up.

There are lots of issues to define a practical and interoperable protocol:

- Packet framing
- Choice of handshake patterns.  XX and Noise Pipes are obvious.  However
the way TLS is often used is more akin to NX than XX - no client auth.  Are
null public keys enough to turn XX into NX or do we need more packet
types?  NN may also be needed for fully anonymous connections with
opportunistic encryption.
- Negotiating the handshake pattern / features?  And then incorporating
this negotiation into the prologue.
- Triggering re-negotiation of session keys after a significantly large
amount of data has been sent (e.g. 1Gb), or after a certain amount of time
(e.g. 1hr) has elapsed (*).  This is tricky to do right with asynchronous
communications in both directions.
- Key management.  e.g. Does the static key belong to the hostname or the
(hostname, service) combination or something else?
- A standard place in the protocol to place client and server certificate
information if the service needs it.

(*) is an application for resumption keys: e.g. re-negotiation triggers a
new NoisePSK_NN handshake with the PSK/resumption key derived from the
previous handshake/session on the underlying transport.  Resumption keys is
the one remaining feature we need in the core specification to support this.

Cheers,

Rhys.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20161230/eba23b01/attachment.html>