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

[Yaron Sheffer <[e-mail]>]

+1

Thanks, Yaron

Get Outlook for Android<https://aka.ms/AAb9ysg>
________________________________
From: Thomas Fossati <[e-mail]>
Sent: Wednesday, November 23, 2022 12:43:31 PM
To: Francesca Palombini <[e-mail]>; Karen Moore <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
Subject: Re: [AD] Re: AUTH48: RFC-to-be 9325 <draft-ietf-uta-rfc7525bis-11> for your review


Hi Francesca, all,



The text you propose seems to solve the ambiguity initially noted by Peter elegantly.



I like it!



Cheers, t



On 23/11/2022, 08:28, "Francesca Palombini" <[e-mail]> wrote:



Hello Karen, authors,



Changes 2 and 3 are approved. I am not convinced about the change in 1: to me, the sentence that was changed (from MAY to MUST) explains the rationale of the following two sentences:



New application

      protocols that employ TLS/DTLS for channel or session encryption

      MUST integrate with both TLS/DTLS versions 1.2 and 1.3;

      nevertheless, in rare cases where broad interoperability is not a

      concern, application protocol designers MAY choose to forego TLS

      1.2.



This is in practice a MUST for most cases, MAY in particular cases.

My suggestion is to delete the normative must from this following sentence. In practice, the requirement is already taken care by the paragraph above, and the sentence is only meant to describe the rationale. So I would do the following change:



OLD:

  By contrast, 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.



NEW:

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



Peter, Yaron, Thomas, what do you think?



Francesca



From: Karen Moore <[e-mail]>
Date: Tuesday, 22 November 2022 at 00:21
To: Thomas Fossati <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, Francesca Palombini <[e-mail]>
Cc: [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>, [e-mail] <[e-mail]>
Subject: [AD] Re: AUTH48: RFC-to-be 9325 <draft-ietf-uta-rfc7525bis-11> for your review

Thomas, Peter, Yaron, and Francesca (AD)*

Thank you for your quick replies!  We have carefully sifted through all of the responses and have updated our files accordingly (see links to the updated files below).

1) Regarding the following question, it is author preference.  In looking at RFC 7525, it appears that some of the citations, such as [DANE-SRV], [DANE-SRV], and [DEP-SSLv3], were works in progress at the time, so it would be appropriate to cite them by number in this document (and we can update the others you mentioned as well for consistency). If you would like to make this change, please let us know as we would support it.

> 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.

--------------
* Francesca, please review the following changes and let us know if you approve.  The changes are highlighted below for ease, and they can also be reviewed here: https://www.rfc-editor.org/authors/rfc9325-auth48diff.html

1) Section 3.1.1 (changed “MAY” to “MUST”)

OLD:
  By contrast, 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.

NEW:
   By contrast, new application protocols that reuse TLS MUST support
   both TLS 1.3 and TLS 1.2 in order to take advantage of underlying
   library or operating system support for both versions.

Note: Rationale for the change from Peter:
   There is an inconsistency with the following statement in Section 3.3.1:

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

...
2) Section 5.1 (changed “software” to "clients”)

OLD
  This is particularly true where TLS clients are user agents like
  Web browsers or email software.

NEW
  This is particularly true where TLS clients are user agents like
  web browsers or email clients.

...
3) Appendix A (changed “SHOULD” to “MUST)

OLD:
   Generic SHOULD-level guidance to avoid 0-RTT unless it is
   documented for the particular protocol.

NEW:
   Generic MUST-level guidance to avoid 0-RTT unless it is
   documented for the particular protocol.

---
The updated XML file is here:
 https://www.rfc-editor.org/authors/rfc9325.xml

The updated output files are here:
 https://www.rfc-editor.org/authors/rfc9325.txt
 https://www.rfc-editor.org/authors/rfc9325.pdf
 https://www.rfc-editor.org/authors/rfc9325.html

This diff file shows all changes made during AUTH48:
 https://www.rfc-editor.org/authors/rfc9325-auth48diff.html

This diff file shows all changes made to date:
 https://www.rfc-editor.org/authors/rfc9325-diff.html

Note that it may be necessary for you to refresh your browser to view the most recent version. Please review the document carefully to ensure satisfaction as we do not make changes once it has been published as an RFC.

Please contact us with any further updates or with your approval of the document in its current form.  We will await approvals from each author prior to moving forward in the publication process.

For the AUTH48 status of this document, please see:
 https://www.rfc-editor.org/auth48/rfc9325

Thank you!

RFC Editor/kc

> On Nov 18, 2022, at 1:28 PM, Thomas Fossati <[e-mail]> wrote:
>
> Hi,
>
> Thanks for the great work!
>
> Two small typographic notes:
>
> * TLS-ECCH should be TLS-ECH, I reckon
> * SSL Stripping is in quotes in RFC7457, maybe we should do the same here
>
> On 18/11/2022, 19:55, "[e-mail]" <[e-mail]> wrote:
> > 1) <!-- [rfced] Please insert any keywords (beyond those that appear in
> > the title) for use on https://www.rfc-editor.org/search. -->
>
> I have nothing to add here.
>
> > 2) <!-- [rfced] FYI: We've replaced hyphens in the following paragraph with parentheses to add clarity to the sentence. Please let us know if this is not preferred.
> >
> > Original:
> >    Although the TLS handshake protocol can also be used with different
> >    record layers to define secure transport protocols - the most prominent
> >    example is QUIC [RFC9000] - such transport protocols are not directly in scope
> >    for this document; nevertheless, many of the recommendations here might apply
> >    insofar as such protocols use the TLS handshake protocol.
> >
> > Updated:
> >    Although the TLS handshake protocol can also be used with different
> >    record layers to define secure transport protocols (the most prominent example
> >    is QUIC [RFC9000]), such transport protocols are not directly in scope for
> >    this document; nevertheless, many of the recommendations here might apply
> >    insofar as such protocols use the TLS handshake protocol.
> > -->
>
> WFM
>
> > 3) <!-- [rfced] Should the note at the end of the first paragraph in
> > Section 3.3 be placed in an <aside> element to indent it and set
> > it aside from the rest of the text as supplemental? Details about
> > the use of <aside> can be viewed here:
> > https://authors.ietf.org/rfcxml-vocabulary#aside
> >
> > Original:
> >    Note: this recommendation applies to TLS 1.2 only, because
> >    compression has been removed from TLS 1.3.
> > -->
> >
> >
> > 4) <!-- [rfced] Section 9.3.2 is not present in [HTTP2]. Please let us
> > know which section was intended.
> >
> > Original:
> >    Multiplexed protocols SHOULD follow the advice provided for HTTP/2
> >    in Section 9.3.2 of [HTTP2].
> > -->
>
> Good catch: it's RFC9113 Section 9.2.3, "TLS 1.3 Features"
>
> > 5) <!--[rfced] Would you like to update "'Supported Elliptic Curves'
> > extension" to "Supported Elliptic Curves Extension" per use in
> > RFC 8422?
> >
> > Original:
> >    Both clients and servers SHOULD include the "Supported
> >    Elliptic Curves" extension [RFC8422].
> >
> > Perhaps:
> >    Both clients and servers SHOULD include the "Supported
> >    Elliptic Curves Extension" [RFC8422].
> > -->
>
> WFM
>
> > 6) <!--[rfced] Please confirm how RFC 9155 and [CAB-Baseline] should be
> > referenced in the following sentence - perhaps A or B?
> >
> > Original:
> >    In addition, the use of the SHA-256 hash algorithm is RECOMMENDED
> >    and SHA-1 or MD5 MUST NOT be used ([RFC9155], and see [CAB-Baseline]
> >    for more details).
> >
> > Perhaps:
> > A) In addition, the use of the SHA-256 hash algorithm is RECOMMENDED
> >    and SHA-1 or MD5 MUST NOT be used [RFC9155] (also see [CAB-Baseline]
> >    for more details).
> >
> > or
> >
> > B) In addition, the use of the SHA-256 hash algorithm is RECOMMENDED
> >    and SHA-1 or MD5 MUST NOT be used (see [RFC9155] and [CAB-Baseline]
> >    for more details).
> > -->
>
> I prefer A
>
> > 7) <!--[rfced] We made "Truncated" lowercase per use in RFC 6066; please
> > let us know of any objections.
> >
> > Original:
> >    Implementations MUST NOT use the Truncated HMAC extension, defined in
> >    Section 7 of [RFC6066].
> >
> > Current:
> >    Implementations MUST NOT use the truncated HMAC extension, defined in
> >    Section 7 of [RFC6066].
> > -->
>
> WFM
>
> > 8) <!-- [rfced] We cannot locate Version 1.1.6 of [CAB-Baseline], but we
> > did find Version 1.1.7. Please confirm if you would like to link to
> > Version 1.1.7 or a different version.
> >
> > Original:
> >    [CAB-Baseline]
> >         CA/Browser Forum, "Baseline Requirements for the Issuance
> >         and Management of Publicly-Trusted Certificates Version
> >         1.1.6", 2013, <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9f40317a13494971&q=1&e=1997acfc-1f86-4453-8d87-04db0e0038a2&u=https%3A%2F%2Fcabforum.org%2Fdocuments%2F>.
> >
> > Perhaps:
> >    [CAB-Baseline]
> >         CA/Browser Forum, "Baseline Requirements for the Issuance
> >         and Management of Publicly-Trusted Certificates, Version
> >         1.1.7", April 2014, <https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-9f40317a13494971&q=1&e=1997acfc-1f86-4453-8d87-04db0e0038a2&u=https%3A%2F%2Fcabforum.org%2Fdocuments%2F>.
> > -->
>
> The latest [1] appears to be 1.8.4.  I'd use that.  My co-authors may
> disagree with me :-)
>
> [1] https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-8dcf34982dacebfd&q=1&e=1997acfc-1f86-4453-8d87-04db0e0038a2&u=https%3A%2F%2Fcabforum.org%2Fbaseline-requirements-documents%2F
>
> > 9) <!--[rfced] FYI: draft-mattsson-cfrg-det-sigs-with-noise-04 was
> > replaced by draft-irtf-cfrg-det-sigs-with-noise-00, so we updated
> > the entry for [CFRG-DET-SIGS] accordingly.
> >
> > Original:
> >    [I-D.mattsson-cfrg-det-sigs-with-noise]
> >               Mattsson, J. P., Thormarker, E., and S. Ruohomaa,
> >               "Deterministic ECDSA and EdDSA Signatures with Additional
> >               Randomness", Work in Progress, Internet-Draft, draft-
> >               mattsson-cfrg-det-sigs-with-noise-04, 15 February 2022,
> >               <https://www.ietf.org/archive/id/draft-mattsson-cfrg-det-
> >               sigs-with-noise-04.txt>.
> >
> > Updated:
> >    [CFRG-DET-SIGS]
> >               Preuß Mattsson, J., Thormarker, E., and S. Ruohomaa,
> >               "Deterministic ECDSA and EdDSA Signatures with Additional
> >               Randomness", Work in Progress, Internet-Draft, draft-irtf-
> >               cfrg-det-sigs-with-noise-00, 8 August 2022,
> >               <https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-
> >               det-sigs-with-noise-00>.
> > -->
>
> WFM
>
> > 10)   <!-- [rfced] Throughout the text, the following terminology appears to be used
> > inconsistently. Please review these occurrences and let us know if/how they
> > may be made consistent.
> >
> > clear-text vs. cleartext
> >    Note: we updated 1 instance of "clear-text" to "cleartext"; if that
> >    is not correct, please let us know.
> >
> > Elliptic Curve vs. elliptic-curve vs. elliptic curve
> >
> >    Note: we made this consistent by using "elliptic curve" for general
> >    mentions and "Elliptic Curve" when part of a term or when followed by
> >    "Diffie-Hellman" per RFC 7525. Please review and let us know if any
> >    further updates are needed.
> > -->
>
> WFM
>
> > 11) <!-- [rfced] Please review the "Inclusive Language" portion of the online
> > Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
> > and let us know if any changes are needed.
> >
> > For example, please consider whether the following should be updated:
> >
> > "MITM attacker" (expanded to man-in-the-middle attacker)
> >    - A possible substitution could be, for example, "on-path attacker"
>
> I think we could use "active on-path attacker"
>
> > "extended_master_secret"
> >    - We expect this is not something that can be updated. Please let us
> >      know if we are incorrect.
> > -->
>
> Correct
>
> > Thank you.
>
> thank you!
>
> --
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.