Re: [TLS] [Network-tokens] Network Tokens I-D and TLS / ESNI
On Wed, Jul 29, 2020 at 4: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 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. > > 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. > > 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 >> wrote: >> >>> >>> On 6/26/2020 10:16 AM, Yiannis Yiakoumis wrote: >
Re: [TLS] [Network-tokens] Network Tokens I-D and TLS / ESNI
On Thu, Jul 30, 2020 at 3:57 AM Watson Ladd wrote: > > > 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 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. > > 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 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
