Subject: Re: [TLS] Network Tokens I-D and TLS / ESNI

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Wed, 29 Jul 2020 01:40:26 +0000

Hi everyone,

Just a quick follow-up that there will be the following talks on Wednesday and Thursday around network tokens.

* 

July 29 , 1:00-1:50pm UTC: TSV Open Meeting

* 

July 30 , 12:30pm-2:00pm UTC: APN Side Meeting

* 

July 30 , 4pm-5pm UTC: Network Tokens Side Meeting (details available here) ( https://github.com/Network-Tokens/network-tokens-rfc/wiki/IETF-108---Network-Tokens-Side-Meeting )

Best,

Yiannis

On Fri, Jun 26, 2020 at 10:42 AM, Christian Huitema < [email-masked] > wrote:

> 
> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
> 
> 
>> 
>> 
>> 
>> 
>> 
>> On Fri, Jun 26 , 2020 at 7:29 AM, Christian Huitema < huitema@ huitema. net
>> ( [email-masked] ) > wrote:
>> 
>>> 
>>> 
>>> On 6/25/2020 11:11 PM, Melinda Shore wrote:
>>> 
>>> 
>>> 
>>>> 
>>>> 
>>>> On 6/25/20 3:29 PM, Erik Nygren wrote:
>>>> 
>>>> 
>>>> 
>>>>> 
>>>>> 
>>>>> One quick comment is that binding tokens to IP addresses is strongly
>>>>> counter-recommended.
>>>>> It doesn't survive NATs or proxies, mobility, and it is especially
>>>>> problematic in IPv6+IPv4 dual-stack environments.
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> There's been a bunch of past work done developing similar sorts of
>>>> protocols, and for what it's worth I wrote up a mechanism for using
>>>> address tags and address rewrites, but unfortunately Cisco decided to
>>>> patent it. Anyway, there are ways of dealing with this problem that don't
>>>> require binding the address to the token ("all technical problems can be
>>>> solved by introducing a layer of indirection").
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> There is also an interesting privacy issue. The token is meant to let a
>>> provider identify some properties of the connection. I suppose there are
>>> ways to do that without having it become a unique identifier that can be
>>> tracked by, well, pretty much everybody. But you have better spell out
>>> these ways.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> You are right that for the duration of a token, one could use it to
>> identify an endpoint (either application or most likely a combination of
>> user/application). Tokens expire and intermediary nodes cannot correlate
>> tokens with each other as they are encrypted. So tracking cannot happen
>> across different tokens (of the same user), or between token-enabled and
>> non-token-enabled traffic. I guess similar type of tracking happens when
>> users are not behind a NAT and their IP address can be used to track them.
>> Would it make sense to have the user add a random value to a token, and
>> then encrypt it with the network's public key, so that each token becomes
>> unique and cannot be tracked. Would that address the privacy concerns
>> better?
>> 
>> 
> 
> 
> 
> That would certainly be better. The basic rule is that any such identifier
> should be used only once. Pretty much the same issue as the session resume
> tickets.
> 
> 
> 
>> 
>> 
>> 
>>> 
>>> 
>>> Then, there are potential interactions with ESNI/ECH. The whole point of
>>> ECH is to keep private extensions private. The token extension would need
>>> to be placed in the outer envelope, which is public but does not expose
>>> seemingly important information like the SNI or the ALPN.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> Ah, I was not aware that ESNI can now include all CH extensions - thanks
>> for the pointer. Yes, the token would have to stay on the outer envelope
>> so the network can process it. The main idea is you can encrypt everything
>> that is client-server specific, and just keep a token to explicitly
>> exchange information with trusted networks.
>> 
>> 
>> 
>> 
>>> 
>>> 
>>> There are also implications for QUIC, in which the TLS data is part of an
>>> encrypted payload. The encryption key of the TLS carrying initial packets
>>> is not secret in V1, but it might well become so in a future version.
>>> 
>>> 
>>> 
>>> 
>> 
>> 
>> 
>> Haven't looked into QUIC yet, but is on the list of things to do. If
>> anyone is interested to help us explore this, please let me know.
>> 
>> 
> 
> 
> 
> You may want to have that discussion in the QUIC WG. If you are building
> some kind of QoS service, you probably want it to work with QUIC too.
> 
> 
> 
> 
> -- Christian Huitema
> 
> 
> 
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 29 Jul 2020 16:48:33 -0400

This proposal is highly ossifying.  Application protocols that are included
in this scheme become very difficult to update.  For example, in the case
of zero-rating, this proposal would only be able to zero-rate application
protocols that are understood by the network's token-parsing appliance.
This seems likely to have serious negative consequences for protocol
innovation, as these applications would no longer be able to implement
novel protocols without losing whatever advantage the network token
offers.  For TLS, this proposal would ossify the extension format, which
could no longer evolve in future TLS versions without risking loss of
network services.  The proposal also violates the TLS Protocol Invariants,
by attempting to process the ServerHello after forwarding an arbitrary
ClientHello.  It would also fail for QUIC, as previously noted, due to
QUIC's mobility support, which is important for performance on mobile
devices.

Additionally, storing this information in the TLS handshake causes an
unnecessary privacy loss: it forces the token to be visible across the
whole internet, even though it is only relevant on the near-client network
segment.  Even if the token is entirely opaque, a pervasive surveillance
adversary could distinguish between connections with and without tokens,
likely differentiating certain applications from others.

I recommend that the authors focus on the draft's proposal to use an IPv6
extension header, and remove the other proposed encapsulations.  Also,
please remove the specific extension number from Section 7.1 unless and
until IANA has allocated a number.  For testing, you should use a value
from the Private Use range, 65282-65535.

On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema <[email-masked]>
wrote:

> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <[email-masked]>
> wrote:
>
>> protocols, and for what it's worth I wrote up a mechanism for using address
>> tags and address rewrites, but unfortunately Cisco decided to patent it.
>> Anyway, there are ways of dealing with this problem that don't require
>> binding the address to the token ("all technical problems can be solved by
>> introducing a layer of indirection").
>>
> for the pointer. Yes, the token would have to stay on the outer envelope so
> the network can process it. The main idea is you can encrypt everything
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Yiannis Yiakoumis" <[email-masked]>
Date: Wed, 29 Jul 2020 23:51:15 +0000

Hi Ben,

Thanks for your comments. Please find some responses inline.

On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz < [email-masked] > wrote:

> 
> This proposal is highly ossifying.  Application protocols that are
> included in this scheme become very difficult to update.  For example, in
> the case of zero-rating, this proposal would only be able to zero-rate
> application protocols that are understood by the network's token-parsing
> appliance.  This seems likely to have serious negative consequences for
> protocol innovation, as these applications would no longer be able to
> implement novel protocols without losing whatever advantage the network
> token offers.  For TLS, this proposal would ossify the extension format,
> which could no longer evolve in future TLS versions without risking loss
> of network services.
> 
> 

In an ideal world, everything beyond IP would be encrypted and opaque to the network, and network tokens would be embedded in IPv6 extension headers. In practice, this has several (well-known) issues, here is my take on the trade-offs:

Tokens as IPv6 extension headers have the benefit that they are applicable to all traffic/applications, and could potentially be enforced by the network in a stateless, per-packet manner. The problems are that i) IPv6 extension headers are often dropped by network operators, ii) there are no good APIs to expose L3 socket APIs to the app developers who would eventually acquire and insert tokens, and iii) it doesn't work with IPv4.

Tokens as TLS extensions address the major shortcomings for IPv6, i.e., they have integrity protection so they cannot be dropped by intermediary nodes, they are closer to the app developer and can therefore expose APIs for them to add/remove tokens, and iii) they work across both IPv4 and IPv6. Obviously, they will support only the specific type of transport which limits the scope.

Specifically on your comment about protocol innovation, and using ESNI as an example: my understanding, is that dependency on existing network services will be an issue for ESNI adoption, and I agree that this is frustrating. I will counter argue though, that the problem is not that the network appliance doesn't adopt to a new format or novel protocol, but rather that there is no protocol and means in place for endpoints to explicitly coordinate with the network. In that sense, having a thin mechanism to do this coordination can accelerate innovation in all other aspects.

Does the group have any sense on the impact of existing DPI-based services on adoption of new ideas on TLS?

Also note that something like network tokens would be implemented in programmable hardware and/or software, and in principle should be much quicker to adopt to format changes comparing to fixed-silicon appliances.

> 
> The proposal also violates the TLS Protocol Invariants, by attempting to
> process the ServerHello after forwarding an arbitrary ClientHello.
> 
> 

Not sure I understand this. Can you explain what you mean by arbitrary ClientHello, or point me to the related TLS section?

> 
> It would also fail for QUIC, as previously noted, due to QUIC's mobility
> support, which is important for performance on mobile devices.
> 
> 

Not very familiar with QUIC, will have to read on this.

> segment.

The token is not necessarily relevant only to the near-client network segment. For example, in a zero-rating scenario where the token comes from the server, there are intermediary networks that are not relevant for charging.

> 
> Even if the token is entirely opaque, a pervasive surveillance adversary
> could distinguish between connections with and without tokens, likely
> differentiating certain applications from others.
> 
> 

You can already infer use of applications just by using IP addresses. Also, the amount of information you can extract from the presence of tokens decreases rapidly with the number of users that participate in them.

> from the Private Use range, 65282-65535.

OK - I'll pick one from them private range - thanks.

Best,

Yiannis

> 
> On Fri, Jun 26, 2020 at 1:43 PM Christian Huitema < huitema@ huitema. net (
> [email-masked] ) > wrote:
> 
> 
>> 
>> 
>> 
>> 
>> 
>> TLS@ ietf. org ( [email-masked] )
>> 
>> https:/ / www. ietf. org/ mailman/ listinfo/ tls (
>> https://www.ietf.org/mailman/listinfo/tls )
>> 
>> 
> 
>

---

From: Tom Herbert <[email-masked]>
Date: Wed, 29 Jul 2020 18:28:16 -0700

On Wed, Jul 29, 2020 at 4:51 PM Yiannis Yiakoumis <
[email-masked]> wrote:

> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz <[email-masked]> wrote:
>
>> which could no longer evolve in future TLS versions without risking loss of
>> network services.
>>
>
> In an ideal world, everything beyond IP would be encrypted and opaque to
> the network, and network tokens would be embedded in IPv6 extension
> headers. In practice, this has several (well-known) issues, here is my take
> on the trade-offs:
>
> Tokens as IPv6 extension headers have the benefit that they are applicable
> to all traffic/applications, and could potentially be enforced by the
> network in a stateless, per-packet manner. The problems are that i) IPv6
> extension headers are often dropped by network operators, ii) there are no
> good APIs to expose L3 socket APIs to the app developers who would
> eventually acquire and insert tokens, and iii) it doesn't work with IPv4.
>
> Tokens as TLS extensions address the major shortcomings for IPv6, i.e.,
> they have integrity protection so they cannot be dropped by intermediary
> nodes, they are closer to the app developer and can therefore expose APIs
> for them to add/remove tokens, and iii) they work across both IPv4 and
> IPv6. Obviously, they will support only the specific type of transport
> which limits the scope.
>
> A major drawback of using TLS for this is that it requires the network to
maintain per flow state.

> Specifically on your comment about protocol innovation, and using ESNI as
> an example: my understanding, is that dependency on existing network
> services will be an issue for ESNI adoption, and I agree that this is
> frustrating. I will counter argue though, that the problem is not that the
> network appliance doesn't adopt to a new format or novel protocol, but
> rather that there is no protocol and means in place for endpoints to
> explicitly coordinate with the network. In that sense, having a thin
> mechanism to do this coordination can accelerate innovation in all other
> aspects.
>
> Also note that something like network tokens would be implemented in
> programmable hardware and/or software, and in principle should be much
> quicker to adopt to format changes comparing to fixed-silicon appliances.
>
> Not sure I understand this. Can you explain what you mean by arbitrary
> ClientHello, or point me to the related TLS section?
>
> The token is not necessarily relevant only to the near-client network
> segment. For example, in a zero-rating scenario where the token comes from
> the server, there are intermediary networks that are not relevant for
> charging.
>
> You can already infer use of applications just by using IP addresses.
> Also, the amount of information you can extract from the presence of tokens
> decreases rapidly with the number of users that participate in them.
>
>>> That would certainly be better. The basic rule is that any such
>>> identifier should be used only once. Pretty much the same issue as the
>>> session resume tickets.
>>>
>>>
>>> There are also implications for QUIC, in which the TLS data is part of
>>>> an encrypted payload. The encryption key of the TLS carrying initial
>>>> packets is not secret in V1, but it might well become so in a future
>>>> version.
>>>>
>>>
> --
> Network-tokens mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/network-tokens
>

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 29 Jul 2020 22:09:14 -0400

On Wed, Jul 29, 2020 at 7:51 PM Yiannis Yiakoumis <
[email-masked]> wrote:

> extension headers are often dropped by network operators,
>

In all the listed use cases, the client-proximate network operator is the
one who wants the tokens, so they can choose not to drop them.

> ii) there are no good APIs to expose L3 socket APIs to the app developers
> who would eventually acquire and insert tokens,
>

I appreciate that this is an obstacle, but I don't see a need to rush this
capability.  If there is demand for the feature, the APIs will be written.
Also, v6 extension headers are not the only way to get the right routing
properties.

and iii) it doesn't work with IPv4.

Making this feature v6-only is not very limiting.  Networks that want to
support it just have to be dual-stack, which they should be anyway, and
apps need to use IPv6, which they should support anyway.  Even v6-only ISPs
are already common, so by the time this specification is ready it won't be
too much to require dual-stack for participating apps and networks.

> services will be an issue for ESNI adoption,
>

I am not aware of an impediment to ESNI adoption.  Moreover, since ESNI
(now called "ECH") is entirely within the TLS Protocol Invariants, any
entity that would create such a problem is already in violation.

and I agree that this is frustrating. I will counter argue though, that the
> problem is not that the network appliance doesn't adopt to a new format or
> novel protocol, but rather that there is no protocol and means in place for
> endpoints to explicitly coordinate with the network.
>

There is: the Internet Protocol!  (Also ICMP, DHCP, PCP, and many others.
PCP (RFC 6887) seems like it might be a particularly good fit for Network
Tokens.)

In that sense, having a thin mechanism to do this coordination can
> accelerate innovation in all other aspects. Does the group have any sense
> on the impact of existing DPI-based services on adoption of new ideas on
> TLS?
>

> quicker to adopt to format changes comparing to fixed-silicon appliances.

I think most experienced members of the TLS group would tell you that
deployed appliance firmware has empirically updated very slowly, if at
all.  For comparison, TLS 1.3 went through 29 revisions in four years,
breaking compatibility frequently along the way.  In the world you're
describing, apps that use network tokens would potentially have been
excluded from field-testing those versions.  That field-testing was crucial
in the development of the final standard, largely because of the presence
of buggy systems that made assumptions specific to TLS 1.2.

Protocol changes with Network Tokens are especially delicate because
failure is largely expected to be silent.  That means if some ISP's token
inspector doesn't handle the app's protocol properly, the app never finds
out.  In the zero-rating case, the app would continue to work as normal,
silently running up the user's bill, likely in violation of a written
promise to the user.  App developers would have to be exceptionally
cautious when making protocol changes.  That's ossification.

> ClientHello, or point me to the related TLS section?

RFC 8446 Section 9.3:
   -  A middlebox which forwards ClientHello parameters it does not
      understand MUST NOT process any messages beyond that ClientHello.
      It MUST forward all subsequent traffic unmodified.  Otherwise, it
      may fail to interoperate with newer clients and servers.

      Forwarded ClientHellos may contain advertisements for features not
      supported by the middlebox, so the response may include future TLS
      additions the middlebox does not recognize.  These additions MAY
      change any message beyond the ClientHello arbitrarily.  In
      particular, the values sent in the ServerHello might change, the
      ServerHello format might change, and the TLSCiphertext format
      might change.

> Not very familiar with QUIC, will have to read on this.

See here: https://tools.ietf.org/html/draft-ietf-quic-transport-29#section-9

After the TLS handshake, QUIC connections can migrate across client IPs and
interfaces without redoing the handshake.  IPv6 extension headers would
allow tagging the packets appropriately for the network they're on, but
tagging the connection in the handshake is impossible.

> the server, there are intermediary networks that are not relevant for

Yes, the tagging has to be handled by the client in this scenario.  That
seems sufficient for all the listed use cases.  If the network operator has
to maintain flow state, that's no worse than the TLS-based proposal.

> You can already infer use of applications just by using IP addresses.

For apps that use CDNs, that's generally not true.

> Also, the amount of information you can extract from the presence of
> tokens decreases rapidly with the number of users that participate in them.
>

I agree that this is a small amount of leakage; I'm merely pointing out
that it's (a) not zero and (b) unnecessary.

---

From: Watson Ladd <[email-masked]>
Date: Thu, 30 Jul 2020 06:56:52 -0400

> eventually acquire and insert tokens, and iii) it doesn't work with IPv4.

Aren't network operators the ones interpreting these tokens? Aren't
application developers integrating these? Don't they use sockets? BSD
sockets is the API for BSD sockets.

IPv4 shouldn't be a consideration for a greenfield enhancement imho.

> mechanism to do this coordination can accelerate innovation in all other

Internet is end to end and layered for a reason. The economics of
middleboxes make upgrades far slower than client and server. Even with
visibility and negotiation the problems of middleboxes remain.

> on adoption of new ideas on TLS?

TLS 1.3 is filled with kluges to make it look like TLS 1.2 to middleboxes.

> quicker to adopt to format changes comparing to fixed-silicon appliances.

If you want per-flow instead of per-packet processing of priorities you can
look at the header on the first packet of a flow and copy on the rest. Flow
based does have challenges scaling, but if your hardware can't look into
extension headers this could work.

> decreases rapidly with the number of users that participate in them.

If tokens are per application vs. used as a tracking vector. The set of
applications people use is identifying.

I don't think pointing at a bigger leak elsewhere is a good justification
for making another hole in the boat.

---

From: Tom Herbert <[email-masked]>
Date: Thu, 30 Jul 2020 05:47:44 -0700

On Thu, Jul 30, 2020 at 3:57 AM Watson Ladd <[email-masked]> wrote:

>
>
> On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis <
>> Tokens as IPv6 extension headers have the benefit that they are
>> applicable to all traffic/applications, and could potentially be enforced
>> by the network in a stateless, per-packet manner. The problems are that i)
>> IPv6 extension headers are often dropped by network operators, ii) there
>> are no good APIs to expose L3 socket APIs to the app developers who would
> Yes, we can set HBH options via socket options. One caveat, in Linux at
least, is that currently only applications with admin privileges can set
options. Either this can be fixed by allowing unprivileged applications to
set them or we can have a new socket option just to set this. Either way, I
don't believe it's a major blocker to fix and relative to the time to
standardize a new protocol or deploy support in the network I don't believe
it's the bottleneck.

Tom

>> Does the group have any sense on the impact of existing DPI-based
>> services on adoption of new ideas on TLS?
>>
>
> If you want per-flow instead of per-packet processing of priorities you
> can look at the header on the first packet of a flow and copy on the rest.
> Flow based does have challenges scaling, but if your hardware can't look
> into extension headers this could work.
>
>
>>>> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema <[email-masked]
>>>> > wrote:
>>>>
>>>>> There is also an interesting privacy issue. The token is meant to let
>>>>> a provider identify some properties of the connection. I suppose there are
>>>> Then, there are potential interactions with ESNI/ECH. The whole point
>>>>> of ECH is to keep private extensions private. The token extension would
>>>>> need to be placed in the outer envelope, which is public but does not
>>>>> expose seemingly important information like the SNI or the ALPN.
>>>>>
>>>>
>>>> Ah, I was not aware that ESNI can now include all CH extensions -
>>>> thanks for the pointer. Yes, the token would have to stay on the outer
>>>> envelope so the network can process it. The main idea is you can encrypt
>>>> everything that is client-server specific, and just keep a token to
>>>> explicitly exchange information with trusted networks.
>>>>
>>>> You may want to have that discussion in the QUIC WG. If you are
>>>> building some kind of QoS service, you probably want it to work with QUIC
>>>> too.
>>>>
>>>> -- Christian Huitema