Re: [secdir] Secdir telechat review of draft-ietf-tls-exported-authenticator-14

[Yaron Sheffer <[e-mail]>]

I fully agree. Thank you Ben!

On 4/6/21, 21:43, "Benjamin Kaduk" <[e-mail]> wrote:

    Hi Yaron,

    Thanks for the (multiple!) reviews.

    My understanding is that the intention is not to allow "server_name" in all
    CertificateRequests but only specifically in the ClientCertificateRequest
    case.  I think it can be helpful to notate that with a "CR" in the "TLS
    1.3" column of the registry but we would need some further clarification as
    to what that notation actually means.  I left some suggestions for how to
    do that in my ballot position, but to summarize: a "comment" column in the
    registry would be great for this, and failing that a note in the IANA
    Considerations of this document to clarify what is and is not being
    registered would probably work as well.

    Thanks again for highlighting this point,

    Ben

    On Fri, Apr 02, 2021 at 09:05:38AM -0700, Yaron Sheffer via Datatracker wrote:
    > Reviewer: Yaron Sheffer
    > Review result: Has Issues
    > 
    > After a bit of back and forth over my *two* previous SecDir requests, I'm
    > afraid that my original comment has not yet been fully addressed. The IANA
    > considerations section (Sec. 8.1) adds server_name as a possible extension for
    > CertificateRequest. This would be a non-backward compatible change to TLS.
    > 
    > IMO what we needed to do is both to clarify the allowed extensions for what
    > Nick called "the CR-like structure" (almost done in Sec. 4, though the last
    > sentence should by changed to include CertificateRequest) and undo the change
    > to the TLS ExtensionType registry (not done, would require to remove Sec. 8.1).
    > 
    > * Nit: this sentence is repeated almost verbatim in Sec. 4 and Sec. 5, and in
    > both cases is mangled.
    > 
    > Old:
    > 
    > The application layer protocol used to send the authenticator request SHOULD
    > use a secure with equivalent security to TLS, such as QUIC [QUIC-TLS], as its
    > as its underlying transport to keep the request confidential.
    > 
    > New:
    > 
    > The application layer protocol used to send the authenticator request SHOULD
    > use a secure *channel* with equivalent security to TLS, such as QUIC
    > [QUIC-TLS], as its ~~as its~~ underlying transport to keep the request
    > confidential.
    > 
    >