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