Subject: [TLS] ALPN or NPN ?

From: <[email-masked]>
Date: Tue, 12 Mar 2013 18:03:08 +0000

Hi,

ALPN and NPN seem very close. Nevertheless they impact differently the performance and the complexity of migration scenario.

More and more applications are being migrated over TLS. Consequently reverse proxies have to deal with more and more complex situations and need to know the application protocol to guide incoming TLS sessions toward the right servers. ALPN is very efficient because with ALPN a reverse proxy is able to start the resource selection immediately after the processing of the ClientHello. NPN is less efficient as the reverse proxy has to wait an additional TLS exchange before initiating the resource.

More and more applications are being partially or totally virtualized and carried over TLS. In these cases reverse proxies rely on information like Server Name Indication to select the server credential to return in the ServerHello. There are situations where the selection of the server credential requires the knowledge of the Server Name and of the Application Protocol. ALPN and SNI provide this information in time as there are both carried in the ClientHello. This is not possible with NPN as the Application Protocol is determined by the client after receiving the ServerHello.

Hope it helps the discussions.
Emile

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 12 Mar 2013 14:28:21 -0400

> More and more applications are being partially or totally virtualized and carried over TLS. In these cases reverse proxies rely on information like Server Name Indication to select the server crede…

these two points seem to be marks in favor of ALPN.

However, NPN does not advertise the client's selection of protocol to
any sniffing or intercepting middleware, while ALPN does leak this
information to middleware (as well as anyone on the network path).

From a communications privacy and robustness perspective, this is a
serious mark in favor of NPN.

Regards,

	--dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 12 Mar 2013 15:42:18 -0400

On 03/12/2013 03:26 PM, Alfredo Pironti wrote:
> This looks only superficially true to me. I agree NPN does protect the
> client choice against an occasional sniffer; however, a motivated
> attacker can mount a known version rollback attack to retrieve the
> value of that field (see
> http://www.ietf.org/mail-archive/web/tls/current/msg08909.html and
> followup for more details on the attack).

hm, good point, thanks for the reminder.

This seems to be a fundamental tension: If NPN or ALPN (or SNI, for that
matter) are used by the server to select which credentials to present in
the first place, then the client *cannot* prevent leaking information
about its desired peer to a MITM attacker who is willing to cause a
failed handshake to find out the information.

For servers which do not select their own credentials based on these
extensions, a client could be configured to make initial connections
without the extension, and then immediately renegotiate (supply the
desired extension during the renegotiation) upon confirming/verifying
the server's credentials/identity.  This incurs more round-trips, of
course, but it avoids leaking the information to an
as-yet-unauthenticated peer (and it doesn't seem to require any change
in the existing protocol, iiuc).

How commonly do people expect these extensions to be used by the server
to select alternate credentials?

Are there other practical defenses a client could take to defend itself
against an active MITM that is willing to cause a handshake failure to
extract this information?

	--dkg

---

From: Alfredo Pironti <[email-masked]>
Date: Tue, 12 Mar 2013 20:26:13 +0100

On one hand, decrypting that field once may be enough for a firewall
to block all future connections generated by the victim client; on the
other hand, a QoS system may have a hard time doing its job on all
connections.

Let me stress once more that the main point worrying me about NPN is
exactly this "false" sense of security that it gives.

Best,
Alfredo

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

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 13 Mar 2013 01:44:21 +0400

Hello

Using one of these two extensions, would it be possible to protect multiple
protocols over the established TLS session or only a single protocol will
be protected over that session?

Since we are using port 443 to run the protocol X, so I guess protocol X
traffic will be encapsulated into HTTP Requests/Responses before being
encrypted by TLS Record, true?

Best regards
Badra

On Tue, Mar 12, 2013 at 10:03 PM, <[email-masked]> wrote:

>  Hi,****
>
>  ****
>
> ALPN and NPN seem very close. Nevertheless they impact differently the
> performance and the complexity of migration scenario.****
>
>  ****
>
> More and more applications are being migrated over TLS. Consequently
> reverse proxies have to deal with more and more complex situations and need
> to know the application protocol to guide incoming TLS sessions toward the
> right servers. ALPN is very efficient because with ALPN a reverse proxy is
> able to start the resource selection immediately after the processing of
> the ClientHello. NPN is less efficient as the reverse proxy has to wait an
> additional TLS exchange before initiating the resource. ****
>
>  ****
>
> More and more applications are being partially or totally virtualized and
> carried over TLS. In these cases reverse proxies rely on information like
> Server Name Indication to select the server credential to return in the
> ServerHello. There are situations where the selection of the server
> credential requires the knowledge of the Server Name and of the Application
> Protocol. ALPN and SNI provide this information in time as there are both
> carried in the ClientHello. This is not possible with NPN as the
> Application Protocol is determined by the client after receiving the
> ServerHello. ****
>
>  ****
>
> Hope it helps the discussions.****
>
> Emile****
>
> ** **
>

---

From: Mohamad Badra <[email-masked]>
Date: Wed, 13 Mar 2013 02:00:20 +0400

Hi Christian,

> yes, it would be possible to protect multiple independent protocols.
>
>
If multiple protocols will be protected over a single TLS session, so how
to multiplex between these protocols' traffic?

> No, you won’t wrap these protocols in HTTP.****
>
> **
>

Got it. Thanks!
Best regards
Badra

> **
>
> *Von:* [email-masked] [mailto:[email-masked]] *Im Auftrag von
> *Mohamad Badra
> *Gesendet:* Dienstag, 12. März 2013 22:44
> *An:* [email-masked]
> *Cc:* [email-masked]
> *Betreff:* Re: [TLS] ALPN or NPN ?****
>
> ** **
>
> Hello****
>
> ** **
>
> Using one of these two extensions, would it be possible to protect
> multiple protocols over the established TLS session or only a single
> protocol will be protected over that session?****
>
> ** **
>
> encrypted by TLS Record, true?****
>
> ** **
>
> Best regards****
>
> Badra****
>
> ** **
>
> On Tue, Mar 12, 2013 at 10:03 PM, <[email-masked]> wrote:****
>
> Hi,****
>
>  ****
>
> _________________________________________________________________________________________________________________________****
>
> ** **
>
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc****
>
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler****
>
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,****
>
> France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.****
>
> ** **
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;****
>
> they should not be distributed, used or copied without authorisation.****
>
> If you have received this email in error, please notify the sender and delete this message and its attachments.****
>
> As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.****
>
> Thank you.****
>
>
> https://www.ietf.org/mailman/listinfo/tls****
>
> ** **
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Mar 2013 08:23:08 -0400

Firewall vendors love to add features to firewalls that allow blocking of content, even if that blocking is often harmful. If you don't believe me, walk down to your IT department and ask for a 15-minute tour of the UI on the corporate firewall.

If we go with ALPN, firewall vendors *will* add blocking of various applications as a firewall feature. Some IT departments will turn this on incorrectly, just as they turn on stuff now that makes network operations harder. (Fred Baker and I are writing a document in OPSAWG about this.)

Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary breakage of secure services.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Wed, 13 Mar 2013 13:32:14 +0000

[firewall vendor hat firmly on]

> Firewall vendors love to add features to firewalls that allow blocking of content, even if that blocking is often harmful. If you don't believe me, walk down to your IT department and ask for a 15-…

Agreed, but they don't do it because of our love of blocking things, but because those same IT department people would like to have fine-grained control over what does and does not pass the firewall.

> If we go with ALPN, firewall vendors *will* add blocking of various applications as a firewall feature.

They will add such a blocking feature regardless. With ALPN this can be done by observing the ClientHello. With NPN this requires being a transparent proxy, which inevitably lowers performance or throughput.

> Some IT departments will turn this on incorrectly, just as they turn on stuff now that makes network operations harder. (Fred Baker and I are writing a document in OPSAWG about this.)
> 

I don't think people would want to block, as long as NPN/ALPN is used only for distinguishing HTTP/1 from HTTP/2. But I can see this used in the future to mark other applications, such as SSL-VPN tunneling client, like Microsoft's SSTP, Cisco's "SSL VPN client", or my company's SNX. If a future firewall has a new feature for blocking tunneling clients, then that feature is going to work regardless of whether we choose NPN or ALPN. The only question is whether it's going to require being an SSL proxy or not. But if the IT people would like to block tunneling clients, and that requires activating an SSL proxy, then they will do it. 

This is not an argument for ALPN. If they really want to block tunneling clients, they have to decrypt the traffic anyway to validate that it's just regular web traffic. I'm just saying that the firewall users require control over everything that goes through the network. NPN will not be able to stop firewall vendors from supplying that kind of control.

Yoav

---

From: Adam Langley <[email-masked]>
Date: Wed, 13 Mar 2013 09:50:06 -0400

> They will add such a blocking feature regardless. With ALPN this can be done by observing the ClientHello. With NPN this requires being a transparent proxy, which inevitably lowers performance or t…

In the event that the client machines are controlled to the extent
that MITM certificates can be installed then you're certainly correct,
although one could equally well lock down the machine to prevent the
use of software that would ever try to send other protocols over TLS.

However, there is a huge gap between between that and sending it in
the clear.  As a browser vendor we observe almost every unfortunate
middlebox behaviour you can imagine. The first example that comes to
mind: there was a small ISP that blocked ECDHE ciphersuites. It's not
even clear why, but the ciphersuite is negotiated in the clear and
someone, knowingly or otherwise, filtered on it.

The inevitable result of a negotiation in the clear is that the
extension will fray around the edges in the same fashion. Perhaps not
for SPDY, which might make the whitelist, but other users will end up
paying the cost of weird behaviour at scale.

I could spend all day, every day, trying to debug the crazy network
behaviour that Chrome users suffer, esp with TLS. It's those lessons
that NPN is trying to learn from, although inevitably it trades away
other some benefits to do so.

Cheers

AGL

---

From: Alfredo Pironti <[email-masked]>
Date: Wed, 13 Mar 2013 13:42:52 +0100

> If we go with ALPN, firewall vendors *will* add blocking of various applications as a firewall feature. Some IT departments will turn this on incorrectly, just as they turn on stuff now that makes…

Is there any interest in a compromise solution? For example, sending
the NPN information *after* the Finished message. This adds one
round-trip, but makes the message exchange as secure as any other
application data. (In general, the idea would be to perform a further
round of negotiation after handshake completion.)

I'm not at all against NPN and the reasons behind it; I just feel a
bit uncomfortable with releasing a spec with a known security issue.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 13 Mar 2013 10:37:37 -0400

> [firewall vendor hat firmly on]

[firewall tester hat firmly on]

> Agreed, but they don't do it because of our love of blocking things, but because those same IT department people would like to have fine-grained control over what does and does not pass the firewal…

Noted. If you were an automaker, the fact that 1% of your customers want to be able to drive your car faster than 100 MPH in case of emergency, you would in fact make the car able to go that fast, but not include a way to test if the driver was an adolescent male in the proximity of other adolescent males. A feature is a feature.

> They will add such a blocking feature regardless. With ALPN this can be done by observing the ClientHello. With NPN this requires being a transparent proxy, which inevitably lowers performance or t…

This is a false dichotomy. All modern firewall vendors already have TLS proxyhing (which is only somewhat "transparent") as a feature already. If this WG chooses NPN or ALPN, that feature will still be there.

> I don't think people would want to block, as long as NPN/ALPN is used only for distinguishing HTTP/1 from HTTP/2. But I can see this used in the future to mark other applications, such as SSL-VPN t…

Correct.

> This is not an argument for ALPN. If they really want to block tunneling clients, they have to decrypt the traffic anyway to validate that it's just regular web traffic. I'm just saying that the fi…

We disagree about "the firewall users" and "require". A small number of firewall administrators have that requirement, but offering the filtering will cause more to do so.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Mar 2013 10:52:24 -0500

> Thus, I prefer NPN. I can live with ALPN, but it will cause unnecessary breakage of secure services.

+1 and +1 to Adam L.'s response to Yoav's.

Given my current and past roles at various organizations, I understand
the desire to perform deep filtering at various companies.  I believe
they should use MITM certs or else they should limit external access
greatly.  After all, users now have the ability to BYON -- they bring
their own network via 3G and 4G devices, so being much more extreme in
limiting external access is much less burdensome on users today.

(Of course, BYOD also means that data exfiltration via analog holes
and USB devices has become much more of a problem, but that was true
with or without BYON.  Where data exfiltration is a serious problem I
advocate much more strict device and network access policies.)

Nico
--

---

From: Xiaoyong Wu <[email-masked]>
Date: Wed, 13 Mar 2013 18:17:50 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Alfredo Pironti
> Sent: Wednesday, March 13, 2013 5:43 AM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: [TLS] ALPN or NPN ?
> 
> > Firewall vendors love to add features to firewalls that allow blocking of
> content, even if that blocking is often harmful. If you don't believe me, walk
> down to your IT department and ask for a 15-minute tour of the UI on the
> corporate firewall.
> >
> > If we go with ALPN, firewall vendors *will* add blocking of various
> > applications as a firewall feature. Some IT departments will turn this
> > on incorrectly, just as they turn on stuff now that makes network
> > operations harder. (Fred Baker and I are writing a document in OPSAWG
> > about this.)
> 
> Is there any interest in a compromise solution? For example, sending the
> NPN information *after* the Finished message. This adds one round-trip,
> but makes the message exchange as secure as any other application data. (In
> general, the idea would be to perform a further round of negotiation after
> handshake completion.)
> 
> I'm not at all against NPN and the reasons behind it; I just feel a bit
> uncomfortable with releasing a spec with a known security issue.

+1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message.

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Mar 2013 13:21:09 -0500

> +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message.

It can't be entirely after the Finished message.  The server at least
has to signal willingness to negotiate an application protocol after
the Finished message exchange, and we should not use a handshake
record for it (because then the presence of either re-nego or app
protocol nego will be obvious to middleboxes.

Nico
--

---

From: Alfredo Pironti <[email-masked]>
Date: Wed, 13 Mar 2013 19:33:09 +0100

> protocol nego will be obvious to middleboxes.

To some extent, I believe we are not trying to hide the usage of the
extension itself, but only its content. A simple sniffer would already
be able to tell if current NPN is used or not.

Alfredo

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 13 Mar 2013 15:06:19 -0400

> +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message.

It's worth remembering that there is actually a practical, real-world
distinction between "in the clear" and "accessible to a MITM who is
willing to cause a connection handshake to fail".

Client software can at least observe that the information leaked in the
latter case, and can advise the user.  (how helpful this is in the face
of a malicious adversary might be hard to assess without thinking
through the full user experience)

Note also that moving the NPN information after the Finished message is
already possible in some sense by doing a second handshake.  Or is there
some restriction on renegotiation that says you MUST not supply NPN on
subsequent handshakes if it was not supplied initially?

However, moving the NPN info after the handshake means that the server
won't have an opportunity to select different credentials based on the
NPN info.

	--dkg

---

From: Andrei Popov <[email-masked]>
Date: Wed, 13 Mar 2013 19:43:43 +0000

NPN draft (http://tools.ietf.org/id/draft-agl-tls-nextprotoneg-04.txt) says:
"  ... after a handshake has been performed for a
   given connection, renegotiations on the same connection MUST NOT
   include the "next_protocol_negotiation" extension."

So NPN extension cannot be used as part of a renegotiation on the same connection.
It looks like one can't have true confidentiality guarantees with NPN, as defined.

There is a broad spectrum of opinions in the WG regarding the need for hiding application protocol information:
- List of protocols and\or the negotiated protocol need to be truly confidential.
- It is enough to protect  application protocol data from passive MITM attack.
- Application protocol data should be visible to the network elements for optimal routing/accounting/filtering etc.

Clearly there are multiple scenarios that need to be supported. Perhaps it will be easier for all the parties involved to come to an agreement if we decouple the problem of negotiating an application protocol from the problem of making various contents of the TLS handshake confidential (or protected from passive attack, obfuscated, etc.)

There are separate proposals that address the confidentiality issue in a systemic way, such that the protection would apply not only to the application protocol data, but also the client cert, SNI information, etc. (see http://tools.ietf.org/id/draft-ray-tls-encrypted-handshake-00.txt is an example).

Cheers,

Andrei

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Daniel Kahn Gillmor
Sent: Wednesday, March 13, 2013 12:06 PM
To: Xiaoyong Wu
Cc: Paul Hoffman; Alfredo Pironti; [email-masked]
Subject: Re: [TLS] ALPN or NPN ?

> +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message.

It's worth remembering that there is actually a practical, real-world distinction between "in the clear" and "accessible to a MITM who is willing to cause a connection handshake to fail".

Client software can at least observe that the information leaked in the latter case, and can advise the user.  (how helpful this is in the face of a malicious adversary might be hard to assess without thinking through the full user experience)

Note also that moving the NPN information after the Finished message is already possible in some sense by doing a second handshake.  Or is there some restriction on renegotiation that says you MUST not supply NPN on subsequent handshakes if it was not supplied initially?

However, moving the NPN info after the handshake means that the server won't have an opportunity to select different credentials based on the NPN info.

	--dkg

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Mar 2013 16:11:32 -0500

> subsequent handshakes if it was not supplied initially?

The 'type' field of all records goes in the clear.  The fact that
re-negotiation is happening is visible.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Mar 2013 16:13:35 -0500

It might not be a bad idea to negotiate hiding the record type by
moving the real record type into the the encrypted payload (into the
plaintext to be encrypted).

Nico
--

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 13 Mar 2013 17:18:08 -0400

> plaintext to be encrypted).

tcpmux [0] over TLS ?  It's certainly doable (at the cost of more round
trips).  Of course, the server couldn't use this to select among a set
of credentials to offer in this model.

	--dkg

[0] https://tools.ietf.org/html/rfc1078

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 13 Mar 2013 17:44:27 -0400

On 03/13/2013 05:35 PM, Nico Williams wrote:
> On Wed, Mar 13, 2013 at 4:18 PM, Daniel Kahn Gillmor <[email-masked]> wrote:
> No.  Just the record type, as in hadnshake vs. application vs. alert.

ah, sorry, i'd misunderstood you.  if an alert about failure of the
encryption layer, stuffing it inside the failing encryption layer seems
like a chicken-and-egg problem.  Otherwise, i think this would be a
worthwhile extension to consider.  It certainly avoids some established
leaks about the state of the session.

> Muxing multiple application protocols over one TLS connection might
> well be interesting, but brings up the whole SSHv1/v2 multiplexing
> experience -i.e., lots of problems-, so I'd rather stay away from
> that.

fwiw, tcpmux doesn't multiplex multiple applications over a single TLS
connection -- it is just a well-defined (archaic) way to allow a single
port to serve multiple different protocols -- but only one per TCP
session (or in this case, one per TLS connection).

	--dkg

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Mar 2013 16:35:24 -0500

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Mar 2013 17:20:43 -0500

> leaks about the state of the session.

Sure.

> session (or in this case, one per TLS connection).

Ah, that, yes, but that's pretty much what NPN is, isn't it.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 00:53:00 +0000

> +1 on this. A false sense of security is no better than no security. If we believe the NPN information is sensitive and should be protected, we should have this after the Finished message.

I don't believe that the NPN information is sensitive. At this point, there is only one interesting value: HTTP/2, and maybe HTTP/1. And those two kinds of connections should be easy to distinguish by traffic analysis. Also, knowing which version of HTTP someone uses, is not a particularly interesting piece of information for the attacker to get. It's only if different services begin to use this information that things become interesting, but still I don't see any point to this. Suppose we choose NPN, and the server advertises HTTP/1.1, HTTP/2.0, and SSTP. What advantage does the attacker lose by not knowing which one the client chose? If anything, this comprehensive list exposes more information about the server than would be exposed by ALPN: If a browser connects to this server, NPN exposes all three services, while ALPN does not expose SSTP (which the browser won't show).

So I believe that NPN offers no security advantage. As a lazy implementer, ALPN requires less code change, and less changes to the state machine.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 01:04:51 +0000

> Noted. If you were an automaker, the fact that 1% of your customers want to be able to drive your car faster than 100 MPH in case of emergency, you would in fact make the car able to go that fast,…

That's pretty much what all automakers do. The speedometer on my car goes to 220 KM/h (137 MPH), although considering how it handles at 100 KM/h this seems more like wishful thinking on Fiat's part than anything to do with reality.

> This is a false dichotomy. All modern firewall vendors already have TLS proxyhing (which is only somewhat "transparent") as a feature already. If this WG chooses NPN or ALPN, that feature will stil…

They do, but they only activate it if the features that are enabled require it. So if you turn on URL filtering based only on IP addresses and host names, these can be filtered without proxying. If you filter by deeper parts of the path, you have to proxy. 

> We disagree about "the firewall users" and "require". A small number of firewall administrators have that requirement, but offering the filtering will cause more to do so.

If vendors went by what customers are asking for, Apple would never release a capacitative touch-screen phone without a physical keyboard or a stylus. Once they did, everybody else also released phones with similar properties. Firewalls block SPDY now, not because customers demand it, but to get the browsers to fall back to HTTP/1, which they have parsers for. This will change as firewall vendors develop parsers for HTTP/2, but the capability to block will remain regardless of what signaling mechanism we choose.

That's why I think we should ignore the threat of firewalls, and concentrate on what is best for TLS in terms of round-trips, latency and implementation convenience vs the alleged security gain from hiding chosen application from Eve.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Wed, 13 Mar 2013 23:00:14 -0500

On Wed, Mar 13, 2013 at 9:13 PM, Peter Gutmann
<[email-masked]> wrote:
> Nico Williams <[email-masked]> writes:
>>It can't be entirely after the Finished message.  The server at least has to
>>signal willingness to negotiate an application protocol after the Finished
>>message exchange, and we should not use a handshake record for it (because
>>then the presence of either re-nego or app protocol nego will be obvious to
>>middleboxes.
>
> This got discussed to some extent among some TLS folks at the RSA conference a
> week or so back, rather than having a specific NPN facility we should really
> be thinking about a generalised mechanism to allow extensions to additionally
> be specified once the handshake has entered the encrypted phase.  In other
> words there's an insecure-extensions negotiation during the handshake, and a
> secure-extension negotiation after the handshake has completed.  The analogy
> used was STARTTLS, you negotiate any initial options before you switch to TLS,
> and then renegotiate anything critical inside the TLS security envelope.  The
> use of the standard extension mechanism allows them to be handled identically
> to the way extensions are already done, and doesn't limit things to only
> dealing with NPN.

Count me as all for this, as long as it's coupled with not leaking
that the records following the handshake are also handshake records.
We could even have a fast second handshake that requires just half a
round trip, something like this:

 - ClientHello says "I support protecting the the record type"
 - ServerHello says "I support protecting the record type", and "I
support negotiation of application protocols (optionally: and also
these applications: X, Y, and Z)"
 - <handshake continues and finishes>

 - Client sends a new handshake message saying "No need to do a new
handshake, but I want to speak application protocol X", and then sends
an application record

 - if the server doesn't support application protocol X it replies
with a [protected] alert record saying as much and optionally listing
supported application protocols, which gives the client a chance to
try some other protocol.

This costs no extra round trips and is exceedingly simple.
Middleboxes will see the client and server advertise this feature but
won't know which application protocol, if any, the two negotiate
(unless the middleboxes are MITM middleboxes).

Nico
--

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 14 Mar 2013 09:29:03 +0200

> That's why I think we should ignore the threat of firewalls, and concentrate on what is best for TLS in terms of round-trips, latency and implementation convenience vs the alleged security gain fro…

I have to say I agree with this. If there is something in ClientHello extensions that needs to be protected, then it should be handled by renegotiation. If not, then the functionality should be kept as simple as possible.

Everything else in TLS works so that the server does not leak information of its support of ciphers or TLS versions. I don't see why this single case should work the other way around. If this is considered a problem, we should have a seperate extension that tries to work around firewalls as much as possible.

Juho

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 11:17:11 +0000

> Everything else in TLS works so that the server does not leak information of its support of ciphers or TLS versions. I don't see why this single case should work the other way around. If this is co…

To be fair, what the server supports is hardly a secret. An attacker can do like SSL pulse, and attempt multiple handshakes with the server, specifying a single ciphersuite/TLS version/Application each time, and get a comprehensive list of everything that the server supports.

I still think it's an irrelevant leak, with such a small label space.

Yoav

---

From: Tom Ritter <[email-masked]>
Date: Thu, 14 Mar 2013 09:46:52 -0400

On 14 March 2013 03:29, Juho Vähä-Herttua <[email-masked]> wrote:
> If this is considered a problem, we should have a seperate
> extension that tries to work around firewalls as much as possible.

We do, it's just not in this Working Group.  It's over here:
http://tools.ietf.org/html/draft-ietf-websec-key-pinning-04#section-2.1.4

I remain convinced that hiding as much information from passive
eavesdroppers is a worthwhile goal.  The least ambitious at this point
would be NPN. Then the suggestion to do a second, encrypted
information negotiation came up - again.  When we talked about
Encrypted Client Certs, we seemed to have punted it to "Encrypted
Handshake" (or whatever you want to call it) and now it's coming up
again after dying down.

Quoting Yoav:
> I don't think people would want to block, as long as NPN/ALPN is used only
> for distinguishing HTTP/1 from HTTP/2. But I can see this used in the future
> to mark other applications, such as SSL-VPN tunneling client, like
> Microsoft's SSTP, Cisco's "SSL VPN client", or my company's SNX. If a future
> firewall has a new feature for blocking tunneling clients, then that feature
> is going to work regardless of whether we choose NPN or ALPN. The only
> question is whether it's going to require being an SSL proxy or not. But if
> the IT people would like to block tunneling clients, and that requires
> activating an SSL proxy, then they will do it.

If "They" is corporate IT: of course they will, and it will be easy
for them to do so.  But "They" is also entities without that control
over their users. In the small scale: coffee shops that use a box to
break into HTTP streams to add in ads.  Why not block VPNs, so I can
put in more ads? Or in the large scale: countries (like Iran and
China) who block VPNs so they can inspect what their citizens are
doing, and look for the activists and reporters.

Everything is moving into TLS today, so we have to consider more than
just web traffic in a home or corporate network.  By being
conservative in what we expose (and eventually making a generic
encrypted extension mechanism, among other ideas) we will keep TLS
more flexible as the general purpose protocol it is, and will result
in fewer people hacking and working around it to do what they want.

The fact that the label space is small today is not considering where
it will go in the future.

-tom

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 14 Mar 2013 08:06:26 -0600

In my experiences, particularly in the last half-dozen years at IBM, if an enterprise cares about security, they terminate SSL/TLS in their DMZ. They do not allow encrypted connections from the outside to come directly into their internal systems.  Am I alone in this view? Has anyone thought about how ALPN/NPN would function in such an environment?

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 14:18:38 +0000

> In my experiences, particularly in the last half-dozen years at IBM, if an enterprise cares about security, they terminate SSL/TLS in their DMZ. They do not allow encrypted connections from the out…

So if the actual server is in the DMZ, it works as usual. This is often done with publicly-facing web servers, and sometimes mail servers. In that case, it doesn't matter whether you use ALPN or NPN. Of course the firewalls that protect DMZs (or internal servers) often have the private keys for the internal servers, so that they can decrypt the traffic and the handshake. In that case, neither ALPN nor NPN hinder them in the least.

The other case is when the server is internal, and the DMZ just has a proxy that translates HTTPS to HTTP (and potentially does some sanity checks). I don't see why this case is different.

Yoav

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 14 Mar 2013 08:27:15 -0600

> So if the actual server is in the DMZ, it works as usual.

Well, kinda, although it presumably requires more cooperation (configuration) with the true backend services so that the middleman knows what to advertise and allow

> The other case is when the server is internal, and the DMZ just has a proxy that translates HTTPS to HTTP (and potentially does some sanity checks). I don't see why this case is different.

Actually it wouldn't work, would it? How would you convert NPN/ALPN into HTTP?

	/r$

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 15:07:10 +0000

> Actually it wouldn't work, would it? How would you convert NPN/ALPN into HTTP?

NPN or ALPN are TLS features. The clear side would be either HTTP/1 or HTTP/2. Both will be possible in the clear. The proxy only needs to know which version of HTTP is supported.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 14 Mar 2013 10:16:34 -0500

> NPN or ALPN are TLS features. The clear side would be either HTTP/1 or HTTP/2. Both will be possible in the clear. The proxy only needs to know which version of HTTP is supported.

Only HTTP?  Forever?  Then why not make the protocol identifier be a small integer?

If the answer is not, then should we define the common X-... convention?

	/r$

---

From: [email-masked] (Martin Rex)
Date: Thu, 14 Mar 2013 18:03:19 +0100 (CET)

> won't have an opportunity to select different credentials based on the

That is both an obvious hen-and-edd problem:

- the server cert goes first in the clear and is a prerequisite
  for the key exchange

- if the server selects a different server credential based on NPN,
  then the observer could deduce from the server's choice of certificate
  what the NPN was, even if the NPN was not visible to the observer.

-Martin

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 14 Mar 2013 20:20:35 +0200

> doing, and look for the activists and reporters.

Having also lived several years in mainland China I'm more than familiar with these issues.

The problem with NPN is that if it's possible to see an undesired protocol (e.g. VPN) in the Server Hello, as an attacker I would simply sniff for ServerHello packets and shut down the connection with a RST from a spoofed source IP if I don't like the contents. I can do this passively without slowing down the connection at all, which means it's really cheap.

This is actually worse than cutting down the connection based on ClientHello, because of the collateral damage for protocols that are otherwise not blocked at all. And if the server has to fake or omit the list of supported protocols, the whole point of the list becomes questionable.

Based on the very good points brought up in this discussion, I would change my vote to NPN with the optional list of protocols removed from the server next_protocol_negotiation extension. I know it makes the protocol selection less flexible, but if we really want to prevent firewall blocking, I don't see much other options than making the whole NPN negotiation encrypted. The attacker can still shut down based on the presence of NPN extension in ServerHello, but if it the extension becomes more common in servers that will be difficult.

Please give some feedback if I'm on the wrong track here.

Juho

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2013 13:26:55 -0500

> This is actually worse than cutting down the connection based on ClientHello, because of the collateral damage for protocols that are otherwise not blocked at all. And if the server has to fake or…

But we've also seen that for certain high-value, HTTPS-only sites, the
great wall operators end up giving up (gmail, github, ...).

Nico
--

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 14 Mar 2013 20:41:40 +0200

> great wall operators end up giving up (gmail, github, ...).

Getting slightly off-topic, but I believe HTTPS sites are usually blocked only based on DNS/IP, not based on the actual content. If the concern here is 3rd parties blocking VPN access and VPNs using NPN (two pretty big assumptions), I doubt the high-value sites like gmail and github will suddenly start advertising VPN support on their main HTTPS servers. If they do not, blocking VPN supporting servers is still quite viable.

Juho

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2013 13:52:32 -0500

> Getting slightly off-topic, but I believe HTTPS sites are usually blocked only based on DNS/IP, not based on the actual content. If the concern here is 3rd parties blocking VPN access and VPNs usin…

All they have to do is advertise the ability to negotiate
application-layer protocols.  That's enough.  If a client proceeds
past the end of the handshake and tries to start the "VPN" (or
whatever) protocol and that fails because the server doesn't support,
what's the harm?  The harm will only be that the client needed more
round trips to _fail_, but that's no big deal considering the benefits
when the client succeeds: the client gets what it wants and non-MITM
middleboxes don't know what that was.

Nico
--

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Thu, 14 Mar 2013 20:59:17 +0200

> middleboxes don't know what that was.

I guess this is my point. If we want to prevent firewalls from blocking, it would be best if no application-layer protocol information would be transferred in plain text at all. As I understand this is not the case with the current NPN draft, which includes a plain text (although optional) list of supported protocols.

Juho

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2013 14:11:28 -0500

> I guess this is my point. If we want to prevent firewalls from blocking, it would be best if no application-layer protocol information would be transferred in plain text at all. As I understand thi…

Before your message I'd have been OK with a server advertising a list
of many application protocols in the clear, but it'd have to be
OPTIONAL and indeed, NOT RECOMMENDED.  You convince me that it's best
to not advertise any specific protocols, just the feature.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 14 Mar 2013 20:14:43 +0000

> Please give some feedback if I'm on the wrong track here.

When clients want to hide their identity, they make an anonymous (or server-authenticated) handshake, and then perform a second handshake, this time with the client certificate.

You could do the same thing with ALPN (or NPN, but in this case NPN has no advantage). You do a regular handshake without ALPN (or with an indication that ALPN is supported - ALPN message with no applications). The interior handshake can have the ALPN extension with application names.

So it would be up to the client to expose the applications in the ClientHello, or go for a second handshake. It's a tradeoff of performance vs secrecy. 

I can think of a slight optimization: usually renegotiations are not allowed to resume the session. In this case (of empty ALPN) we could allow this.

I still think it would be better for browsers at least, to save the roundtrip and have the ALPN list in the ClientHello. Tunneling clients may have different priorities.

Yoav

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2013 15:23:49 -0500

> When clients want to hide their identity, they make an anonymous (or server-authenticated) handshake, and then perform a second handshake, this time with the client certificate.

Most clients don't use user certs in TLS for authentication anyways,
so I'm not sure how this is relevant.  Clients that do can
re-negotiate, of course, but this is externally evident because of the
record type appearing in the clear.  IIUC there exist great walls that
reset TCP connections where TLS re-nego happens.

Clients could re-nego even if they don't use client certs -- just to
protect the app protocol negotiation.  But this adds more round trips
than is absolutely necessary (see my alternative proposal).

> I still think it would be better for browsers at least, to save the roundtrip and have the ALPN list in the ClientHello. Tunneling clients may have different priorities.

But this will make it trivial for great walls to kill those connections.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 14 Mar 2013 21:39:25 +0100

> Getting slightly off-topic, but I believe HTTPS sites are usually blocked only based on DNS/IP, not based on the actual content. If the concern here is 3rd parties blocking VPN access and VPNs usin…

I think it is important to decide first what we want from this
extension. As I understand ALPN and NPN do exactly the same thing, they
negotiate the protocol to be used under TLS, but one proposal offers
something more. Some kind of privacy in that negotiation against passive
eavesdroppers.

The question is, do we need that additional privacy, along with its
added complexity (because a totally new negotiation mechanism is added).
In my opinion, the added complexity of NPN by not using the standard TLS
extension mechanism is a big drawback and I really cannot see the
offered privacy as an important advantage. Moreover, I can see the
disadvantage of administrators not being able to prioritize bulk from
interactive traffic. Do we really need to negotiate the protocol under
TLS in a totally hidden way or do we want to negotiate the protocols
under TLS similarly to what happens now (e.g. with different port numbers)?

People who would like to hide their protocol would do that, and would
falsely advertise HTTP as they do now (by using port 443 to transfer
arbitrary data). I see no advantage to them from NPN.

If the threat on the other hand are misconfigured or misadministered
firewalls, I don't know what the TLS WG can do to prevent that, except
making a clear specification that firewall makers will understand and
not abuse.

In short I support the ALPN proposal, because it is cleaner.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2013 15:47:01 -0500

> added complexity (because a totally new negotiation mechanism is added).

We may be able to get that additional privacy without that complexity.
 We should decide whether we want the additional privacy without
concern about the complexity until we then convince ourselves that we
cannot obtain such additional privacy without too much additional
complication.

I just made a third proposal that I think obtains that additional
privacy with less complexity.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 14 Mar 2013 22:10:46 +0100

> privacy with less complexity.

My main question is whether do we really need that additional privacy? I
am not convinced by the current answers to that question, and I see
several advantages when that information is disclosed (e.g. networking
policies are enforced the same way as they are today).

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Thu, 14 Mar 2013 16:20:50 -0500

> policies are enforced the same way as they are today).

Do we want additional privacy?  I believe we *should*.  We should
always want all the privacy protection that we can get at a low enough
price, and so the question is: can we pay a low-enough price for
privacy protection of application protocol negotiation?

I think it's reasonable to think that NPN is too complex.  I don't
think it's reasonable to reject this feature without looking at
whether there are less complex ways of getting it.

I made a proposal that I think is very simple and gets us that privacy
protection.

Nico
--