Subject: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Wed, 6 Feb 2013 03:09:27 +0000

Hello All,

A revised version of 'Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension' (draft-friedl-tls-applayerprotoneg-01) has been posted.  This version includes a number of significant improvements to the original draft including:

1.            Use of a single extension for both the ClientHello and ServerHello messages
2.            Definition of ProtocolIdentifiers as opaque, non-empty byte strings and the list of protocols is serialized as a concatenation of 8-bit, length prefixed byte strings
3.            Clarification of the suggested order of client-side ProtocolIdentifiers
4.            Clarification that the server-side extension_data MUST contain exactly one ProtocolIdentifier
5.            Should the server support none of the protocols advertised by the client, then the server SHALL respond with a 'fatal handshake failure alert'.
6.            Addition of Andrei Popov of Microsoft as a co-author

These changes were largely proposed by Andrei and have greatly improved the draft.

I would greatly appreciate any comments and feedback on the draft.

Thanks and Best Wishes,

Stephan

---

From: Adam Langley <[email-masked]>
Date: Wed, 6 Feb 2013 17:57:31 -0500

> These changes were largely proposed by Andrei and have greatly improved the

If this draft were published as an RFC tomorrow, we would switch to it
and start a deprecation plan for NPN.

However, we still believe that NPN is the better answer. Take this
paragraph from the draft:

> History demonstrates that there exist a multiplicity of compelling needs for TCP/IP networks to provide
> differentiated network treatment based on protocol.  This differentiated treatment may include QOS
> and/or firewalling to permit enterprises and carriers to manage the flows within their networks.  QOS
> requirements may be driven by the needs of real-time protocols or service provider SLAs or service
> tiers.  Firewalling is required to meet a variety of regulatory, compliance, appropriate use and security
> mandates.

(Removed from -01 I see, possibly because because of me.)

We believe in the end-to-end principle. And we understand that we're
having this discussion because middlebox interference has driven us to
it: HTTPS is now often the only way to get bytes across the Internet
because cryptography slowed the stultifying firewalls.

We think that what can be encrypted, should be encrypted and are
unenthusiastic about playing the same game with middleware, just one
layer up.

NPN is constrained by the round-trip requirement, but its greater
complexity apparently hasn't been a problem for the numerous
implementations. I also hope that the EncryptedExtensions message can
serve as a basis for future extensions to also be under encryption.

Cheers

AGL

---

From: Andrei Popov <[email-masked]>
Date: Thu, 7 Feb 2013 00:47:28 +0000

Cisco and Microsoft have co-authored the new ALPN draft to allow protocol negotiation without extra round-trips and to provide the following benefits:

*         Place ownership of protocol selection on the server, not the client. This allows the server to select an appropriate certificate based on the application protocol.
*         Support truly secure protocol negotiation through standard TLS renegotiation.  This introduces additional latency (only when hiding protocol information is desired), but provides confidentiality guarantees.

Thanks,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Langley
Sent: Wednesday, February 6, 2013 2:58 PM
To: Stephan Friedl (sfriedl)
Cc: [email-masked]
Subject: Re: [TLS] Revision of draft-friedl-tls-applayerprotoneg posted

> These changes were largely proposed by Andrei and have greatly 

If this draft were published as an RFC tomorrow, we would switch to it and start a deprecation plan for NPN.

However, we still believe that NPN is the better answer. Take this paragraph from the draft:

> History demonstrates that there exist a multiplicity of compelling 
> needs for TCP/IP networks to provide differentiated network treatment 
> based on protocol.  This differentiated treatment may include QOS 
> and/or firewalling to permit enterprises and carriers to manage the 
> flows within their networks.  QOS requirements may be driven by the 
> needs of real-time protocols or service provider SLAs or service tiers.  Firewalling is required to meet a variety of regulatory, compliance, appropriate use and security mandates.

We believe in the end-to-end principle. And we understand that we're having this discussion because middlebox interference has driven us to
it: HTTPS is now often the only way to get bytes across the Internet because cryptography slowed the stultifying firewalls.

We think that what can be encrypted, should be encrypted and are unenthusiastic about playing the same game with middleware, just one layer up.

NPN is constrained by the round-trip requirement, but its greater complexity apparently hasn't been a problem for the numerous implementations. I also hope that the EncryptedExtensions message can serve as a basis for future extensions to also be under encryption.

Cheers

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 7 Feb 2013 15:18:58 +0000

Hi

I support the adoption of this draft. I think it solves the problem of multiplexing multiple protocols on a single TLS-protected port.  I prefer it to NPN for the following reasons:

  1.  It is a simpler solution - just another extension and a simple selection mechanism on the server. Implementing this would require less LoC in pretty much any implementation.
  2.  I do not believe that the choice of HTTP/1, HTTP/2 or various versions of SPDY (which should be experimental anyway) needs to be secret. The value space is small enough that whatever advantage an attacker might get by having the protocol revealed, can be gotten by trial and error as well.
  3.  More similar to existing TLS, so less surprises by proxies and middleware, so less need to fall back.
  4.  More friendly to middleware - TLS proxies that will anyway drop HTTP/2 can do so earlier. I realize some will not consider this an advantage…

Reading through it, I have a few suggestions:

I think there should be a special alert message to note that none of the applications are supported. Call it no_application_chosen, rather than use handshake_failure.

I think the SPDY variants should be prefixed by exp and not registered by IANA

Also, I think there should be a prefix for private protocols, not marked as experimental. For example, we could have it say P-author_identifier-name. So if Microsoft wanted to negotiate the sue of SSTP, they could mark it as P-MSFT-SSTP

Yoav

On Feb 6, 2013, at 5:09 AM, Stephan Friedl (sfriedl) <[email-masked]<mailto:[email-masked]>> wrote:

Hello All,

A revised version of ‘Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension’ (draft-friedl-tls-applayerprotoneg-01) has been posted.  This version includes a number of significant improvements to the original draft including:

5.            Should the server support none of the protocols advertised by the client, then the server SHALL respond with a ‘fatal handshake failure alert’.

Thanks and Best Wishes,

Stephan