Subject: Re: [TLS] Next Protocol Negotiation 03

From: Adam Langley <[email-masked]>
Date: Mon, 21 May 2012 17:36:10 -0400

On Thu, Apr 26, 2012 at 1:29 PM, Adam Langley <[email-masked]> wrote
> So, in short, "still thinking".

I've respun the draft in order to change the NextProtocol message into
an EncryptedExtensions message which has the same format as the
extension block in the hello messages. Everything else is the same.

This allows the client's protocol selection to remain under
encryption. The server's list of protocols is still in the clear, but
that can be fixed via an orthogonal change like Marsh's encrypted
handshake.

https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-04

Cheers

AGL

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 May 2012 17:57:21 -0500

On 05/21/2012 04:36 PM, Adam Langley wrote:
> On Thu, Apr 26, 2012 at 1:29 PM, Adam Langley<[email-masked]>  wrote

That's seems like a cleaner version of the same approach. Now we can 
drop the parenthesis in "NP(N)"!

If it's intended to be usable by more than just NPN, perhaps it should 
be described in a separate document?

It does seem to raise the same discussion about resistance to active 
mischief that we've been going over for 
draft-ray-tls-encrypted-handshake and 
draft-mavrogiannopoulos-tls-server-key-exchage. It would be really nice 
to get these considerations addressed in one or some small set of docs.

- Marsh

---

From: Wan-Teh Chang <[email-masked]>
Date: Mon, 21 May 2012 17:12:58 -0700

On Mon, May 21, 2012 at 3:57 PM, Marsh Ray <[email-masked]> wrote:
> That's seems like a cleaner version of the same approach.

Yes.  The EncryptedExtensions handshake message can also be used by
other extensions that are negotiated in a three-step, half-encrypted
manner.  It avoids a proliferation of new handshake messages for these
extensions and the need to specify an order between them.

> Now we can drop the parenthesis in "NP(N)"!

Could you explain the different between "NPN" and "NP(N)"?  Thanks.

> If it's intended to be usable by more than just NPN, perhaps it should be
> described in a separate document?

I agree.

Wan-Teh

---

From: Marsh Ray <[email-masked]>
Date: Mon, 21 May 2012 20:31:15 -0500

On 05/21/2012 07:12 PM, Wan-Teh Chang wrote:
> On Mon, May 21, 2012 at 3:57 PM, Marsh Ray<[email-masked]>  wrote:
>

It's a trivial thing but the extension is Next Protocol Negotiation and 
the former handshake message was Next Protocol. The proposal had also 
switched between those names at one point.

>> described in a separate document?

It's a shame that RFC 4680 'TLS Handshake Message for Supplemental Data' 
couldn't be used for this, it even has a 2 byte 'type' enum which could 
perhaps map easily to extension types. But its RFC is quite specific 
about its position in the handshake. Perhaps something of it can be 
built upon.

- Marsh

---

From: Wan-Teh Chang <[email-masked]>
Date: Tue, 22 May 2012 10:47:46 -0700

On Mon, May 21, 2012 at 6:31 PM, Marsh Ray <[email-masked]> wrote:
> perhaps map easily to extension types. But its RFC is quite specific about
> its position in the handshake. Perhaps something of it can be built upon.

I'm wondering why you're interested in using the SupplementalData
handshake message.  SupplementalData is sent immediately before the
Certificate handshake message, so it is not encrypted in the initial
handshake.  It cannot replace the proposed EncryptedExtensions
handshake message without amending RFC 4680.

Wan-Teh

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 May 2012 19:57:18 +0200 (MEST)

> handshake message without amending RFC 4680.

The logical extension of RFC 4680 would be to define another new pair
of TLS handshake messages (EncryptedSupplementalData) with the same
internal structure, that go between CCS and Finished.

-Martin

---

From: Marsh Ray <[email-masked]>
Date: Tue, 22 May 2012 14:32:56 -0500

On 05/22/2012 12:47 PM, Wan-Teh Chang wrote:
> handshake message.

Simply because it's already mostly specified.

> SupplementalData is sent immediately before the

Would it be better to amend an RFC in order to re-use an existing 
structure in a different place, or to define a new handshake message? If 
the structure were very complex, I think most of us would say the 
former. But this is a trivial wrapper structure so it probably doesn't 
make much difference.

- Marsh

---

From: Ben Laurie <[email-masked]>
Date: Wed, 23 May 2012 12:02:41 +0100

> Simply because it's already mostly specified.

We're adding support to OpenSSL at the moment :-)

We plan to use it for Certificate Transparency.