Re: [radext] TLS-PSK and RADIUS/(D)TLS - MTI trust models

[Alexander Clouter <[e-mail]>]

On Sun, 13 Aug 2023, at 18:38, Margaret Cullen wrote:
>> DTLS is a lot more difficult.  I blame some of that on OpenSSL weirdness.  Their DTLS implementation has best been described as "alpha" for a long time.
>
> This is the reason for my concern with mandating that servers implement DTLS.  

OpenSSL is not the only TLS library out there. I would be hesitant steering any decisions based on a single (albeit more widely used) library implementation.

The telephony world though seems to be quite happy using DTLS, after all no one wants to endure voice/video calls over the WAN via TCP.

> I think RADIUS/DTLS is an awful lot to expect, though — especially 
> because I don’t see any evidence that RADIUS/DTLS will ever be widely 
> implemented or used.  Do you?

Personally I really think this is more due to people not knowing TLS-over-UDP is even a thing.

Maybe I am seeing this too simplistically, but the impact of any mandating done here only affects (officially) the labelling available to a vendor?

 * implementors of TLS *and* DTLS: you get to tout 'RFCwxyz compliance'
 * implementors of only TLS: "you do not get this scout badge, sorry"

> Many protocols that run over TLS don’t have a DTLS equivalent defined, 
> at all.  Is there some important advantage that RADIUS/DTLS offers that 
> RADIUS/TLS does not?  Is that advantage sufficient to warrant mandating 
> both in every server implementation?

Head of Line blocking. When a packet is lost, the RADIUS server is unable to do anything but twiddle its fingers until the networking stacks, outside of its control, at both ends figure it out.

This means first the packet drop has to be detected, this can take some time anywhere from one to 1000's of milliseconds (~2xRTT), then retransmitted by the TCP layer until it gets through.

The RADIUS server meanwhile is unable to get involved in the retransmissions its-self.

Making it worse, *all* further authentications are gummed up until the stream starts to flow again.

With datagrams, this simply is not a problem. Recovery is much more application orientated, plus it bubbles up to the application so failover opportunities are made available far sooner.

>>  There's good reason for that, of course.  But I think it's best to document the system we need, rather than the system we have.
>
> I absolutely agree with this when it comes to documenting good protocol 
> behavior, ways to avoid known issues, etc.  I don’t think it extends to 
> mandating the implementation of an entirely separate protocol.

I think the wording makes this seem a bigger deal than it is.

Transport, not protocol.

Trying here to shift the focus that this is about something RADIUS runs *over* and not something that actually has to be implemented by anyone; the TLS libraries do all the work for you.

It may be that an implementor has picked a library that is a pain on the DTLS front to work with, but I do not think this should be a reason to strike "MUST do DTLS".

Afterall, the hard part of the work is already done. RADIUS servers are already expected to have implemented a datagram transport (ie. UDP) and handle retransmissions.

Wiring TLS into that is a lot more straight forward than the hoops an implementator already goes through to handle any of the EAP-TLS method families such as fragments and the need to spoon feed the TLS library *manually*, yikes!

No TLS library supports TLS over EAP, but it still works :)

>> The alternative is to never fix RADIUS, or to give bad implementations a free pass.
>
> Is there a reason that you think a RADIUS/TLS-only server would be a 
> bad implementation, and that it would  become a good implementation if 
> it also implemented RADIUS/DTLS?

The fallout I see is we will never see any DTLS implementations, and the for the most part this would have occurred for no real material reason.

Like Alan said, OSS implementations are able to clear these hurdles without making much of a song or dance about it which leaves the only benefactors of weakening this requirement to those with arguably the resources where implementing this likely to be just a budget rounding error.

I also suspect requiring DTLS will benefit those Internet cafe hotspot owners with their ropey saturated xDSL uplinks trying to authenticate the users to some hodgepodge WAN hosted RADIUS server federation.

For all of these reasons, I really do think servers should be expected to do both. My view is the client can implement whatever it wants...they already do for better or worse...

Cheers

[1] https://mailarchive.ietf.org/arch/msg/radext/5HB6BTgxA_LqgWDdSIE30u_Ckg8/