Re: [radext] I-D Action: draft-ietf-radext-tls-psk-03.txt

[Peter Deacon <[e-mail]>]

On Tue, 19 Sep 2023, Alan DeKok wrote:

> On Sep 19, 2023, at 1:20 PM, Peter Deacon <[e-mail]> wrote:

>> SRP ciphersuites are supported in OpenSSL.  We've used them for years. 
>> That I know of wolfSSL and GnuTLS support SRP as well.  OpenSSL uses a 
>> similar callback scheme for SRP as the external PSKs.

>  OK, but that's changing the subject.  If you want to write a document
>  on using SRP with RADIUS/TLS, that's completely separate from TLS-PSK.

I have no intention on writing a separate draft nor do I expect this draft 
to be modified to include PAKE.  Remarks quoted above were offered only as 
a direct response to a question you asked about support in standard TLS 
libraries.

I agree with the perspective insecure PSK authentication methods are good 
enough when you assume only keys having sufficient entropy to weather 
offline challenge are used.

The reason for persuing PAKE is I simply don't view as credible the 
prospect decades of real world precident can be changed by merely calling 
a shared secret something else and placing a bunch of strong words in an 
RFC.  I believe use of secure authentication between RADIUS clients and 
servers improves real world security at implementation costs no different 
from PSK.

Not suggesting or requsting this WG do anything at all about my personal 
perspectives on PAKEs.

>> "While there is no known way in which the same PSK might produce 
>> related output in both versions, only limited analysis has been done. 
>> Implementations can ensure safety from cross-protocol related output by 
>> not reusing PSKs between TLS 1.3 and TLS 1.2"

>> This is a reflection of inability to formally prove separation not that 
>> there is actually a problem.

>  The fact that attacks are unknown simply means that they are likely to
>  exist in the future.

The prospect of unknown attacks is what crypto agility is all about and 
why unecessarily restricting PSK to just one version at present is a 
source of avoidable risk by preventing operators from reacting should the 
unknown occur.

>  Given also the complexity of supporting multiple TLS versions with PSK
>  + certs + resumption etc., I think it's worth suggesting that TLS 1.2
>  isn't worth it.

To be clear in no way arguing TLS 1.2 should be required or anyone 
implementing servers or clients otherwise feel in any way compelled to 
support it.  Only that it not be activly disallowed or discouraged.

>  TLS 1.3 (RFC8446) is 5 years old.  It will likely be 6-7 years old by
>  the time we issue "standards track" RADIUS/TLS documents.  I see it as
>  only problematic to continue support for old TLS versions.

Not advocating anyone should have to support old TLS versions.  My request 
is merely to require TLS 1.3 or later and say nothing about 1.2.

regards,
Peter