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 <akr(_at_)akr(_dot_)io> 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
TLS(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/tls