Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN)

From: Peter Gutmann <[email-masked]>
Date: Sat, 16 Mar 2013 01:48:57 +0000

Russ Housley <[email-masked]> writes:

>I'd prefer a solution that is architected with this goal in addition to the
>original goals of SSL/TLS.  I'm concerned that an extension to TLS 1.2 will
>be an improvement, but it will be far short of a handshake that was
>structured to that set of goals.

My objection is somewhat similar, at the moment ALPN is a one-off kludge (as
is NPN).  The next time we want to do something like this, we'll have to add
another one-off kludge.  And then another.  And another.  Asking the list to
choose between kludge #1 and kludge #2 is kind of misleading when there are
better ways to do this.  I'd really prefer to have some sort of general post-
handshake extension mechanism that can be used, like the existing pre-
handshake extensions, to add all the capabilities that people will dream up in
the future.  Then ALPN just becomes a newly-defined extension, and new
capabilities can be easily added by defining a new extension type.

Peter.

---

From: Andrei Popov <[email-masked]>
Date: Sat, 16 Mar 2013 02:32:59 +0000

I don't think ALPN or NPN should be general extension mechanisms. Instead we can define a general mechanism for TLS handshake confidentiality (which would also cover ALPN).

Cheers,

Andrei

Sent from my Windows Phone
________________________________
From: Peter Gutmann
Sent: 3/15/2013 8:49 PM
To: [email-masked]
Subject: Re: [TLS] The consensus is half-mistaken (Re: Confirming consensus for ALPN)

Peter.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Tom Ritter <[email-masked]>
Date: Sat, 16 Mar 2013 11:47:36 -0400

> capabilities can be easily added by defining a new extension type.

I register my agreement.

-tom

---

From: [email-masked] (Martin Rex)
Date: Thu, 21 Mar 2013 00:54:01 +0100 (CET)

> capabilities can be easily added by defining a new extension type.

You mean something like a TLS protected extensions handshake message
that is inserted between the CCS and the Finished handshake message
on both directions, becoming the first protected message and still
being covered/authenticated by the handshake message hash?

Only for the initial aka "full" TLS handshake (because on the
abbreviated aka "session resume" handshake, the sequence of the
CCS&Finished is reversed, i.e. the Server sends the first Finished
handshake message and the Client confirms it), or on both handshake types?

Or are you thinking of exchanging protected extensions _after_ the
Finished handshake message(s)?

-Martin

PS: Different to Nico, I strongly prefer to keep handshake message types
clearly recognizable in the cleartext part of the TLS record protocol,
including renegotiation.  I do *not* see this as a problem. I'm actively
using that data for preprocessing incoming SSL records on my network
wrapper for non-blocking operation, because having to dive through the
entire TLS protocol engine for record reassembly is ugly, complex and
a significant waste of resources.

Btw., I'm not a fan of client-side SSL proxies that MitM HTTPS with
fake server certs.  I wished, that such activities would be a felony
criminal offense in more countries than just in Germany.  And yes,
this is undoubtely illegal in Germany for employers doing that on
HTTPS traffic of employees, no matter what some clueless lawyers claim.