[noise] TLS 1.3

[Trevor Perrin]

On Wed, Mar 25, 2015 at 1:20 AM, Tony Arcieri <bascule at gmail.com> wrote:
> 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.

It was cool originally, I've chatted w/Hugo and Hoeteck at different
times, they're going down a similar path as us.

I just don't see why you'd bolt it on top of a "traditional"
signature-based key agreement, it made sense as an alternative, not an
addition.

This is the problem with a one-size-fits-all design.  They can't do
"real" OPTLS because of weird back-compat constraints.  But a lot of
cases don't have those constraints, but would still have to live with
a protocol designed around them.  Whereas a more modular approach can
give you more tailored protocols...

Trevor

>
> 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