Subject: [TLS] New draft for "next protocol"

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 May 2011 11:47:06 -0700

Greetings again. I have joined Adam as co-author on this draft. After the discussion of the previous "next protocol" draft at the meeting in Prague, we realized that the "negotiation" wording was tripping people up, so we removed it and made it clear that, at the end, this is about the client telling the server which protocol the client will be using after the TLS session is setup. To make that clearer, we re-titled the draft and started over at -00.

Please take a look at <http://www.ietf.org/id/draft-agl-tls-nextproto-00.txt> and let us know what you think.

--Paul Hoffman

---

From: David Holmes <[email-masked]>
Date: Mon, 16 May 2011 03:45:51 +0000

Very interesting!  I had assumed that the "next-protocol" extension was to inform the server (or proxy, or load-balancer) so that it could do better pre-loading, caching or optimizing.  I was surprised to see the extension described as a countermeasure for a cross-protocol attack.

Can you describe in more detail how the extension works against an attacker?  And let me apologize if this has already been discussed, I don't remember seeing it on the mailing list.

---

From: Adam Langley <[email-masked]>
Date: Wed, 18 May 2011 13:06:35 -0700

> Can you describe in more detail how the extension works against an attacker?  And let me apologize if this has already been discussed, I don't remember seeing it on the mailing list.

Preventing cross-protocol attacks is one of several uses for NPN,
although it is the one that is currently most highlighted in the
draft.

Previous versions of the websockets protocol have had to be
reverted[1] because of cross-protocol attacks where an attacker
creates confusion about which protocol is being used. As network
transparency issues force many other protocols to support running over
port 443 the risk of something bad resulting from the n^2 possible
confusions keeps going up.

NPN simply allows a client to state, unambiguously, which protocol is
being spoken.

[1] http://www.ietf.org/mail-archive/web/hybi/current/msg04744.html

Cheers

AGL

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 26 May 2011 12:29:40 -0400

On Wed, 2011-05-18 at 13:06 -0700, Adam Langley wrote:
> As network
> port 443

And when the firewalls start filtering based on the NPN extension, we
will be back to square one.

-- 
Matt

---

From: Adam Langley <[email-masked]>
Date: Sun, 29 May 2011 10:17:56 -0400

> will be back to square one.

Firewalls could filter on a) the presence of nextproto in the
ClientHello or b) the protocols in the ServerHello. Since Chrome
already sends the nextproto extension, filtering that is hopefully too
destructive. b) might become an issue, but that's why the client is
free to pick a protocol that wasn't advertised by the server if it has
out-of-band knowledge that the server will support it. The client's
choice is deliberately sent under encryption and in constant space in
order to protect it from filtering.

AGL

---

From: Florian Weimer <[email-masked]>
Date: Tue, 31 May 2011 07:03:20 +0000

* Adam Langley:

> creates confusion about which protocol is being used.

Are you sure that analysis was correct?  I'm reasonably certain that
it's not.  In other words, you got punked.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99