Re: [Uta] Éric Vyncke's No Objection on draft-ietf-uta-rfc7525bis-09: (with COMMENT)

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

On 7/12/22 1:50 AM, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-uta-rfc7525bis-09: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> # Éric Vyncke, INT AD, comments for draft-ietf-uta-rfc7525bis-09
> CC @evyncke
> 
> Thank you for the work put into this document.
> 
> Please find below some non-blocking COMMENT points (but replies would be
> appreciated even if only for my own education).
> 
> Special thanks to Leif Johansson for the shepherd's detailed write-up including
> the WG consensus and the justification of the intended status.
> 
> I hope that this review helps to improve the document,
> 
> Regards,
> 
> -éric
> 
> ## COMMENTS
> 
> ### No 7457bis ?
> 
> I find a little weird that the legacy 'attack' document, RFC 7457, is not
> updated, but that the new attacks (the updated content of RFC 7457) are
> described in this document. No hard feeling though, and thanks for the warning
> text in section 1.

The original chronology of work in the UTA WG was to define the attacks 
that justified further work (RFC 7457), then doing that further work. It 
was a kind of "scaffolding" and perhaps we didn't see the need for that 
the second time around.

> ### Section 1
> 
> ```
>     Therefore this document replaces [RFC7525], with an explicit goal to
>     encourage migration of most uses of TLS 1.2 to TLS 1.3.
> ```
> Should it be stated with 'RECOMMEND' ?

I'm not sure that RECOMMEND belongs in text that's merely explaining the 
motivation for this work. There are plenty of actual recommendations 
later in the document.

> ### Section 1 what is meant by "stronger"
> 
> ```
>     Furthermore, this
>     document provides a floor, not a ceiling, so stronger options are
>     always allowed (e.g., depending on differing evaluations of the
>     importance of cryptographic strength vs. computational load).
> ```
> 
> While the astute readers will understand what is meant by 'stronger', should
> this document be clear on what is meant by 'stronger' in each subsequent
> sections ?

I suppose that RFC 3365 / BCP 61 defined "strong" in the context of IETF 
protocols, but more directly appropriate might be a pointer to RFC 4949. 
Section 2 already does include this sentence:

    A number of security-related terms in this document are used in the
    sense defined in [RFC4949].

We could change that to:

    A number of security-related terms in this document are used in the
    sense defined in [RFC4949], including "attack", "authentication",
    "certificate", ..., "self-signed certificate", "strength", and
    "strong".

> ### Section 3.1.1 what about SSLv1
> 
> While I am not familiar with old SSL, if there was a SSLv1, should this
> document also have recommendation about SSLv1 ?

That's pretty much implied by the prohibition on anything older than TLS 
1.2. We mention 1.0 and 1.1 simply because they were not forbidden by 
RFC 7525.

> ### Section 3.1.1 unclear
> 
> Perhaps because I am not a native English speaker, but I find this sentence
> hard to parse: ```
>        Even if a TLS
>        implementation defaults to TLS 1.3, as long as it supports TLS 1.2
>        it MUST follow all the recommendations in this document.

Other folks seem to have been confused by that, too, so we need to make 
it clearer. This is a possibility:

"To the extent that an implementation supports TLS 1.2 (even if it 
defaults to TLS 1.3), it MUST follow the recommendations regarding TLS 
1.2 specified in this document."

> ### Section 3.1.3 SCSV
> 
> It would not hurt expanding "SCSV" at first use even if a reference is added.

Agreed.

> ### Section 3.7 ESNI as a SHOULD ?
> 
> Shouldn't ESNI be a normative "SHOULD" ? Or is the non-normative text "just" to
> avoid forming a cluster with ESNI draft ? Which would be sad...

There is always debate about references to works in progress. It's not 
clear that a protocol still being hashed out in a WG (even a protocol as 
important as ESNI) can be reasonably considered a best current practice, 
given that it's far from stable. Eventually, we assume that the IETF 
will publish rfc7525ter to replace rfc7525bis, at which time that BCP 
will include updated recommendations (including, I'd expect, ESNI and 
various other things that are developed between now and then).

> ### Section 4.1 post-quantum crypto
> 
> A little surprised by the absence of any "post-quantum crypto" reference in
> this introduction text.

Noted:

https://github.com/yaronf/I-D/issues/423

> ### Section 4.5 TWIRL ?
> 
> Should "TWIRL" be expanded ? or at least given a reference ?

Yes:

https://github.com/yaronf/I-D/issues/424

Peter