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

From: The IESG <[email-masked]>
Date: Fri, 13 Dec 2013 09:16:08 -0800

The IESG has received a request from the Transport Layer Security WG
(tls) to consider the following document:
- 'Transport Layer Security (TLS) Application Layer Protocol Negotiation
   Extension'
  <draft-ietf-tls-applayerprotoneg-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2013-12-27. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document describes a Transport Layer Security (TLS) extension
   for application layer protocol negotiation within the TLS handshake.
   For instances in which the TLS connection is established over a well
   known TCP/IP port not associated with the desired application layer
   protocol, this extension allows the application layer to negotiate
   which protocol will be used within the TLS session.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 13 Dec 2013 09:27:22 -0800

The shepherd writeup for this document (current version at <http://datatracker.ietf.org/doc/draft-ietf-tls-applayerprotoneg/shepherdwriteup/>) is not accurate, and that has a major effect on the IETF Last call. For question 9, it says:

==========
(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

the document represents strong consensus
==========

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.

--Paul Hoffman

---

From: Alyssa Rowan <[email-masked]>
Date: Fri, 13 Dec 2013 19:42:27 +0000

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

---

From: Yoav Nir <[email-masked]>
Date: Fri, 13 Dec 2013 21:43:13 +0000

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 <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
> 
> -----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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Dec 2013 14:46:45 -0800

On 13 December 2013 13:43, Yoav Nir <[email-masked]> wrote:
> 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.

As the editor of the spec that stands most to be affected by faffing
around here, I'd be strongly opposed to further delays.

...and don't take this to mean that this is the only reason I believe
we should proceed in this way.  The arguments stacked up against ALPN
are not new.  I've read the arguments presented, and agree with some
points, disagree with others, but on the whole I find them completely
unconvincing.

---

From: "Stephan Friedl (sfriedl)" <[email-masked]>
Date: Sat, 14 Dec 2013 00:28:29 +0000

I fear that there is a perception that ALPN leaks information like a sieve and NPN doesn't leak at all.  Both extensions leak information in plain text - they just leak different information.  

NPN leaks the entire list of protocols available on a host/port combination and encrypts the single protocol selected by the client.  When watching a single TLS negotiation using NPN, a passive attacker knows all the protocols exposed by a server and therefore has a big head start on identifying the single protocol chosen by the client as well as assessing a server for potential vulnerabilities to exploit - effectively an instant port scan.  In contrast ALPN has the client advertising the protocols it supports in plaintext and has the server's selection of a protocol returned in plaintext.  In ALPN the entire list of protocols supported by a given host on a given port is never revealed during a single TLS negotiation.

Also, I agree with Yoav's take on ALPN as simple networking and not a 'cryptographic protocol'.  All ALPN does is provides the protocol to be used for a connection when the port number is no longer definitive.  ALPN is a plain, vanilla extension - whereas NPN does introduce some non-standard twists to TLS extension practice in that the negotiation is not encapsulated in the hello messages and that it introduces a padded handshake message between the ChangeCipherSpec and Finished messages.

Thanks,

Stephan

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Yoav Nir
> Sent: Friday, December 13, 2013 2:43 PM
> To: Alyssa Rowan
> Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt>
> (Transport Layer Security (TLS) Application Layer Protocol Negotiation
> Extension) to Proposed Standard
> 
> Hi Alyssa
> 
> - 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
> 
> 
> >> 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.
> >
> > * At IETF 88's Technical Plenary, serious concerns were raised about
> > * Decisions were made at IETF 88, with overwhelming consensus, that
> > * ALPN has no such consideration. It leaks plaintext metadata which
> > its  competitor, NPN, encrypts. This makes ALPN quantitatively more
> > * Profound concerns have been raised about the protocol and the voting
> > * The chairs and AD have refused, and simply ignored the concerns.
> > * It is publicly known that Nation State Adversaries have attempted
> > to,  and in some cases succeeded in, weakening or backdooring
> > <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
> > * As discussed at the IETF 88 Plenary, especially in light of the
> > * That has not happened with the ALPN extension to date.
> >

---

From: Watson Ladd <[email-masked]>
Date: Fri, 13 Dec 2013 16:47:23 -0800

> NPN leaks the entire list of protocols available on a host/port combination and encrypts the single protocol selected by the client.  When watching a single TLS negotiation using NPN, a passive att…

Clients are much more interesting to watch than servers. So long as
ALPN and NPN are negotiating among a small number of protocol versions
this doesn't matter. But if we include various options in HTTP this
makes fingerprinting easier if they are exposed in ALPN. Scanning for
what a server supports looks like a bunch of diverse clients
connecting: it isn't going to get noticed anyway. But knowing that a
client supports the latest Firefox+a particular extension because it
has support for a protocol over 443 is very useful. I don't think the
extra few bits matter, but we should remind everyone that they should
be very few bits. (In particular the inevitable hack advertising IRC
support via ALPN is a terrible idea).

> Also, I agree with Yoav's take on ALPN as simple networking and not a 'cryptographic protocol'.  All ALPN does is provides the protocol to be used for a connection when the port number is no longer…

ALPN needs to be negotiated and tied into the session. Otherwise you
can have fun playing wrong protocol with right authority games.

Sincerely,
Watson Ladd

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 14 Dec 2013 00:50:38 +0000

On 13/12/2013 21:43, Yoav Nir wrote:

> I mostly agree with the facts presented below. However: - I object
>  to characterizing this as a "cryptographic protocol".

Fair enough. Poor choice of words on my part. ALPN is a metadata
extension to the cryptographic protocol, TLS.

> [...]we now have TLS tell us whether there's HTTP/1 or HTTP/2 
> inside.

The I-D doesn't seem to limit this to HTTP/1 or HTTP/2: it's a general
extension, which suggests a general use case.

If HTTP/(1|2) is all it's really intended to be used for at this time,
(your and Martin's response makes me think maybe it is), then perhaps
we SHOULD only use it for that at this time.

I think that would substantially weaken my objection. How would others
feel about that?

And then later (TLS 1.3?), if we can encrypt the ClientHello [How?
Ed25519+Elligator2 key from DNSSEC, or something? Hm... not sure.],
then ALPN is fine. That might be a way forward, perhaps.

> - Mass surveillance is a concern. It is not the only concern.

I agree (though it is of growing importance). Little metadata leaks
can still be important where they intersect.

> We haven't heard anyone explain what good knowing the version of 
> HTTP does to a nation state adversary.

Hypothetical case study:

If NSA had, for example, a practical attack on the RSA-RC4-(SHA|MD5)
ciphersuites that used likely known-plaintext prefixes ("GET /"...?)
along with biases in the keystream to, as they would say, "enable"
partial key recovery, ALPN would mean they don't even have to guess
which prefix to try, and might be able to make it easier for non-HTTP
use of TLS.

Of course, that's just my own guess, and the BIG vuln there is RC4
(which can be (I hope) dealt with by Adam's draft).

ALPN would, I appreciate, be a help in packet classification/shallow
analysis, mostly if more widely deployed among other protocols.

I note Stephan's comments about NPN's own leaks, and so NPN could be
more useful to them in "CNE" (hacking), when the gloves come off.
There are benefits and drawbacks to both - I accept that.

> - The chairs did not ignore the requests. They rejected them.

They said that no substantive new information had been presented since
the initial consensus call and therefore the consensus should stand.
(They did state that objections could be raised during IETF LC: that's
what's happening now.)

The disclosures re: BULLRUN and the IETF 88 TP seemed simply
unaddressed. I find that baffling. It is, as you say, rushed. It looks
like railroading, and I'm sure all want to avoid that appearance.

If the WG indeed knew then what we know now, then if we took a quick
consensus on-list, it'd have a similar result, and all would see that
it has been reached openly and transparently, which would address the
concerns that have been raised?

> While I prefer ALPN, I wouldn't consider it tragic to have had 
> NPN.

Similarly, I prefer NPN, but I'm not vehemently against ALPN,
particularly if limited in scope to HTTP/1 or /2 until ClientHello can
be encrypted in TLS 1.3.

On 13/12/2013 22:46, Martin Thomson wrote:

> As the editor of the spec that stands most to be affected by 
> faffing around here, I'd be strongly opposed to further delays.

Sorry! I do thank you for baking TLS in - I feel that's important -
and I really do apologise for the 'faff'. (This is not really how I
wanted to introduce myself, believe me!)

I feel that, as an extension to a protocol with a billion-dollar
target painted on it, it needs to be thought through, not rushed through.

I want to make sure legitimate concerns raised on-list are addressed,
not shortcutted, and that a transparent consensus, with current
information, not stale, can be reached.

A week or so, maybe?

- -- 
/akr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 13 Dec 2013 17:05:17 -0800

On 13 December 2013 16:50, Alyssa Rowan <[email-masked]> wrote:
> It is, as you say, rushed. It looks

I don't agree with the characterization.  This needs to be fast, but
to say that is has been rushed would be a vast overstatement.  This
was first raised prior to the first individual submission of ALPN,
which was over a year ago.  We've talked about it a fair bit already
and I don't believe that the substance of more recent revelations
change anything.

I believe that our esteemed chairs and area directors have allowed
these concerns to be raised and debated sufficiently.  I am grateful
that, in this case, they have curtailed the right of infinite appeal
by closing this issue.

Me, I'd rather be spending my time dealing with TLS 1.3.  These
discussions aren't doing anyone a favour.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 14 Dec 2013 13:47:39 +0100

> I think that would substantially weaken my objection. How would others

I don't see any advantage in your proposal. Why restrict ALPN from
negotiating anything else than HTTP? Currently we _already_ select
protocols in the clear using different service ports. ALPN allows to
negotiate different service even if the port is fixed (e.g. 443). Why do
you think ALPN is worse than what we have already and shouldn't be
allowed to negotiate other services?

I understand however you'd prefer ALPN not be in the clear, but TLS does
_not_ offer any mechanism to conceal anything negotiated during the
handshake. NPN takes the greedy path and hacks the protocol to allow
concealing only the negotiated protocol (the two peers' identities are
still in the clear as well as any other negotiated information). If NPN
is accepted it would certainly make harder designing a clean method that
conceals _all_ negotiated information in next protocol revision (as it
would have to carry the NPN hack).

regards,
Nikos

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 14 Dec 2013 20:35:23 +0000

On 14/12/2013 12:47, Nikos Mavrogiannopoulos wrote:

>> [Limiting ALPN to HTTP/(1|2)]

To clarify, I specifically propose (Security Considerations?):

  It is NOT RECOMMENDED for a client using ALPN in TLS 1.2 to identify
  supported protocols other than HTTP/1 or HTTP/2: signalling that
  other protocols are supported could reveal more fingerprinting,
  targeting or application metadata in plaintext than is desirable or
  necessary.

  This caveat does not apply if the ClientHello is protected from
  passive eavesdropping [as in a future version of TLS].

(Subject to argument, of course.)

>  negotiating anything else than HTTP?

Because:
• It minimises plaintext fingerprinting.
  - Eve trivially knows every protocol Alice advertises support for.
  - Ideal if Eve wants to become Mallory and has a tailored exploit
    for one of them.
    · Real scenario: QUANTUM, EGOTISTICAL GIRAFFE, etc
  - Please let's keep that to a minimum, while it's still plaintext.
• Why use ALPN (or NPN!) for anything?
  - Why _indeed_ not use a port number? POP3 got one. Why not HTTP2?
  - Because of port-blocking firewalls disallowing all but port 80/443.
  - Many non-IETF protocol deployments bitten by this chose to use 443.
    · Tor
    · Several VPNs, including SSTP, and commonly OpenVPN in the wild
    · Skype [not that that's a _good_ protocol, just a common one!]
  - So multiplexing on 443 is considered fairly commonplace/desirable.
  - But DPI firewalls, even simple ones, can read ALPN if plaintext.
    · So they'd block those, too. Then what? Stop using ALPN? Lie in it?
• Most of all, because: it's HTTP/2 that needs it _right now_.
  - Other things can have it later, in TLS 1.3, when it's much safer.

At this point (post-IETF 88) if we were redesigning UDP or TCP, we'd
certainly consider encrypting the port numbers, if it were practical,
wouldn't we?

As far as your point that NPN is a bit of a hack, I agree.

It may be better to have ALPN in a limited fashion now, so that Martin
and the httpbis WG can proceed - I do not really want to delay their
fine work - and encrypt the whole ClientHello later in TLS 1.3.

Therefore, upon reconsideration, I withdraw my objection to ALPN
progressing to Proposed Standard.

I do wish for my caveat above to be noted under Security
Considerations, although this is of course subject to argument,
as others may not agree.

I apologise for any inconvenience caused.

- -- 
/akr

---

From: Yoav Nir <[email-masked]>
Date: Sat, 14 Dec 2013 21:40:13 +0000

> (Subject to argument, of course.)

Someone here suggested running email protocols (IMAP, POP3, and SMTP) over the same 443 port, distinguished by ALPN. In sites such as live.com or mail.google.com, you might even get the same information in HTTP/1, HTTP/2, IMAP, or POP3. Why should those be excluded?  How about having this in the security considerations:

   Implementers and document editors who intend to extend the protocol 
   identifier registry by adding new protocol identifiers should consider
   that in TLS versions 1.2 and below the client sends these identifiers
   in the clear, and should also consider that for at least the next 
   decade, it is expected that browsers would normally use these earlier
   versions of TLS in the initial ClientHello.

   Care must be taken when such identifiers may leak personally 
   identifiable information, or when such leakage may lead to profiling,
   or to leaking of sensitive information. If any of these apply to 
   this new protocol identifier, the extension SHOULD NOT be used in TLS
   versions 1.2 and below, and documents specifying such protocol 
   identifiers SHOULD recommend against such unsafe use. 

> iQIcBAEBCgAGBQJSrMEKAAoJEOyEjtkWi2t6JIcP/2UuGi+sg0dAKOnzBjzpxwo0
> CvgVwES4WtF2QJEq7sCkXbYUIqW4uDeNAUy6D+vR5+Q407oPeIgR4IH9AzThFkpM
> MR6cBP+yYyRpr0AFCtuupR77L0up9uLoSZxAgH7A4ot6s/fa2Vg1xtxE+C5/Sz4G
> lPc6j8Rr3LnWlqH47kp+YxZAtAOa2pieWYDJlS8zK2Ulaf7I1mtAIy4MDAVrFYAN
> Tye/LQLg485j0uXiDs3xErps0XJQKTT+dV3WtPMyNek6XjEQgHXQ9WbJE9t6F8W0
> 9Y5b2gzhoPoJ99OYTvZmYtdPdtFHHU+Hq6Q4ZuP64AMFviNTY7TQl3PD68WIiCyy
> 7feWHtl7Zb0Cbx8l+ZN3OV8BuUIcO3StcFnjaIu0jPP+Th2Wf9I+6045uqBq/Gmw
> VmpMVR7+QDBLt15VnIuZNwdbo+e7Apin/YNnWxKg6PYakYXtCqQv+xWiexZooNn9
> 9vRnn3dzfLYMyjjd4sPDiEQ0toMIOQ133IToN6/TRU+VX00BnX5mZ8IMvRTwoVXz
> ja1NJJUnZrYkS4P6/knR/8pQBONtVbQQ/JFhbmH2KtaUWdG4KnE9RSzCe3FVC9Um
> iHeC/uY6ZTM521ISfCOH2+hj6Z3BDPm8WZCdLHB6T2pg+7ki+g8SbvpnaPy5RQ1L
> N4TGPOysvUqmgcm9EDjT
> =F2Gq

---

From: Alyssa Rowan <[email-masked]>
Date: Sat, 14 Dec 2013 22:52:56 +0000

On 14/12/2013 21:40, Yoav Nir wrote:

> How about having this in the security considerations:
> 
> Implementers and document editors who intend to extend the
> protocol identifier registry by adding new protocol identifiers
> should consider that in TLS versions 1.2 and below the client sends
> these identifiers in the clear, and should also consider that for
> at least the next decade, it is expected that browsers would
> normally use these earlier versions of TLS in the initial
> ClientHello.
> 
> identifiable information, or when such leakage may lead to 
> profiling, or to leaking of sensitive information. If any of these 
> apply to this new protocol identifier, the extension SHOULD NOT be 
> used in TLS versions 1.2 and below, and documents specifying such 
> protocol identifiers SHOULD recommend against such unsafe use.

Absolutely. Much better than my wording. Less limiting, but lets them
know what they're doing by using it.

The next decade part makes me a sad panda. Realistic, but depressing.
Let's see if we can do better with TLS 1.3!

- -- 
/akr

---

From: "Randy Presuhn" <[email-masked]>
Date: Sun, 15 Dec 2013 16:04:45 -0800

Hi -

> From: "Alyssa Rowan" <[email-masked]>
> To: <[email-masked]>; <[email-masked]>; <[email-masked]>
> Sent: Friday, December 13, 2013 4:50 PM
> Subject: Re: [TLS] Last Call: <draft-ietf-tls-applayerprotoneg-03.txt> (Transport Layer Security (TLS) Application Layer Protocol
Negotiation Extension) to Proposed Standard
...
> I think that would substantially weaken my objection. How would others

I think at least a little consideration should be given to other
protocols that employ TLS, e.g. Netconf.

Randy