Re: [tsvwg] Regarding DTLS and UDP options

[Joe Touch <[e-mail]>]

On 4/18/2017 11:16 AM, Tom Herbert wrote:
>> UDP packets and TCP packets can already be forged.
>>
>> If that's your concern, you need to use true transport-layer or network
>> layer security.
>>
> 1) Yes, that is my concern. UDP is already dicey in terms of security,
> the risks introduced with these extensions needs to be thoroughly
> vetted before I'd ever deploy in my network
Do you feel the same about new TCP options?

> 2) It can't be a requirement to turn up security everywhere just to
> use UDP options
It isn't for new TCP options either, though.

> 3) My example is a contrived attack against the new protocol that
> might be deployed, the mitigations to defend such an attack should be
> part of the protocol not deferred to some other layer
The protocol extension already includes OCS and AE for that reason,
though there's no way that UDP can protect the entire IP header too
(that's what IPsec is designed for).

>
>> And endpoints can claim conformance all they want; forged packets are
>> already noncompliant. No protocol is robust to forged packets except
>> those that support authentication or encryption.
>>
> That's misses the crux of my argument. In my example, an attacker
> forged a packet with can be "correctly" interpreted as either fragment
> or a non-fragment. Which interpretation depends on the node that
> processes it (sort of a Copenhagen Interpretation for network
> protocols I suppose :-) ). But a packet cannot simultaneously be a
> fragment and a not fragment, that is nonsensical (packets don't have
> duality in this instance). This must be considered an error condition.
The solution to your  example would be for the protocol to allow only
the hidden FRAG mechanism. Right now that's optional.

However, note that forged packet can add a new extension that has two
effects - one for upgraded endpoints, one for legacy - already. In TCP.

The solution to *that* ambiguity is to confirm new options before using
them and use them only when confirmed - as noted in Section 10.

> This ambiguity does not occur in IP or IPv6 and has been introduced by
> the protocol specification not incorrect implementation. 
It occurs the same way you could forge a new IP option that is accepted
or ignored, depending on the endpoint support.

> It's unlikely
> in practice that this would cause problems, however, as I mentioned
> above, if this can be exploited as a security vulnerability that will
> be a concern of mine.
>
> I thought a one point there was the idea that the UDP checksum would
> be incorrect so that in the case I describe above a fragment would be
> dropped and not misinterpreted by a node that doesn't support
> fragments. Is there a reason that wouldn't work?

I'm not sure - again, I think your concerns about misinterpreting the
data are addressed by allowing only FRAG as LITE.

But I'm not sure I understand the example.

Consider that if I can forge a FRAG, I can forge an entire UDP packet. I
don't need anything new to have this vulnerability.

Joe