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

[Watson Ladd]

On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis 
wrote:

> Hi Ben,
>
> Thanks for your comments. Please find some responses inline.
>
> On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz  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.
>

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.


> 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.
>

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.


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

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

>
> 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.
>

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.


> 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.
>
> 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.
>>
>
> 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 

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

[Yiannis Yiakoumis]

Hi Ben,

Thanks for your comments. Please find some responses inline.

On Wed, Jul 29, 2020 at 1:48 PM, Ben Schwartz < bem...@google.com > 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.

> 
> 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.
> 
> 

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.

> 
> 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.
> 
> 

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 (
> huit...@huitema.net ) > 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
>>> ( huit...@huitema.net ) > wrote:
>>> 
>>> 
>>> 
>>> 

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

[Yiannis Yiakoumis]

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 < huit...@huitema.net > 
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
>> ( huit...@huitema.net ) > 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
> 
> 
> 
>___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote:
>
>
>
> On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema
> mailto:huit...@huitema.net>> 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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yiannis Yiakoumis]

On Fri, Jun 26, 2020 at 7:29 AM, Christian Huitema < huit...@huitema.net > 
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?

> 
> 
> 
> 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.

> 
> 
> 
> -- Christian Huitema
> 
> 
> 
> 
> ___
> TLS mailing list
> TLS@ ietf. org ( TLS@ietf.org )
> https:/ / www. ietf. org/ mailman/ listinfo/ tls (
> https://www.ietf.org/mailman/listinfo/tls )
> 
> 
>___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Christian Huitema]

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.

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.

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.

-- Christian Huitema




signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Melinda Shore]

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").

Melinda

-- 
Melinda Shore
melinda.sh...@nomountain.net

Software longa, hardware brevis



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Yiannis Yiakoumis]

(cross-posting to network-tokens@ as this is the first related topic - 
apologies for any duplicates)

Hi Erik,

Thanks for the comments. That's a good point, and wanted to clarify the 
reasoning around binding fields in general, as well as  binding tokens to IP 
addresses specifically.

Unlike access and security tokens, network tokens are not protected by a secure 
TLS connection and can be read by any intermediary node. Therefore, they are 
open to replay attacks, and unless  used in a fully trusted environment, one 
should take measures against such attacks. There are two main approaches here:

* Limit a token's lifetime, to make replay attacks hard. The extreme here is to 
make tokens single use (e.g., through a nonce), and reject tokens with 
previously seen nonces (within a time window).

* Bind the token to a field that limits the scope it can be used (e.g., a user, 
a device, a set of exit gateways, etc). The network should be able to 
separately verify that the token is used within this scope. A binding field can 
be in an IP address, an IMSI, or any other field the network operator may use 
to limit the scope of a token.

Note that the binding value matters only at the point of enforcement ( the 
place where the network checks the scope). It doesn't play any role on the 
client, the server, or other network nodes.  Moreover, when tokens are 
encrypted, the binding field itself is not visible to anyone other than the 
network that issued the token, which should cover privacy concerns.

Two use cases where binding tokens to IP addresses should be fine are i) when 
users (a home or a mobile subscriber) are assigned a static IP address ( or a 
DHCP lease that lasts beyond a token's expiration time), and ii) for public IP 
addresses. Consider the following scenario:

home device → home NAT → operator network (static IP addresses) → operator NAT 
→ Internet .

Despite multiple NATs, the operator can bind the token to the IP address it 
assigns to the modem and not worry about the downstream and upstream NAT.

As you mentioned, there will be cases where IP binding won't work, either 
because the endpoint that gets the token doesn't have an assigned IP address, 
because the enforcement point is behind a NAT, or because of heavy use of 
proxies etc. In such cases one could bind tokens to a different field, or use 
short-lived tokens and/or nonces to prevent replay attacks. The overall benefit 
of binding tokens to certain fields is that they can have a longer lifetime and 
require less state in the network.

Does this address your concern? Also, any ideas/references on how common it is 
to have static/long-leased IP addresses in different scenarios (e.g., 
residential networks and mobile networks)?

Thanks,

Yiannis

On Thu, Jun 25, 2020 at 4:29 PM, Erik Nygren < erik+i...@nygren.org > 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.
> 
> (Even in IPv6-only, privacy addressing causes problems here.)  Even if you
> have a way to convert tokens over
> 
> for your set of IP addresses (eg, to deal with dual-stack) that still may
> not help enough with NAT environments.
> 
> 
> 
> Erik
> 
> 
> 
> 
> On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis < yiannis@ selfienetworks.
> com ( yian...@selfienetworks.com ) > wrote:
> 
> 
>> Hi all,
>> 
>> 
>> 
>> I wanted to briefly introduce network tokens ( https://networktokens.org )
>> into this list, how they relate with TLS and ESNI, and kindly ask anyone
>> that is interested to share feedback and join the discussion.
>> 
>> 
>> 
>> Network tokens is a method for endpoints to explicitly and securely
>> coordinate with networks about how their traffic is treated. They are
>> inserted by endpoints in existing protocols, interpreted by trusted
>> networks, and may be signed or encrypted to meet security and privacy
>> requirements. Network tokens provide a means for network operators to
>> expose datapath services (such as a zero-rating service, a user-driven QoS
>> service, or a firewall whitelist), and for end users and application
>> providers to access such services. Network tokens are inspired and derived
>> by existing security tokens (like JWT and CWT), borrowing several of their
>> security and privacy properties, and adjusting them for use in a
>> networking context.
>> 
>> 
>> 
>> There are two ways that network tokens relate with TLS:
>> 
>> * They can support ESNI adoption: in a world where ESNI is widely adopted,
>> network tokens can enable use cases where endpoint-network coordination is
>> required, without having to go back to plaintext SNI that everyone can
>> read.
>> 
>> * Network tokens are embedded as TLS handshake extensions (among others)..
>> 
>> We are shooting for a BoF in November, and are very much interested into
>> feedback around the concept, use cases, what 

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

[Erik Nygren]

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.
(Even in IPv6-only, privacy addressing causes problems here.)  Even if you
have a way to convert tokens over
for your set of IP addresses (eg, to deal with dual-stack) that still may
not help enough with NAT environments.

  Erik


On Thu, Jun 25, 2020 at 4:29 PM Yiannis Yiakoumis <
yian...@selfienetworks.com> wrote:

> Hi all,
>
> I wanted to briefly introduce network tokens 
> into this list, how they relate with TLS and ESNI, and kindly ask anyone
> that is interested to share feedback and join the discussion.
>
> Network tokens is a method for endpoints to explicitly and securely
> coordinate with networks about how their traffic is treated. They are
> inserted by endpoints in existing protocols, interpreted by trusted
> networks, and may be signed or encrypted to meet security and privacy
> requirements. Network tokens provide a means for network operators to
> expose datapath services (such as a zero-rating service, a user-driven QoS
> service, or a firewall whitelist), and for end users and application
> providers to access such services. Network tokens are inspired and derived
> by existing security tokens (like JWT and CWT), borrowing several of their
> security and privacy properties, and adjusting them for use in a networking
> context.
>
> There are two ways that network tokens relate with TLS:
>
>1. They can support ESNI adoption: in a world where ESNI is widely
>adopted, network tokens can enable use cases where endpoint-network
>coordination is required, without having to go back to plaintext SNI that
>everyone can read.
>2. Network tokens are embedded as TLS handshake extensions (among
>others).
>
> We are shooting for a BoF in November, and are very much interested into
> feedback around the concept, use cases, what we need to do to make network
> tokens adopted as a TLS handshake extension, and folks that are interested
> to get involved in the effort!
>
> Links to an IETF I-D, a mailing list, and initial implementation are
> available at https://networktokens.org  .
>
> Best,
> Yiannis
>
> =
> Yiannis Yiakoumis
> Co-Founder & CEO
> https://selfienetworks.com | +1-650-644-7857
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Network Tokens I-D and TLS / ESNI

[Yiannis Yiakoumis]

Hi all,

I wanted to briefly introduce network tokens ( https://networktokens.org ) into 
this list, how they relate with TLS and ESNI, and kindly ask anyone that is 
interested to share feedback and join the discussion.

Network tokens is a method for endpoints to explicitly and securely coordinate 
with networks about how their traffic is treated. They are inserted by 
endpoints in existing protocols, interpreted by trusted networks, and may be 
signed or encrypted to meet security and privacy requirements. Network tokens 
provide a means for network operators to expose datapath services (such as a 
zero-rating service, a user-driven QoS service, or a firewall whitelist), and 
for end users and application providers to access such services. Network tokens 
are inspired and derived by existing security tokens (like JWT and CWT), 
borrowing several of their security and privacy properties, and adjusting them 
for use in a networking context.

There are two ways that network tokens relate with TLS:

* They can support ESNI adoption: in a world where ESNI is widely adopted, 
network tokens can enable use cases where endpoint-network coordination is 
required, without having to go back to plaintext SNI that everyone can read..

* Network tokens are embedded as TLS handshake extensions (among others).

We are shooting for a BoF in November, and are very much interested into 
feedback around the concept, use cases, what we need to do to make network 
tokens adopted as a TLS handshake extension, and folks that are interested to 
get involved in the effort!

Links to an IETF I-D, a mailing list, and initial implementation are available 
at https://networktokens.org ( https://networktokens.org/ ).

Best,

Yiannis

=
Yiannis Yiakoumis
Co-Founder & CEO
https://selfienetworks.com | +1-650-644-7857___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls