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

[Valery Smyslov <[e-mail]>]

Hi Alan,

>   I believe that the latest draft addresses all open concerns about the content.

I have a couple of nits that are better to be fixed before submitting the draft to the IESG.

1. 4.2.1 typo 
s/identies/identities

2. 5.1
I think that the added text about the historic method of protecting RADIUS packets
should be reworded to avoid use of "sign", "signing". Formally speaking 
calculating Message Authentication Code using hash algorithm is not "signing",
which is only applicable to public key cryptography. Security people are
very sensitive to the correct use of this term, so I believe the text should
be reworded to avoid negative feedback from the security review.
I think use of "authentication" or "integrity protection" is appropriate here.

>   The only remaining issue is the document status.  It's currently informational.  It perhaps could better
> be "experimental", to show that it is on the standards track.
> 
>   Jan-Frederiks point is that we could perhaps just make it proposed standard.
> 
>   I think there are benefits to that.  However, changing the status is likely to require the agreement of the
> WG and the AD.
> 
>   Comments?

I think that BCP is more appropriate here than Proposed Standard. The draft doesn't
define any new protocol, it contains recommendations for using existing protocols.

Anyway, I agree that there should be a WG consensus for changing the status
and an agreement from the responsible AD.

Regards,
Valery.

> > On Jan 15, 2024, at 6:20 AM, Alan DeKok <[e-mail]> wrote:
> >
> > On Jan 15, 2024, at 5:41 AM, Fabian Mauchle <[e-mail]> wrote:
> >> TLS1.3 session resumption requires it to be an opaque blob - externally provided PSK does not imply
> this, we can be more restrictive - if we want to.
> >
> >  I believe it's useful to suggest that PSKs managed by administrators be understandable by those
> administrators.  i.e. UTF-8 text is much easier for people to manage than opaque blobs.
> >
> >> E.G. RFC4279 requires that the identity MUST be UTF-8. Currently we require that the client supports
> this (but we don't forbid other things).
> >> But we could also be more restrictive and define that client and server MUST implement RFC4279 for
> the externally provided PSK. Thus the server may only accept non-UTF-8 for session resumption. This
> might simplify server implementations to distinguish between PSK and resumption.
> >
> >  I believe so, yes.
> >
> >  Alan DeKok.
> >
> > _______________________________________________
> > radext mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/radext
> 
> _______________________________________________
> radext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/radext