Re: [radext] WGLC #2 for draft-ietf-radext-dtls-04

[Sam Hartman <[e-mail]>]

>>>>> "Peter" == Peter Deacon <[e-mail]> writes:

    Peter> On Mon, 8 Apr 2013, Alan DeKok wrote:
    >> Sam Hartman wrote:
>> Can you point to the documentation of the hard requirement for
    >>> server-side memory in upgrade?  I'd like to understand how we
    >>> got there and the discussions/arguments leading to that.

    >> Down-bidding attacks.

    Peter> A bidding down attack requires client or server to be tricked
    Peter> into accepting security lower than highest supported by both
    Peter> peers.  See the table in my previous message.

OK.
So, RADIUS/UDP is easier to attack than RADIUS/DTLS.
Let's assume a server requires message authenticators for UDP.

If the server forbids UDP-after-DTLS, then once DTLS has happened, an
attacker can no longer attack that particular UDP secret.
However if the client is responsible for enforcing the attack, then an
attacker can try and convince the server to accept a request using the
UDP secret in question.

I don't want to argue about whether it's a bid-down attack or not.
It is a real attack.
It's almost certainly in our threat model.

It's almost certain that a policy control of forbid UDP as the
mandatory-to-implementmechanism combined with Alan's proposal for
latching on use of DTLS as a SHOULD is sufficient to meet security
review.
If you turn off the latching behavior  then  you have a residual risk.

That said, I think I've also convinced myself that having the latching
behavior be mandatory-to-implement but not mandatory-to-use on the
server is also fine.

So,  here's where I stand on this issue:

* we need to do something in this space.

* I'm against mandating that clients or proxies support upgrading from
  UDP to DTLS without a restart/flag day

* I am in favor of requiring servers support clients upgrading without a
  flag day. Alan's latching proposal seems like a fine option to get
  that either as a SHOULD or MUST.

--Sam