Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.7k
Description
Proposal:
Due tosecurity concerns, neither AWS-LCnor BoringSSL support "External PSK" (as definedhere) in TLS 1.3.
This issue proposes the addition of a boolean propertyssl.HAS_PSK_TLS13 to indicate whether the crypto library CPython is built against supports External PSK, allowing python's test suite and consuming modules to branch accordingly.
This feature has precedent in thessl.HAS_PSK andssl.HAS_PHA flags indicating support (or lack thereof) for other TLS features that are not universally implemented across TLS libraries.
One Hard Thing: Naming Concerns
I'm not sure thatHAS_PSK_TLS13 is the best name. While AWS-LC doesn't support "External PSKs" in TLS 1.3 (i.e. "PSK" is only used for session resumption), itdoes for earlier TLS versions. However, the "external" terminology established in RFC 9258 pertains specifically to TLS 1.3. So do we includeEXTERNAL instead ofTLS13 in thessl module property name? My thought is "no" because it's somewhat imprecise.
A further complication is that AWS-LC does notionally support PSK in TLS 1.3, butonly for session resumption (this is fine security-wise, as sessions can't span protocol versions). This makes the current suggestion ofHAS_PSK_TLS13 somewhat disingenuous, as thePreSharedKeyExtension is indeed used.
Something likessl.HAS_TLS13_EXTERNAL_PSK "feels" like an abomination, but is probably the most accurate. Anyway, I don't see a clear choice and am very open to suggestions.
Has this already been discussed elsewhere?
This is a minor feature, which does not need previous discussion elsewhere
Links to previous discussion of this feature:
Related changes to increase libcrypto/libssl compatibility (specifically with AWS-LC) have been discussed with the communityhere.