Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol Negotiation Extension) to Proposed Standard

[Yoav Nir <[e-mail]>]

Hi Alyssa

I mostly agree with the facts presented below. However:

- I object to characterizing this as a "cryptographic protocol". This is simple networking. Just as Ethernet tells us there's IP inside, and IP tells us there's TCP inside, and TCP tells us about port 443 (which used to mean https), we now have TLS tell us whether there's HTTP/1 or HTTP/2 inside. This is needed because the HTTP specifications and implementations don't handle version negotiation well. This can have security implications, but it's not a cryptographic protocol.

- Mass surveillance is a concern. It is not the only concern. The IP address of the server I'm accessing leaks far more important information then whether I'm using HTTP/1 or HTTP/2. This may also leak the browser version, but that can also be readily recognized by looking at the ciphersuite list. Sure, others (including me) raised all sorts of possibilities for extra used for ALPN. For now, there's only the two versions of HTTP.  We haven't heard anyone explain what good knowing the version of HTTP does to a nation state adversary.

- The chairs did not ignore the requests. They rejected them. You can still disagree. One thing is missing from the account of the hum at IETF 87. Yes, there were some voices for each proposal, and that does not a consensus make. But then Sean asked a different question, and got overwhelming support for the statement that reaching a decision right then was important, and that we didn't want to wait and discuss it more. That is why the choice between them was done as an almost vote - nearly all of us at the time preferred to get *a* decision rather than keep hashing the subject over and over again. Rolling back, as people are suggesting now, runs contrary to that consensus.

- I've read that message suggesting the chairs had conflict of interest. There's no question the chairs worked to rush this decision, but my memory is that they mostly wanted to avoid accepting this work item at all. Having accepted it, they may have had a bias for less radical changes, but I don't remember any "railroading".

While I prefer ALPN, I wouldn't consider it tragic to have had NPN. But we (in the sense of the IETF, mostly the httpbis group) have a goal for a feature complete document for HTTP/2 with multiple interoperable implementations in the wild. This requires the negotiation part to be done. Rolling back the TLS WG decision now puts that goal at risk, so I oppose it.

Yoav


On Dec 13, 2013, at 9:42 PM, Alyssa Rowan <[e-mail]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> On 13/12/2013 17:27, Paul Hoffman wrote:
> 
>> A hum was taken at IETF 87 for the WG to pick between this
>> proposal and another; there were many hums in the room for each,
>> with more for this proposal. That hum was not taken to the WG
>> mailing list. Since then, many people have given strong reasons to
>> prefer the other proposal for technical reasons.
> 
> Strongly seconded. This cryptographic protocol is not ready yet, and
> requires careful reconsideration on-list, and at the very least a
> public on-list call for consensus - which it does not seem to have
> received - before deciding whether it is appropriate to proceed.
> 
> • At IETF 88's Technical Plenary, serious concerns were raised about
>  mass surveillance of data and metadata by Nation State Adversaries.
> 
> • Decisions were made at IETF 88, with overwhelming consensus, that
>  new protocols MUST consider the impact they have on mass surveillance.
> 
> • ALPN has no such consideration. It leaks plaintext metadata which its
>  competitor, NPN, encrypts. This makes ALPN quantitatively more
>  vulnerable to passive attackers, including Nation State Adversaries.
>  [It may be that a future TLS 1.3 can encrypt the whole ClientHello;
>  but that is not the current state-of-play. As it stands, it would be
>  plaintext.]
> 
> • Profound concerns have been raised about the protocol and the voting
>  process. A call has been made for at the very least the opportunity
>  to stop, rewind, and rethink whether ALPN is appropriate, and for a
>  new consensus call.
>  <https://www.ietf.org/mail-archive/web/tls/current/msg10892.html>
> 
> • The chairs and AD have refused, and simply ignored the concerns.
>  <https://www.ietf.org/mail-archive/web/tls/current/msg10947.html>
>  <https://www.ietf.org/mail-archive/web/tls/current/msg10948.html>
> 
> • It is publicly known that Nation State Adversaries have attempted to,
>  and in some cases succeeded in, weakening or backdooring
>  cryptographic standards. TLS has very likely been a main target of
>  this, as the most-used cryptographic standard on the internet.
> 
> <http://www.nytimes.com/interactive/2013/09/05/us/documents-reveal-nsa-campaign-against-encryption.html>
> 
> • Concerns have been raised that one or more of the chairs or AD may
>  have a conflict of interest and appear to be railroading the process.
>  <https://www.ietf.org/mail-archive/web/tls/current/msg10943.html>
> 
> • As discussed at the IETF 88 Plenary, especially in light of the
>  Snowden BULLRUN disclosures, it is absolutely vital that
>  cryptographic standards such as TLS are devised openly,
>  transparently, and with clear, public consensus as being the best
>  available solution.
> 
> • That has not happened with the ALPN extension to date.
> 
> Therefore, I second Brian's proposal for a new consensus call and
> discussion on ALPN, and Paul's appeal to the IETF LC: in my opinion,
> it is wholly premature to advance ALPN to Proposed Standard at this time.
> 
> - -- 
> /akr
> -----BEGIN PGP SIGNATURE-----
> 
> iQIcBAEBCgAGBQJSq2MjAAoJEOyEjtkWi2t6L0MQAIxsdB4aAZvw6XdiIttRzaHR
> bmvvGCScckyUfSFS6t2V36oxp9FNmkEzaXUTpUcRMrJsRlsXgjExlIsYKYqvtPzi
> x8zPRyc2Yp61zTj2tZI0tlYDwQ3M53Pfy1br+0eLfqqy+dRaPsRyQWHi9FlMLU5u
> eGaA1KMgUOAZSxNB9oliJOXmSj+DcQpcWpp+D3piYBSINUYrY3xtO31khhG0f8xX
> EOLH7pMwVkyEhQOG83qA801Yt45j0cr6X7Wg34jFhCfCR1xQDbkMLabAXHYTWmdo
> C4cmJQVTHgnYXiIPdwXR87iPpAevBNpoxNQzps1LoHYEM6xpqDwln9aExyaPAiT6
> 4fV+Wr5C22H/Xh+wbkVFPRQEvZbbjDJKGSWyB0i6YKgmUxrF+VQHlJKFrS2TwEni
> nmIIcFFN/bo2f8bwbtLf2bEQRAzz8R2N5gVeLQJcoWEz4lcl/1F2E82tZnd9ArLU
> XGH5gawLh3bqLZRFUU0VfCYfQSrGy2PtIViyKSLKLCOlI7onL9CGB3jtSuqQDHep
> 8h3yeSk68d0gVVLmRUmx9aZMbOivZOP54t+Q8wwtluuHnGKdN2NU3oAFSfmDKcRG
> cEWsddc44tF1eANVWXxJsHe8LvxUA6UCvI19kLxuNcV4RL8lCzWr38YaUVRpqXby
> cYdzEMv6nqKpAynigGgh
> =u0As
> -----END PGP SIGNATURE-----
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls