Re: [auth48] AUTH48: RFC-to-be 9325 <draft-ietf-uta-rfc7525bis-11> for your review

[Peter Saint-Andre <[e-mail]>]

I concur with the changes proposed by Thomas and Yaron, with one 
exception below.

I've also completed a full read and have a few small items as well...

1. Introduction

OLD

    Naturally, future attacks are likely, and this document does not
    address them.

NEW

    Naturally, future attacks are likely, and this document cannot
    address them.

3.1.1.  SSL/TLS Protocol Versions

CBC is not spelled out on first use (although it is spelled out in 
Section 4.2); it's actually used in the Introduction but only in the 
name of the AES-CBC cipher suite, so I propose that we spell it out here.

OLD

       In addition, TLS 1.0 lacks a per-
       record Initialization Vector (IV) for CBC-based cipher suites and
       does not warn against common padding errors.

NEW

       In addition, TLS 1.0 lacks a per-
       record Initialization Vector (IV) for cipher suites based on
       cipher block chaining (CBC) and does not warn against common
       padding errors.

This is a very long sentence, which I suggest changing as follows:

OLD

       In most application
       protocols that reuse TLS and DTLS, there is no immediate need to
       migrate solely to TLS 1.3 and proactively deprecate TLS 1.2,
       especially because the existence of large numbers of application
       clients dependent on TLS libraries or operating systems that do
       not yet support TLS 1.3 would introduce significant
       interoperability issues, thus harming security more than helping
       it.

NEW

       In most application
       protocols that reuse TLS and DTLS, there is no immediate need to
       migrate solely to TLS 1.3.  Indeed, because many application
       clients are dependent on TLS libraries or operating systems that
       do not yet support TLS 1.3, proactively deprecating TLS 1.2 would
       introduce significant interoperability issues, thus harming
       security more than helping it.

There is an inconsistency between the following statements:

       New application
       protocols that employ TLS/DTLS for channel or session encryption
       MUST integrate with both TLS/DTLS versions 1.2 and 1.3;

and

       new application
       protocols that reuse TLS MAY support both TLS 1.3 and TLS 1.2 in
       order to take advantage of underlying library or operating system
       support for both versions.

I suggest changing MAY to MUST in the second statement.

3.1.3  Fallback to Lower Versions

OLD

    We note that as a result of that

NEW

   As a result,

3.2.  Strict TLS

OLD

   When a protocol supports only a dynamic upgrade,

NEW

   When a protocol supports only a dynamic upgrade method,

3.3.1.  Certificate Compression

Question for my co-authors: should the title of this section be 
"Certificate Chains" instead of "Certificate Compression"?

3.4  TLS Session Resumption

PSK is not spelled out on first use. I suggest:

OLD

    For TLS 1.3, a
    more secure PSK-based mechanism is described in Section 4.6.1 of
    [RFC8446].

NEW

    For TLS 1.3, a
    more secure mechanism based on the use of a pre-shared key (PSK) is
    described in Section 4.6.1 of [RFC8446].

3.10.  Zero Round-Trip Time (0-RTT) Data in TLS 1.3

OLD

    Typically, this extends to both the TLS library as well as protocol
    layers above it.

NEW

    Typically, this extends to the TLS library as well as protocol
    layers above it.

OLD

    For use in HTTP over TLS, readers are referred to [RFC8470] for
    guidance.

NEW

    For HTTP over TLS, refer to [RFC8470].

4.1  General Guidelines

OLD

    Consequently, they need to be phased out over time and replaced with
    more secure cipher suites.

NEW

    Consequently, cipher suites using weak algorithms need to be phased
    out and replaced with more secure cipher suites.

There's a bad line break here:

       Rationale: The NULL cipher suites do not encrypt traffic and so
       provide no confidentiality services.  Any entity in the network
       with access to the connection can view the plaintext of contents
       being exchanged by the client and server.
       Nevertheless, this document does not discourage software from
       implementing NULL cipher suites, since they can be useful for
       testing and debugging.

4.2  Cipher Suites for TLS 1.2

OLD

    Typically, in order to prefer these suites, the order of suites needs
    to be explicitly configured in server software.

NEW

    Typically, to prefer these suites, the order of suites needs
    to be explicitly configured in server software.

OLD

    to avoid predictable or repeated nonces (that would allow
    revealing the long term signing key)

NEW

    to avoid predictable or repeated nonces (which could reveal
    the long-term signing key)

OLD

    While most fault attacks

NEW

    While most fault injection attacks

4.2.1  Implementation Details

Question for my co-authors regarding this sentence: "Other application 
protocols specify other cipher suites as mandatory to implement (MTI)."

Do we mean that they "MAY specify" or do we intend to merely make a 
factual statement?

4.5  Public Key Length

Question for my co-authors regarding this sentence: "The Logjam attack 
[Logjam] further demonstrates that 1024-bit Diffie-Hellman parameters 
should be avoided."

Do we mean SHOULD?

5.1  Security Services

OLD

    clients are user agents like web browsers or email software.

NEW

    clients are user agents like web browsers or email clients.

7.1.  Host Name Validation

OLD

    In addition, that RFC contains a long
    list of example protocols

NEW

    In addition, that RFC contains a long
    list of application protocols

Should we spell out PKI on first use?

7.5.  Certificate Revocation

OLD

    *  OCSP stapling as used in TLS 1.2 does not extend to intermediate
       certificates within a certificate chain.  The Multiple Certificate
       Status extension [RFC6961] addresses this shortcoming, but it has
       seen little deployment and had been deprecated by [RFC8446].  As a
       result, we no longer recommend this extension for TLS 1.2.

NEW

    *  OCSP stapling as used in TLS 1.2 does not extend to intermediate
       certificates within a certificate chain.  The Multiple Certificate
       Status extension [RFC6961] addresses this shortcoming, but it has
       seen little deployment and had been deprecated by [RFC8446].  As a
       result, although this extension was recommended for TLS 1.2 in
       [RFC7525], it is no longer recommended by this document.

8.2.  Informative References

Question for the RPC: I noticed that a few RFCs cited informationally in 
this document use descriptive names, not RFC numbers: [DANE-SMTP], 
[DANE-SRV], [DEP-SSLv3], and [HTTP-SEMA] (also [HTTP1.1] and [HTTP2]). 
Does the RPC have a preference here? It struck me as strange that just a 
few RFCs were not cited by number. Personally I would prefer changing 
these descriptive names to RFC numbers, but it's not a hill for me to 
die on.

Finally, see below for one text tweak.

On 11/20/22 9:08 AM, Thomas Fossati wrote:

> OLD
> 
> was published when the industry was in the midst of its transition to 
> TLS 1.2.
> 
> NEW
> 
> was published when the industry was amid its transition to TLS 1.2.
> 
> ---

To my ear, that doesn't sound quite right in English. I suggest either 
the OLD text or:

    was published when the industry was transitioning to TLS 1.2

That's it!

Many thanks to our RPC colleagues for their work on this document.

Peter