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

[Tom Herbert <[e-mail]>]

On Wed, Sep 11, 2024 at 8:59 AM [e-mail]
<[e-mail]> wrote:
>
> Hi, Tom,
>
> > On Sep 11, 2024, at 8:11 AM, Tom Herbert <tom=[e-mail]> wrote:
> >
> >> ...
> >> Signed emails are a good example. The signatures happen at a layer above TCP. SMTP doesn’t ensure that the recipient has a key, nor does it drop all mails that lack keys, even when authentication is present.
> >
> > Joe,
> >
> > But Authentication Header (RFC4302) is much closer in functionallity
> > and use case than SMTP, and if a receiver can cannot validate the AH
> > in packet, for *any* reason, the packet MUST be dropped. That is the
> > relevant IETF precedent.
>
> You asked for an example of a use case where the current approach (SAFE) is still meaningful and useful. SMTP is it.
>
> Yes, AH works more like you prefer. But I would note that AH is deprecated in IPsec anyway. If we compare the only current IPsec required mode - ESP - that correlates to UENC and both are rightfully treated the same way, basically UNSAFE.,
>
> >>
> >> We could add optional AUTH to NFS without breaking NFS everywhere; those who care would benefit, but those who don’t - or don’t yet have a key - would not be affected. That works for many other UDP protocols, from DNS to DHCP.
> >>
> >> AUTH that isn’t checked at the receiver doesn’t just pass failed authenticity checks; it passes ones that would have succeeded to, so it acts like it’s not there. That’s “opportunistic” to me.
> >
> > Okay how about we call Auth it "Best Effort security" (pretty much an
> > oxymoron :-) ...)
>
> If you consider signing but not encrypting email equally oxymoronic, sure. It’s very widely used, though.
>
> >> [SM] Yes, but what utility does this offer to somebody employing AUTRH in a new protocol based on top of UDP options? Surely if AUTH is used UDP options are required ...
> >>
> >>
> >> That’s exactly the opposite of how the SAFE UDP options are designed. They’re silently ignored by legacy endpoints.
> >
> > And that obviously implies that SAFE options are safe to ignore. Auth
> > is not safe to ignore since it creates a security hole when ignored.
>
> 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. 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. 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.

You seem to assume that only the receiver has a vested interest in
secure communications. That is not true. Whenever I sign an email,
enter a login password, send a packet with Auth option I FULLY EXPECT
the receiver to authenticate the data. If they can't then I'd rather
be informed that communications are feasible than be lulled into a
false sense of security only to find out later that my service
provider gave me zero protection when my account is breached.

If Auth option can be ignored, then it is only a matter of time before
somewhere and for someone a security breach happens and a user incurs
harm. And the fact, this breach could have been prevented had the
protocol specified receiver requirements.

>
> 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.


Tom

> >>
> >> ...
> >>
> >> The question is whether doing AUTH on a packet means “you’d better do this or else” - but again, everything in UDP is designed to let the receiver decide what to do, not the sender force.
> >
> > No, that's not how UDP works. From RFC1122:
> >
> > "If a UDP datagram is received with a checksum that is non-zero and
> > invalid, UDP MUST silently discard the datagram."
>
> That’s a core part of the protocol. We do not have the luxury of making such assertions to a legacy protocol.
>
> >> [SM] Sure, but UDP already exists, UDP options is advertized as framework to build protocols on top of UDP, if "anything goes" is desired, why would I not simply stick to existing UDP?
> >>
> >>
> >> Anything doesn’t go per se; it’s just up to the receiver to decide what goes - JUST AS IT IS FOR TCP SYN OPTIONS, i.e., the stateless initiation of the TCP control protocol.
> >>
> >> FWIW, if we’re talking about precedent across IETF protocols, that’s a fundamental - transmitter offers, receiver decides. In stateful protocols, e.g., TCP, SCTP, etc., option capabilities are announced in the SYN but the receiver decides whether to accept them or not. The initiator has to wait for feedback to decide whether to proceed based on that information.
> >>
> >
> > Except that UDP is a stateless protocol and it does not have SYNs,
>
> SYNs arrive with no context, so they are handled exactly the same as every UDP packet - statelessly.
>
> > so
> > the comparison to TCP has little relevance. If you want to make a
> > meaningful comparison, then compare UDP options to other option
> > formats in stateless protocols (IIPv4 options, IPv6 HBH and Dest
> > options, Authenrication header, et.c).
>
> AH is not an option. It’s a tunnel. And yes, this is very much like options that were designed AFTER the protocol was designed, but not at all like those designed when the protocol was introduced.
>
> >
> >> In this case, the transmitter can try to figure out of the receiver will honor AUTH using an app level exchange; if it doesn’t, then it can always decide to cease transmissions too.
> >
> > We already negotiated a key with the receiver,
>
> AGAIN (and again and again) - if you negotiate a key with the receiver, then the receiver would (and could be required per the negotiation) to override the default. THAT IS NOT BEING DEBATED and we can make that clear as a suggestion for future negotiation protocol designers.
>
> The default is a concern ONLY for endpoints that either don’t support AUTH or haven’t negotiated keys. Just like email readers that don’t have keys or support signatures.
>
> Joe