[noise] TLS 1.3

[Tony Arcieri]

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.

On Tue, Mar 24, 2015 at 11:05 PM, Trevor Perrin <trevp at trevp.net> wrote:

> 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] https://www.ietf.org/mail-archive/web/tls/current/msg14385.html
> [2] https://github.com/trevp/noise/blob/noise2/noise.md
> [3] https://www.ietf.org/mail-archive/web/tls/current/msg14494.html
> [4] https://www.ietf.org/mail-archive/web/tls/current/msg15621.html
> _______________________________________________
> Noise mailing list
> Noise at moderncrypto.org
> https://moderncrypto.org/mailman/listinfo/noise
>



-- 
Tony Arcieri
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/noise/attachments/20150325/511779a6/attachment.html>