On Wed, Jul 29, 2020, 7:51 PM Yiannis Yiakoumis <yian...@selfienetworks.com>
wrote:
> 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.
>
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 extract from the presence of tokens
> 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.
>
> 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 <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 <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
>>>
>>
>
>
> _______________________________________________
> 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
