* Section 22: Mention potential for privacy exposure

[gorryfair]

Christian asked about privacy exposure. Request for the security considerations to mention potential for privacy exposure when using with an upper layer protocols that protect privacy.

[gorryfair]

See comments: https://mailarchive.ietf.org/arch/msg/tsvwg/arS4hxLhf821pkJ5TAtMnJAqz5E/

[jtouch]

Added a paragraph to the end of the security considerations in -23.

[gorryfair]

I think another para ought to also warn that adding UDP Options can also potentially provide additional fields that could help in-network devices to differentiate the type of a flow or the set of endpoints that are communicating (e.g. when the set of options differs from one endpoint to another). However, the use of UDP Options is under the control of the application, and applications that seek to hide such information (e.g., to meet a privacy requirement), need to only enable use when this is consistent with their privacy requirements.

[jtouch]

I would prefer to ensure that transport options are intended for endpoints only. If we start talking about how they COULD be used on-path, we need to ensure they're visible on-path - and that might not happen with UENC. There are no TCP options I recall that are defined specifically for on-path use.

This is a can of worms that I do not think UDP options should be opening.

[gorryfair]

This is not what was commented about. What was noted on the list was that the normal operation end to end operation of this method exchanges unencrypted protocol information - any method that does will allow visibility of fields that could help an in-network observer to differentiate the type of a flow or the set of endpoints that are communicating - this is not about allowing it or saying it is out of scope, it is about the privacy properties of the method, in a world post RFC6973, and the need for applications to be able to choose.

[jtouch]

I would suggest reminding users that these fields are as visible as the UDP header is, unless option encryption is supported by UENC. I don't think it's appropriate to comment on uses of those fields of what they could mean - that depends entirely on their content.

[gorryfair]

True, except that when you have an encrypted protocol carried over UDP this might add fields outside of the encryption envelope. I have sympathies to your argument in that, but there are many people in the IETF who think thinks this is a concern.

The text exists in this issue to do the right thing, and I think the draft will need to have text that relates to the perceived privacy issues, even if the conclusion is that this is no different to any other protocol encapsulation, and the upper layers decides whether to add UDP Options.

[jtouch]

Agreed with Gorry's assessment above; need to check the doc to see what changes help that for -24.

[jtouch]

Added a sentence to address this to -24 at end of security section.

[Mike-Heard]

Fix in -24 looks good modulo resolution of issue #6

[gorryfair]

New text was added.