Re: [tsvwg] [saag] TSVWG WGLC: draft-ietf-tsvwg-transport-encrypt-08, -> logging

["Lubashev, Igor" <[e-mail]>]

> On Tue, Oct 15, 2019 at 9:10 PM Tom Herbert <[e-mail]> wrote:
> 
> On Tue, Oct 15, 2019 at 2:11 PM Lubashev, Igor <[e-mail]>
> wrote:
> >
> > Most users would likely say that they want Internet that is as fast as
> possible (low latency/high throughput), very reliable, secure (passwords and
> emails are safe from peeping toms) and reasonably private. Different people
> will make different trade-offs between the above, especially about the
> degree of privacy vs performance and reliability.
> >
> Sure, but who are the "people" making the tradeoff? If the tradeoff of what
> information to expose is left up to the user then that is reasonable. But if
> network operators or IETF are arbitrarily making this tradeoff for the user
> that's a problem.

I completely agree with this.

What trade-off operators do when they block QUIC, rate limit QUIC, etc. is a different discussion.
This draft is about what trade-offs IETF is doing, when it is removing existing signals that network can use and not providing a substitute at the same time.


> As Joe stated, the only viewpoint that really matters is that
> of the user; their needs and wishes come first. So if a user wants strong
> security and privacy, then that's their prerogative-- in no way should they be
> penalized for that.

Yes.  And if the user believes that signals to the network are not desirable for their preferred level of privacy, they should be able to instruct their client to not send those signals. Moreover, IETF should ensure that their choice is harder for the network to discriminate against; hence the requirement that endpoints that do send these signals send them for no more than 80% of the connections.


<snip>

> So the open question still seems to be what is the path
> forward to allow strong user privacy and yet give the network the necessary
> visibility above the network layer in a secure and robust fashion.

I think you have a preferred approach, and I completely agree with it -- encrypt transport header and send explicit network signals.  I see this draft to be about the consequences of doing the former without the latter.  And the tussle is about an argument that any extra signal might weaken privacy.


<snip>

> > I think it is unfortunate that security is even mentioned in this draft. Header
> encryption is not about security; it is about privacy and protocol ossification
> resistance.
> >
> From draft-ietf-quic-transport-23:
> 
> "QUIC authenticates all of its headers and encrypts most of the data it
> exchanges, including its signaling, to avoid incurring a dependency on
> middleboxes."
> 
> In other words to prevent middleboxes from ossifying the QUIC protocol.

Right, a trade-off between protocol ossification and network performance/reliability is an IETF concern in its entirety, and it should be a subject for IETF debate what the trade-off should be.

Privacy is also mentioned often here, since some signals may help correlate connections. This would be a user concern (as we discussed above).

- Igor