<div dir="ltr">I was literally having this exact same discussion with Ilari today, and even started describing OPTLS as "Noise for TLS" until Ilari explained to me what you discovered, and now I kind of feel like it's the worst of both worlds.</div><div class="gmail_extra"> <div class="gmail_quote">On Tue, Mar 24, 2015 at 11:05 PM, Trevor Perrin <<a href="mailto:trevp@trevp.net" target="_blank">trevp@trevp.net</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I took a closer look at TLS 1.3, to see how it might translate to Noise. It's still largely in flux. But the OPTLS proposal [1] is very similar to a Noise pipe or HandshakeNX (HandshakeXX with client auth) [2]: HandshakeNX(): -> e <- e, dhee, s, dhse HandshakeXX(s): -> e <- e, dhee, s, dhse -> s, dhse IETF discussion of that focused on the case where [3]: (a) the server's long-term key is already a signing key (b) it's stored in an HSM that doesn't support DH keys (c) time sync doesn't exist (a) and (b) preclude using the long-term key as s above. (b) precludes the solution of signing s with the signing key since s would then have all the power of the signing key, but is stored less securely. (c) precludes limiting that risk with signature expiry. Meeting those constraints require signatures over the entire handshake, which loses some deniability: -> e <- e, dhee, long-term key, sign-everything For some reason the IETF is trying to combine this with OPTLS [4]: -> e <- e, dhee, s, dhse, long-term key, sign-everything Where s is a "semi-static" key for a subsequent 0-RTT handshake. Am I missing something, or is that ugly and missing the point of OPTLS? (which was to accomplish a DH-only key agreement, for savings in bandwidth, deniability, and implementation simplicity): - If the server doesn't support the semi-static key, it sets s=e to skip the dhse calculation (but then transmitting s is pointless) - If the server *does* support the semi-static key, then dhse is performed but is pointless, as the connection is already authenticated by the signature, and forward-secrecy is already provided by dhee Anyways, Noise doesn't have the HSM-back-compatibility concerns that are apparently steering them to signatures. So a system using Noise could easily have the server send an optional semi-static public-key in the payload of a HandshakeNX, and then the client could use that for a 0-RTT BoxNS: -> e, dhes Trevor [1] <a href="https://www.ietf.org/mail-archive/web/tls/current/msg14385.html" target="_blank">https://www.ietf.org/mail-archive/web/tls/current/msg14385.html</a> [2] <a href="https://github.com/trevp/noise/blob/noise2/noise.md" target="_blank">https://github.com/trevp/noise/blob/noise2/noise.md</a> [3] <a href="https://www.ietf.org/mail-archive/web/tls/current/msg14494.html" target="_blank">https://www.ietf.org/mail-archive/web/tls/current/msg14494.html</a> [4] <a href="https://www.ietf.org/mail-archive/web/tls/current/msg15621.html" target="_blank">https://www.ietf.org/mail-archive/web/tls/current/msg15621.html</a> _______________________________________________ Noise mailing list <a href="mailto:Noise@moderncrypto.org">Noise@moderncrypto.org</a> <a href="https://moderncrypto.org/mailman/listinfo/noise" target="_blank">https://moderncrypto.org/mailman/listinfo/noise</a> </blockquote></div> <div> </div>-- <div class="gmail_signature">Tony Arcieri </div> </div>