Re: [tsvwg] Review of draft-ietf-tsvwg-udp-options-32

["[e-mail]" <[e-mail]>]

> On Apr 9, 2024, at 7:11 PM, Christian Huitema <[e-mail]> wrote:
> 
> On 4/9/2024 3:41 PM, Joe Touch wrote:
>>> On Apr 9, 2024, at 12:17 PM, Christian Huitema<[e-mail] <mailto:[e-mail]>>  wrote:
>>> the maximum segment size option.
>>> Anything that adds clear text to an already encrypted packet should be considered an attack.
>> That would make all TCP or IP options used with TLS an attack. Please let us know when those are addressed.
> 
> But there have indeed been attacks against clear text TCP headers, from SYN attacks to RST to data insertion.

Yes, but that does not mean that every use of cleartext in TCP headers *is* an attack.

An attack is not simply something you don’t expect.

> There are also lots of intermediaries that like to mess with the TCP headers, for example rewriting flow control parameters or the maximum segment size option.
> These have been addressed over time in TCP.

Yes - partly by the use of VPNs. In some places (e.g., BGP), by the use of in-protocol protections similar to what we’re already planning here for UDP. But in most places, they’re not protected for TCP at all and yet the Internet still works.

> These attacks are largely mitigated in encrypted transports like QUIC.

Everywhere someone has the required certificate, which isn’t everywhere.

Again, simply assuming encryption isn’t enough if there aren't deployed keys.

> Adding clear text options to encrypted transports will bring new attack scenarios, which will typically only be discovered over time and which will necessitate ad hoc mitigations.

We are opt-in, not default on. We already have hooks for TCP-AO style protection. And we’re also already protected by VPNs the same way TCP is.

If this is so dangerous, then TCP is too - which would be convenient as we wouldn’t be exchanging emails like this ;-)

Joe