[Emu] AD review draft-ietf-emu-rfc7170bis-14

[Paul Wouters <[e-mail]>]

Hi,

I think in general this document is ready to go. I have some hopefully
minor issues that would be good to resolve or clarify before starting IETF
LC.

       As such, the PAC has been removed from this document.

This reads a bit weird. Can it say PAC has been deprecated instead? This
occurs twice in the document.

draft-ietf-uta-rfc6125bis-15 -> RFC 9525

I am a bit confused by:

        Server Certificates MAY be constructed with a SubjectDN containing a
        single element, "CN=" containing the FQDN of the server.  It is also
        permissible for the server to have an empty subjectDN as recommended
        by {!{I-D.ietf-uta-rfc6125bis}}.

That document (RFC 9525 now) actually says:

        The Common Name RDN MUST NOT be used to identify a service
        because it is not strongly typed (it is essentially free-form
        text) and therefore suffers from ambiguities in interpretation.

        For similar reasons, other RDNs within the subjectName MUST NOT
        be used to identify a service.

It seems to me that RFC9525 says to only use subjectAltName (SANs) ?

Now this document also follows with:

        Server Certificates MUST include a subjectAltName extension

Perhaps some text can be added to the "Server Certificates MAY be
constructed"
text by saying that authentication decisions MUST NOT be made based on the
SubjectDN ?


        Note that since TLS client certificates are sent in the clear with
        TLS 1.2 and earlier

Can "and earlier" be removed? Eg can this document say the TLS version MUST
be 1.2 or later? If not, then the later text "The first is when TLS 1.2 is
used" needs to fill in what is expected for TLS 1.1. Similar for more text
later on, eg "which should not be sent over a TLS 1.2 connection".

        The first Basic-Password-Auth-Req TLV received in a session MUST
        include a prompt, which the peer displays to the user.

Should this receive some Security Considerations to avoid log4j/JNDI type
issues?

        While [RFC8446] allows for the TLS conversation to be restarted,

Maybe write "TLS 1.3" instead of "[RFC8446]" here? Or use both?

The IANA considerations lists:

        11,PAC TLV,(DEPRECATED) [RFC7170]

As it is [THIS-DOCUMENT] that deprecates it, it should be added to the
reference RFC as well, eg:

       11,PAC TLV,(DEPRECATED) [RFC7170] [THIS-DOCUMENT]


        Protection against Man-in-the-Middle Attacks

Maybe rename to "on-path attacks" ?

Appendix C.4 should clarify the TLS version used (1.2). Should it be
changed to use a TLS 1.3 example?

Paul