Subject: [TLS] Next Protocol Negotiation 03

From: Adam Langley <[email-masked]>
Date: Tue, 24 Apr 2012 16:56:42 -0400

With httpbis active, several people have suggested that it's time to
make another pass at making NPN a little more formal.

Previous drafts have omitted some details so that the more important
aspects were clearer. Paul Hoffman also made a valiant attempt [2] at
making it more "IETF friendly" to see whether that would get anywhere.

In contrast, the current draft [1] is complete and sufficient to
produce an interoperable implementation with what's running on
www.google.com.

Perforce, it includes the current extension and handshake message
numbers. I understand that using these numbers without permission has
upset some people. However, we stand up, evaluate and tear down TLS
work at a rate far in excess of what the WG could usefully process.
Standardising every experiment before testing it would waste RFCs and
allocations, not to mention years. Therefore the extension and
handshake numbers were randomly generated.

NPN is included in several TLS implementations and used quite
regularly on the Internet and I would like the TLS WG to consider its
adoption.

Cheers

AGL

[1] https://tools.ietf.org/html/draft-agl-tls-nextprotoneg-03
[2] https://tools.ietf.org/html/draft-agl-tls-nextproto-00

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Apr 2012 15:05:00 +0300

Hi Adam

I support the adoption of NPN.

However, I would like to get a statement from Google, that if the output from the working group is different from what is running on Google's servers (and Chrome and Firefox) right now, those servers and clients will change to match the standard. Otherwise, we are going to have one of two outcomes:
 - the TLS working group rubber-stamps Google's proposal, perhaps decorating it with some nice security considerations.
 - the TLS working group creates a different standard, and implementers can choose between the Google NPN and the IETF NPN, and more that likely, implement both.

At HTTPBIS in Paris There was such a statement about SPDY. Can you make one about NPN?

I can think of two things that might prove contentious:
 1. Using the extension and handshake numbers. I would hope that IANA assigns those numbers rather than forcing a transition period, but that should not be a problem as both clients update without asking the user, and the servers are under your control. So it's not a problem either way.

 2. Some may consider the use of a new handshake message as superfluous. You could have the client advertise that it supports http/1.1 and spdy/2.0, and then the server chooses one in the ServerHello. The downside is that an eavesdropper can then know what the protocol inside the TLS connection is. I don't know if the benefit of hiding that information is worth a new handhsake message, which also changes the state machine.

Yoav

---

From: Jack Lloyd <[email-masked]>
Date: Wed, 25 Apr 2012 08:18:44 -0400

On Wed, Apr 25, 2012 at 03:05:00PM +0300, Yoav Nir wrote:

> 1. Using the extension and handshake numbers. I would hope that IANA
>  assigns those numbers rather than forcing a transition period, but
>  that should not be a problem as both clients update without asking
>  the user, and the servers are under your control. So it's not a
>  problem either way.

This seems to be assuming the only users for NPN are Firefox and
Chrome on the clients and Google's servers, but given that NPN is
already included in OpenSSL 1.0.1 and there seems to be substantial
interest in SPDY on the server side, it seems implausible that this
would still be true by the time the WG produced a modified NPN
extension.

-Jack

---

From: Adam Langley <[email-masked]>
Date: Wed, 25 Apr 2012 09:09:24 -0400

> However, I would like to get a statement from Google, that if the output from the working group is different from what is running on Google's servers (and Chrome and Firefox) right now, those serve…

I will have to check around before making a statement on behalf of
Google, but my personal inclination would be to adopt the result of
the WG. If the result differed, then Chrome/Firefox may support both
during the transition, which could be several years. (Google is not
the only large site using SPDY.)

>  1. Using the extension and handshake numbers.

I feel that the process around magic numbers is flawed and forcing a
renumbering would be an unfortunate amount of effort to serve very
abstract goals. None the less, I don't think that renumbering would be
a deal breaker.

>  2. Some may consider the use of a new handshake message as superfluous.

We reached the point where we have to deploy over TLS with NPN, in
part, because of middleware interference. TLS's cryptography has been
a fairly effective barrier that has held the line below the transport
layer for the most part. (MITM proxies are the significant exception.)
Other protocols that lack cryptography (notably HTTP) are now
effectively frozen in place by buggy middleware in all directions.

Given this history, an NPN that allows middleware to 'filter' would
seem to be a short term solution at best.

We're also looking at other extensions, for example encrypted client
certs[1] (which have been suggested by others too), that also involve
encrypted handshake messages. So that state machine change may be be
useful for a range of needs.

[1] http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00

Cheers

AGL

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 25 Apr 2012 17:15:52 +0200

> handshake numbers were randomly generated.

Some comments on the current draft. It is quite a complex negotiation.
My understanding is, that instead of having a simple:
ClientHello: I want protocols A, or B.
ServerHello: Let's talk A.

We have
ClientHello: I want to negotiate a protocol
ServerHello: I have A or B.
...
Client NPN message: Let's talk A.

That's really different from any other negotiation in TLS.
I understand that you might want to hide the protocol that
they are actually talking, but is this the way to do it?

Say that B is TOR. Wouldn't a middleware terminate the connection anyway
if the server supports tor? So that complication doesn't
really buy privacy or protection against middlewares.

I'd suggest that you define NPN using the simple ClientHello/ServerHello
methods, and then for privacy add a new extension NegotiatePrivate or so
that would exchange after Client ChangeCipherSpec:
ClientPrivateExtensions: client_hello_extension_list<0..2^16-1>;

and after the server Changecipherspec:
ServerPrivateExtensions: server_hello_extension_list<0..2^16-1>;

and this format is not NPN specific. Any extension
can be negotiated like that.

regards,
Nikos

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Apr 2012 10:58:19 -0500

> useful for a range of needs.

So if we are going to change the state machine in a generally more 
useful way, why not make the change more general?

I.e., instead of

> struct {
>      opaque selected_protocol<0..255>;
>      opaque padding<0..255>;
>    } NextProtocol;

We could define something closely analogous to a Hello message extension 
area, records sent immediately after the CCS in their respective directions:

struct {
     Extension extensions<0..2^16-1>;
} ClientAdditionalExtensions;
struct {
     Extension extensions<0..2^16-1>;
} ServerAdditionalExtensions;

thus re-using the definition of 'Extension' from RFC 5246.

The use of these ClientServerAdditionalExtensions record could be 
negotiated with (what else?) a new extension. We could call it the 
AdditionalExtensionsNegotiationExtension, but maybe there's a better 
name. I envision this extension could be sent on the Client Hello and 
replied to on the Server Hello if this feature is negotiated.

We could define this Client Hello extension to be empty, or it might be 
useful to have it list the ExtensionTypes for which the actual data will 
be sent in the CAE and those for which the reply is required to be sent 
in the SAE record after the CCS.

The extension sent in reply on the Server Hello reply would indicate the 
feature was negotiated successfully. It could list the ExtensionTypes 
for which the use of was negotiated successfully, but the actual reply 
payload will be found in the SAE after the CCS.

There are considerations for resumed handshakes because the server CCS 
comes before the client CCS. But there are already such considerations: 
"Most current TLS extensions are relevant only when a session is 
initiated: when an older session is resumed, the server does not process 
these extensions in Client Hello, and does not include them in Server 
Hello.  However, some extensions may specify different behavior during 
session resumption." [RFC5246]

This would enable implementors to take the pain of modifying their state 
machines once while also enabling other extensions to benefit from the 
privacy enhancement.

Thus, the definition of next_protocol remains nearly the same, except 
that it is now the "extension data" field of a proper 
next_protocol_negotiation type extension.

We'd have to decide which (if any) of the currently defined extension 
types should be considered incompatible with this new feature, but it 
seems like most would transition smoothly. Few current extensions seem 
to affect handshake messages between the Hellos and the CCS. Nor does it 
seem likely that many will specify different behavior during session 
resumption."

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Apr 2012 11:09:52 -0500

> really buy privacy or protection against middlewares.

Tor is actively engaged in a fascinating tit-for-tat contest with 
protocol censors. In fact, they are developing methods precisely to make 
it impractical for unauthorized middleboxen to actually determine "if 
the server supports Tor".

It's an evolving situation and I expect it will continue to evolve 
faster than, say, IETF protocols. :-) So I don't think it's a useful 
indicator of the effectiveness of any proposed TLS protocol features.

- Marsh

---

From: Adam Langley <[email-masked]>
Date: Wed, 25 Apr 2012 12:40:40 -0400

> really buy privacy or protection against middlewares.

The idea would be that the server doesn't advertise Tor, or any other
possibly suspect protocol. Rather the client would simply select "tor"
as the protocol.

The fact that the server advertises is unfortunate, but necessary to
avoid an extra round trip. I'd rather see NPN in the clear as a
standard ClientHello/ServerHello negotiation then take an extra round
trip.

Cheers

AGL

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 25 Apr 2012 09:42:27 -0700

> they are actually talking, but is this the way to do it?

Hiding the protocol is problematic if the server wants to use
the NextProtocol as part of its certificate selection process.
It would need to be in the ClientHello extension.

Also, if we're going to go down the road of sending Handshake
messages after ChangeCipherSpec (NPN, concealed client cert),
then I'd suggest that there should be no order imposed on these
messages; otherwise the state machine logic could get unwieldy
quickly, not to mention the difficulty in writing the specs.

Further, we should not create another registry of protocol
names (the Google Tech Note lists "http/1.1", "spdy/1", and
"spdy/2" as being in use).  Please leverage the existing IANA
list of well-known services for this (so we don't need to
duplicate definitions for "smtp", "imap4", etc.), along with
the standard "x-" prefix for anything experimental like SPDY
("x-google-spdy-2" as an example).

Mike

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2012 11:51:14 -0500

> ("x-google-spdy-2" as an example).

I disagree.  First, TCP port numbers are a scarce resource, and one
thing we should have learned by now is that creating scarce resources
== creating problems.  Second, the chances are that the set of TCP
port number services and NPN protocols will not be one be a subset of
the other.  Why waste a port number (or add an alias to one) if it
will never be used?  Third, why the heck should anyone have to
register their service protocol names?  That only ever made sense in
the context of a scarce resource (port numbers).

I'm with those who want SSHv2-style extension naming (i.e.,
name@domain).  It's worked great for SSHv2.  (The one major
extensibility issue for SSv2 has been its initial handshake, which is
not easily extensible, and the one reserved field in it has not been
implemented consistently, so it's useless in that regard, which has
led to some degree of signalling through fake algorithm identifiers.)

Nico
--

---

From: Adam Langley <[email-masked]>
Date: Wed, 25 Apr 2012 12:53:54 -0400

> area, records sent immediately after the CCS in their respective directions:

This would appear to be very close to to what Nikos suggested. But
this is important an important point:

> There are considerations for resumed handshakes because the server CCS comes
> before the client CCS.

If NPN were a property of the session, then we wouldn't have to burn
an extra round trip when negotiating encrypted extensions with an
resumed handshake.

It still precludes False Start, but I'm not adverse to making NPN a
property of the session - it just makes the code a little more
complex.

Cheers

AGL

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 25 Apr 2012 10:57:10 -0600

On 4/25/12 10:42 AM, Michael D'Errico wrote:

> Further, we should not create another registry of protocol names
> (the Google Tech Note lists "http/1.1", "spdy/1", and "spdy/2" as
> being in use).  Please leverage the existing IANA list of
> well-known services for this (so we don't need to duplicate
> definitions for "smtp", "imap4", etc.), along with the standard
> "x-" prefix for anything experimental like SPDY ("x-google-spdy-2"
> as an example).

Folks in the security area might think differently, but over in the
applications area we're working to deprecate the "x-" prefix:

https://datatracker.ietf.org/doc/draft-ietf-appsawg-xdash/

In fact it's on tomorrow's IESG telechat, so poke the Security ADs
right now if you have concerns. :)

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 25 Apr 2012 11:12:12 -0700

I think you misunderstood what I meant.  I don't want to use
port numbers, but rather the service names such as "smtp" and
"imap" which have already been registered with IANA.  No need
to create a duplicate registry for use in TLS NPN.

I am unfamiliar with SSH at the protocol level, so was unaware
of its extension naming.  Would "spdy/[email-masked]" be an
example of how to name non-IANA things?  Looks good to me.

Mike

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2012 13:29:57 -0500

> to create a duplicate registry for use in TLS NPN.

Right, but those names got with port numbers...

> example of how to name non-IANA things?  Looks good to me.

Yes, that.  Works great!

Nico
--

---

From: Adam Langley <[email-masked]>
Date: Wed, 25 Apr 2012 11:40:17 -0700 (PDT)

> Yes, that. Works great!
Rather, I think it would be "[email-masked]/2". None the less, I'm
perfectly happy with that if it avoids extra IANA work.

Cheers

AGL

---

From: Nico Williams <[email-masked]>
Date: Wed, 25 Apr 2012 14:20:44 -0500

> perfectly happy with that if it avoids extra IANA work.

In SSHv2 the rule is <name>@<DNS domainname>, so it'd have to be
[email-masked], or some such.  But tonce we've agreed to the
principle, the exact form of the identifier is much less important.  I
don't mind if we went with <name>@<domain>[/<fragment>], or better
yet: tag URIs (RFC4151) (name@domain is slightly less verbose, but
whatever).

Nico
--

---

From: Marsh Ray <[email-masked]>
Date: Wed, 25 Apr 2012 14:32:50 -0500

> standard ClientHello/ServerHello negotiation then take an extra round

I don't speak for the Tor project, but I don't think this design is 
going to meet anyone's requirements for serious censorship resistance.

Nevertheless, giving some privacy to the significant bits of the 
handshake in a way that is more latency-friendly than full renegotiation 
is very appealing. It seems likely to enable new and interesting 
applications, SPDY is just one good example.

Unfortunately, we must keep in mind that anything sent before receiving 
the other endpoint's Finished message is going to raise similar 
considerations as False Start. The security guarantees provided to this 
data are somewhat squishy, as they tend to depend on all sorts of 
not-yet-fully authenticated details of the in-progress negotiation. As 
we saw with ServerKeyExchange DHE_RSA/ECDH, even the future introduction 
of new key exchanges and cipher suites can change these properties.

In the case of something like NP(N), a MitM might utilize a downgrade 
attack which allows him to decrypt the client's NP record (possibly 
offline). This could break the handshake, but clients are so eager to 
retry the user might not even notice.

So maybe any facility for "privately" negotiating handshake extensions 
ought to be held to a clear standard lest we invite disaster, namely, it 
should provide the same security guarantees as are provided to 
application data.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Wed, 25 Apr 2012 12:57:59 -0700

> standard ClientHello/ServerHello negotiation then take an extra round

I think we can accommodate both "styles" of NPN with one extension:

    A) If the client sends an empty ExtensionData, then behave
       the way it is currently defined by the Technical Note.

    B) Otherwise if the client sends a list of protocol strings
       in its ExtensionData, then the server chooses the first
       one it supports and responds with it.

    C) Sending an empty list would have to be defined as either
       an error (server responds with a fatal alert) or to be the
       same as (A).

Mike

---

From: Marsh Ray <[email-masked]>
Date: Thu, 26 Apr 2012 12:12:28 -0500

> applications, SPDY is just one good example.

Just an update, I've made contact with the Tor project. As heavy users 
of TLS, they are interested in the direction the protocol evolves. They 
may also have some useful input here on this issue of privacy of 
handshake records.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Thu, 26 Apr 2012 19:21:00 +0200 (MEST)

> may also have some useful input here on this issue of privacy of 

  http://tools.ietf.org/html/rfc4680

describes two additional generic handshake messages in the cleartext
part of the TLS handshake.

Maybe we should define something similar for the encrypted part of
the handshake, so that we don't have to add new handshake messages
for every new feature?

-Martin

---

From: Adam Langley <[email-masked]>
Date: Thu, 26 Apr 2012 13:29:39 -0400

> the handshake, so that we don't have to add new handshake messages

Indeed, folks seem to be leaning towards wanting more generic support
for extensions under encryption. Having a "client offers, server
selects" extension exchange after the ChangeCipherSpecs is perfectly
possible, although at the cost of precluding False Starting a full
handshake. False Start isn't a real TLS feature of course, but we're
currently pondering how much we want to be able to support it, and how
much we want NPN under encryption.

Also, if there's a generic "secure" extension exchange after the CCS,
it has the same concerns as False Start. i.e. an attacker can perform
a downgrade attack on it. For False Start we say that if the
ciphersuite isn't strong enough, we simply won't do it. But having a
TLS feature switch on and off like that seems untenable.

So, in short, "still thinking".

Cheers

AGL

---

From: Tom Ritter <[email-masked]>
Date: Fri, 27 Apr 2012 10:53:33 -0400

> Defining the use cases and the threat model of post-CCS extensions is
> probably a useful thing to do at this point.
> ...
> With regards to the threat model, post-CCS extensions should probably
> share the exact same threat model as pre-CCS extensions, since they
> both happen before the Finished record (for example, putting
> application data on them is not a good idea).
> ...
> Getting a bit funkier (since the state machine is a-changing these
> days) maybe it makes sense to add a post-auth post-Finished phase to
> TLS, so that "supplemental data" can be exchanged without the fear of
> an MITM.

I think I'm in the minority here, but I tend to distinguish passive
and active attacks significantly, and into different threat models.
We've seen evidence of widescale passive 'attacks'/taps on the
government level, and more commonly on the corporate level - the
evidence indicates that passive taps are pervasive, orders of
magnitude more common than the active attacks we've seen in Syria,
Iran, and corporate environments.

Post-CCS extensions are good against passive attacks, but not active
ones.  This was discussed at length a little bit ago when talking
about Encrypted Client certificates where the threat model moved (from
my perception) from preventing passive observation to preventing an
active attempt to learn the client's identity by altering the
handshake detectably.

There's potentially two state machine changes here. Post-CCS,
Pre-Finish - where the tradeoff of performance is better than
resistance from active attacks: perhaps SNI.  And Post-Finish for
things that should resist active attacks: such as encrypted client
certificates.

-tom