Re: [radext] WGLC for draft-ietf-radext-tls-psk-04

[Fabian Mauchle <[e-mail]>]

Hi,

On 01.12.23 09:18, Valery Smyslov wrote:
> the last (-04) version of draft-ietf-radext-tls-psk significantly differs
> from the previous version, that has passed WGLC. The chairs
> decided to issue another Working Group Last Call to confirm
> the WG consensus for the changes.

After re-reading -04 and trying to update my implementation:

4.2.1.  Security of PSK Identities
 > However, implementations MUST support managing PSK identities as a
 > set of undistinguished octets

This sentence confuses me (not sure why I didn't trip over it before).
If I follow the advise (SHOULD) of verifying identities as valid UTF-8, 
I would now violate above statement as I no longer support just any 
undistinguished octets.


6.2.3.  Resumption
 > Implementations MUST support resumption

I oppose this requirement.

1. this draft is about PSK, not resumption, and I see no technical 
requirements why a PSK client/server would need to support resumption.
I think this requirement belongs to draft-ietf-radext-radiusdtls-bis, 
which already states it as SHOULD.

2. I see PSK as a method for constrained implementations to get 
something better than Radius/UDP, so the requirements should be kept 
minimal.

3. in light of TLS1.3, resumption and PSK are mutually exclusive. TLS 
1.3 PSK already minimizes the handshake to a single round-trip.
(no sure how this works in TLS1.2)


I fully agree with paragraphs 2-5, stating how implementations should 
behave if they support both PSK and resumption.


 > Systems supporting TLS-PSK and resumption MUST cache data during the
 > initial full handshake sufficient to allow authorization decisions to
 > be made during resumption.  If cached data cannot be retrieved
 > securely, resumption MUST NOT be done.  The cached data is typically
 > information such as the original PSK identity, along with any
 > policies associated with that identity.

I presume this applies to TLS1.2 PSK? Maybe it should say so.


The remainder of section 6.2.3 I fully agree on the content - I think 
these are some very important provisions - but in my view they belong in 
draft-ietf-radext-radiusdtls-bis, as they apply to TLS resumption in 
general, not (just) PSK.


Best regards,
Fabian

-- 
Fabian Mauchle
Network
NOC:   [phone]
Direct:[phone]

Switch
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland