[tsvwg] Re: I-D Action: draft-ietf-tsvwg-udp-options-33.txt

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

Hi, Tom,

> On Sep 11, 2024, at 9:44 AM, Tom Herbert <tom=[e-mail]> wrote:
> 
>> I would be glad to discuss new perspectives further, but continuing to claim that *defaulting* AUTH as OK to accept regardless of the check result is the same as saying every signed email you receive should be dropped when you lack the key - or try to read them on a device that doesn’t support signatures.
> 
> Joe,
> 
> Email has the same problem. If you accept a signed email without
> validating it then you are potentially accepting a forged email.

Yes - and many people do that. This email and yours included, because neither is signed.

> That
> is a problem. The sending user didn't sign the email just for fun or
> to waste compute cycles, they did it because they want to protect
> THEMSELVES.

Yes, but they do - as per my other note, when I send signed work emails, that means that a user CAN read it on any device, but can now - or later - check to make sure its authentic if they want. If they don’t, that’s also fine too.

My signature, like that on a check or a contract, isn’t authenticated immediately. It’s the receiver’s option to decide if and when to authenticate. But it serves a purpose for me - the ’sender’ - to ensure that IF and/or WHEN something is challenged, it’s there for that purpose.

> If the receiver does accept a forged email because they're
> too lazy to authenticate it, then when the user incurs damages because
> of that laziness, liability is going to rest on the receiver.

Sure - just like banks not checking signatures on checks more than a certain amount or more than a few in a day from the same person. BUT, *after the fact*, those signatures still serve a purpose to determine whether the data was valid or not.

The nice thing about letting the receiver decide, for authentication, is that:

	a) they decide whether they want to support the feature (code complexity, size)
	b) they decide whether or when they want to invoke the validation (can save power and cycles, e.g., on portable devices)

> You seem to assume that only the receiver has a vested interest in
> secure communications.

I am not. I am, however, assuming that authentication isn’t like encryption.

The sender decides whether they need the “insurance”.
The receiver decides whether they want to assume the risk.

There are two parties there. The sender shouldn’t decide whether the receiver accepts the risk. The fact that this is true for AH is an artifact of the way IPsec needed to be implemented - effectively, all IPsec variants are UNSAFE because they can only be placed inside encapsulations.

Consider that this might have been the very reason AH isn’t used - that it wasn’t possible as a “SAFE” option for IP.

>> 
>> That’s basically a complete proof of why AUTH needs to be SAFE.
>> 
> 
> Hardly. If you want to prove that you need to show that ignoring Auth
> does not introduce a security risk for users.

See above. It introduces risk on them that it is THEIR decision to assume or not.

Joe