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 18, 2023, at 5:26 PM, Peter Deacon <[e-mail]> wrote:

>> We are also supporting PAKEs and until OPAQUE is ready the only usable 
>> PAKE only works with TLS 1.2.

>  Are those part of the standard TLS libraries?  I can't find much about
>  that for OpenSSL.

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.

>> and if there are any version specific problems with TLS found they 
>> won't be able to switch versions.

>  I don't know what that means.
>  The intent is to not require *only* TLS 1.3.  But instead to require
>  *at least* TLS 1.3.

At present there is no version of TLS beyond 1.3.  Should there be a 
design or implementation problem discovered unique to TLS 1.3 operators 
would not be able to select an earlier version to avoid it.

>  Perhaps MUST support TLS 1.3 or later, and SHOULD NOT support TLS 1.2,
>  due to issues with using the same PSK across multiple TLS versions

What about MUST support TLS 1.3 or later and leave it at that?

I don't believe SHOULD NOT is warranted when there is no known problem. 
Referenced text in RFC8446:

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

regards,
Peter