<div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 30, 2016 at 1:37 AM, Trevor Perrin <span dir="ltr"><<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The spec mentions a "length field" and a "type field" which you could<br>
use for some minimal framing.  Basically, before each handshake<br>
message, you could include:<br>
 - 1-byte type (zero by default)<br>
 - 2-byte length<br>
[...]<br></blockquote></div><br></div><div class="gmail_extra">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.<br><br></div><div class="gmail_extra">There are lots of issues to define a practical and interoperable protocol:<br><br></div><div class="gmail_extra">- Packet framing<br></div>- 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.<br></div>- Negotiating the handshake pattern / features?  And then incorporating this negotiation into the prologue.<br><div><div><div class="gmail_extra">- 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.<br></div><div class="gmail_extra">- Key management.  e.g. Does the static key belong to the hostname or the (hostname, service) combination or something else?<br></div><div class="gmail_extra">- A standard place in the protocol to place client and server certificate information if the service needs it.<br></div><div class="gmail_extra"><br></div><div class="gmail_extra">(*) 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.<br><br></div><div class="gmail_extra">Cheers,<br><br></div><div class="gmail_extra">Rhys.<br><br></div></div></div></div>