Re: [tsvwg] A review of draft-ietf-tsvwg-udp-options-12

["C. M. Heard" <[e-mail]>]

On Sun, Jun 13, 2021 at 10:21 AM Joseph Touch wrote:

> Hi, Mike,
>
> On Jun 13, 2021, at 10:08 AM, C. M. Heard <[e-mail]> wrote:
>
> - regarding AE being safe
>>         This is not considered unsafe for two reasons:
>>         1. A(authentication) isn’t unsafe
>>         2. Encryption should only be used when sending packets to a party
>> that is keyed; that can/should be known or checked before use anyway.
>>         i.e., there’s never a case where you send encrypted text to a
>> party you don’t know should be ready.
>>
>>
> I do not agree that this behaviour is optimum ... I'm of the opinion that
> authentication should be a contract between the two ends. TC-AO could not
> have done anything else because unknown TCP options are ignored. UDP-AE
> can do better. That being said, if there is consensus in the WG for
> what's in the -12 draft I can live with it.
>
>
> FWIW, we don’t have any stateful handshake inside of UDP options - that’s
> deliberate. We COULD add that sort of thing - in the spirit of a zero-byte
> packet with an option check list (a new option where you list the option
> codepoints you want to support), but we’ve resisted that because we didn’t
> want to bake statefulness into the options themselves. In a sense, that
> state is at the endpoint user layer in how it interprets options only.
>
> It might be sufficient to say that:
>
> - when AE is used as auth, it has no other restrictions
> - when AE is used as encryption, it MUST be used as an unsafe option,
> i.e., only as a post-reassembly option on FRAG-buried data
>
> That way users who don’t support encryption wouldn’t get bad data.
>

That would work for me.

Mike