Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)
draft-ietf-uta-rfc7525bis-11

[Ballot discuss]
Hi,

Thanks for this document, I think that it is a helpful update.  Disclaimer, I'm not a security expert, but I would like to discuss some of the RFC 2119 constraints that have been specified please:


(1)
I find some of the 2119 language to be somewhat contradictory:

  *  Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].

  *  Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to
    negotiate TLS version 1.2 over earlier versions of TLS.

The second sentence implies that a TLS 1.2 is allowed to negotiate earlier versions of TLS, but a previous statement indicates that this is not allowed.  A similar contradiction appears for DTLS:

  *  Implementations MUST NOT negotiate DTLS version 1.0 [RFC4347].

  *  Implementations MUST support DTLS 1.2 [RFC6347] and MUST prefer to
      negotiate DTLS version 1.2 over earlier versions of DTLS.


(2)
  *  New protocol designs that embed TLS mechanisms SHOULD use only TLS
      1.3 and SHOULD NOT use TLS 1.2; for instance, QUIC [RFC9001]) took
      this approach.  As a result, implementations of such newly-
      developed protocols SHOULD support TLS 1.3 only with no
      negotiation of earlier versions.

Why is this only a SHOULD and not a MUST?  If a new protocol (rather than an updated version of an existing protocol) was being designed why would it be reasonable to design it to support TLS 1.2?  If you want to keep these as SHOULD rather than MUSTs then please can the document specify under what circumstances it would be reasonable for a new protocol design to use TLS 1.2.


(3)
                                                          When TLS-only
      communication is available for a certain protocol, it MUST be used
      by implementations and MUST be configured by administrators.  When
      a protocol only supports dynamic upgrade, implementations MUST
      provide a strict local policy (a policy that forbids use of
      plaintext in the absence of a negotiated TLS channel) and
      administrators MUST use this policy.

The MUSTs feel too strong here, since there are surely deployments and streams of data where encryption, whilst beneficial, isn't an absolute requirement?

In addition "MUST be used by implementations and MUST be configured by administrators" also seem to conflict, i.e., if the implementation must use it then why would an administrator have to enable it?


(4) 
  When using RSA, servers MUST authenticate using certificates with at
  least a 2048-bit modulus for the public key.  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).

So, for clarity, this would presumably mean that SHA-256 is also preferred over say SHA-512?  Is that the intention?  Or would it be better if the SHOULD allowed stronger ciphers?

[Ballot comment]


  This document does not discuss the use of TLS in constrained-node
  networks [RFC7228].  For recommendations regarding the profiling of
  TLS and DTLS for small devices with severe constraints on power,
  memory, and processing resources, the reader is referred to [RFC7925]
  and [I-D.ietf-uta-tls13-iot-profile].

Would it be better to write "does not specify" rather than "does not discuss", which feels a bit colloquial?

Thanks,
Rob

[Ballot comment]
Thanks for working on this specification. It is certainly be useful.

Thanks to Magnus Westerlund for his TSVART review, which is done in a very short notice. Please treat his review comments as if those are mine.

[Ballot comment]
I suspect that I'm being dumb, but I cannot quite reconcile:

* Implementations MUST NOT negotiate SSL version 3.
* Implementations MUST NOT negotiate TLS version 1.0 [RFC2246].
* Implementations MUST NOT negotiate TLS version 1.1 [RFC4346].
with:
* Implementations MUST support TLS 1.2 [RFC5246] and **MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS** (emphasis added).

I don't understand the last part -- it seems like this equates to:
{
if (version == SSL3 || version == TLS1 || version == TLS1.1 ) { abort(); }
if (version >= 1.2) { do_stuff () };
}
I don't understand the "if (version >= 1.2)" check -- if I MUST NOT use SSL3, TLS1.0, TLS1.1, then isn't the only thing left >= TLS 1.2?
Not trying to be difficult, I really just don't understand what I'm missing...

[Ballot comment]
Thank you to Ben Kaduk for the SECDIR review.

** Section 3.2
  When TLS-only
  communication is available for a certain protocol, it MUST be used
  by implementations and MUST be configured by administrators.

This guidance seems a little vague but prescriptive.  Is the guidance that if there is a TLS-version or TLS support for a given protocol, that implementations of that protocol “MUST” support it?  My confusion is around the wording that “it must be used by implementations.”

** Section 3.2
When
a protocol only supports dynamic upgrade, implementations MUST
provide a strict local policy (a policy that forbids use of
plaintext in the absence of a negotiated TLS channel) and
administrators MUST use this policy.

Aren’t site administrators responsible for setting and enforcing local policy?  Why would the software vendor (implementations) be provided the policy?

** Section 3.3.1

-- Given that the recommendations of this section include things beyond certificate compression, is the title of “Certificate Compression” appropriate?

-- Would there be any additional techniques to list per Section 4 of RFC9191?

** Section 4.4
When a sender is approaching CL, the implementation SHOULD initiate a
new handshake (or in TLS 1.3, a Key Update) to rotate the session
key.

When a receiver has reached IL, the implementation SHOULD close the
connection.

Should these normative SHOULDs be MUSTs?  What is the circumstance where it would be prudent or necessary sender to use the existing key material after the CL has been exceeded?  Same issue on the IL limit.

[Ballot comment]
# GEN AD review of draft-ietf-uta-rfc7525bis-09

CC @larseggert

Thanks to Tim Evens for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/Cm6WU_TE-rTbHuLT1WLLc26vrl0).

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 1, paragraph 6
```
-    implementations, assuming the implementer expects his or her code to
-                                                      ^^^^^^^
+    implementations, assuming the implementer expects their code to
+                                                      ^  +
```

### Duplicate references

Duplicate informative references to: `rfc7672`.

### Outdated references

Reference `[RFC8740]` to `RFC8740`, which was obsoleted by `RFC9113` (this may
be on purpose).

Reference `[RFC5246]` to `RFC5246`, which was obsoleted by `RFC8446` (this may
be on purpose).

Reference `[RFC6347]` to `RFC6347`, which was obsoleted by `RFC9147` (this may
be on purpose).

Reference `[RFC4346]` to `RFC4346`, which was obsoleted by `RFC5246` (this may
be on purpose).

Reference `[RFC4347]` to `RFC4347`, which was obsoleted by `RFC6347` (this may
be on purpose).

Reference `[RFC6961]` to `RFC6961`, which was obsoleted by `RFC8446` (this may
be on purpose).

Reference `[RFC2246]` to `RFC2246`, which was obsoleted by `RFC4346` (this may
be on purpose).

Reference `[RFC5077]` to `RFC5077`, which was obsoleted by `RFC8446` (this may
be on purpose).

Reference `[RFC7507]` to `RFC7507`, which was obsoleted by `RFC8996` (this may
be on purpose).

### URLs

These URLs in the document did not return content:

* https://www.cabforum.org/documents.html

### Grammar/style

#### Section 1, paragraph 7
```
rabilities than TLS 1.2 or below. Therefore this document replaces [RFC7525],
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Therefore".

#### Section 1, paragraph 8
```
n and deployment scenarios, with the exception of unauthenticated TLS (see S
                            ^^^^^^^^^^^^^^^^^^^^^
```
Consider using "except" or "except for".

#### Section 3.1.1, paragraph 11
```
is significantly easier and less error prone than secure deployment of TLS 1
                                ^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 3.3.1, paragraph 4
```
used when encrypting the ticket (as least as strong as the main TLS cipher su
                                    ^^^^^
```
Did you mean "less", "little"? Or "at least"?

#### Section 3.9, paragraph 1
```
h the server and the client side. Typically this extends to both the TLS libr
                                  ^^^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "Typically".

#### Section 4.2, paragraph 6
```
l interoperability, except with extremely old clients. As with other cipher
                                ^^^^^^^^^^^^^
```
Consider using an extreme adjective for "old".

#### Section 4.4, paragraph 3
```
ther demonstrates that 1024-bit Diffie Hellman parameters should be avoided.
                                ^^^^^^^^^^^^^^
```
This word is normally spelled with a hyphen.

#### Section 4.4, paragraph 8
```
cipher suites recommended above. However it does apply to most other TLS ci
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 5.1, paragraph 9
```
s discovered indirectly and in an insecure manner (e.g., by an insecure DNS q
                            ^^^^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "insecurely" to avoid wordiness.

#### Section 5.2, paragraph 1
```
AES-GCM getting implemented in an insecure way and thus making TLS sessions
                            ^^^^^^^^^^^^^^^^^^
```
Consider replacing this phrase with the adverb "insecurely" to avoid wordiness.

#### Section 7.3, paragraph 12
```
n database cannot scale beyond a small number of the most heavily used Web se
                              ^^^^^^^^^^^^^^^^^
```
Specify a number, remove phrase, use "a few", or use "some".

#### Section 7.4, paragraph 5
```
o the CertificateEntry structure. However using this facility remains imprac
                                  ^^^^^^^
```
A comma may be missing after the conjunctive/linking adverb "However".

#### Section 7.5, paragraph 1
```
lient authentication, but we recommend to review the operational conditions b
                            ^^^^^^^^^^^^^^^^^^^
```
The verb "recommend" is used with the gerund form.

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool

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

### 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' ?

### 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 ?

### 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 ?

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

### Section 3.1.3 SCSV

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

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

### Section 4.1 post-quantum crypto

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

### Section 4.5 TWIRL ?

Should "TWIRL" be expanded ? or at least given a reference ?

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues.

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-uta-rfc7525bis-06, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

Michelle Thangtamsatid
IANA Services Specialist

The following Last Call announcement was sent out (ends 2022-05-30):

From: The IESG
To: IETF-Announce
CC: draft-ietf-uta-rfc7525bis@ietf.org, francesca.palombini@ericsson.com, leifj@sunet.se, uta-chairs@ietf.org, uta@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)) to Best Current Practice


The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'Recommendations for Secure Use of
Transport Layer Security (TLS) and
  Datagram Transport Layer Security (DTLS)'
  as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2022-05-30. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  Transport Layer Security (TLS) and Datagram Transport Layer Security
  (DTLS) are widely used to protect data exchanged over application
  protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
  years, the industry has witnessed several serious attacks on TLS and
  DTLS, including attacks on the most commonly used cipher suites and
  their modes of operation.  This document provides recommendations for
  improving the security of deployed services that use TLS and DTLS.
  The recommendations are applicable to the majority of use cases.

  An earlier version of this document was published as RFC 7525 when
  the industry was in the midst of its transition to TLS 1.2.  Years
  later this transition is largely complete and TLS 1.3 is widely
  available.  This document updates the guidance, given the new
  environment.  In addition, the document updates RFC 5288 and RFC 6066
  in view of recent attacks.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-uta-rfc7525bis/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7465: Prohibiting RC4 Cipher Suites (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6347: Datagram Transport Layer Security Version 1.2 (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6176: Prohibiting Secure Sockets Layer (SSL) Version 2.0 (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc5746: Transport Layer Security (TLS) Renegotiation Indication Extension (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc7627: Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc8740: Using TLS 1.3 with HTTP/2 (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc7301: Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc8422: Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Versions 1.2 and Earlier (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc9155: Deprecating MD5 and SHA-1 Signature Hashes in TLS 1.2 and DTLS 1.2 (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6125: Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS) (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc5288: AES Galois Counter Mode (GCM) Cipher Suites for TLS (Proposed Standard - Internet Engineering Task Force (IETF))
    rfc6066: Transport Layer Security (TLS) Extensions: Extension Definitions (Proposed Standard - Internet Engineering Task Force (IETF))

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP. This is the correct type of RFC, since the document provides recommendations for improving the security of deployed services that use TLS and DTLS.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Transport Layer Security (TLS) and Datagram Transport Layer Security
  (DTLS) are widely used to protect data exchanged over application
  protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
  years, the industry has witnessed several serious attacks on TLS and
  DTLS, including attacks on the most commonly used cipher suites and
  their modes of operation.  This document provides recommendations for
  improving the security of deployed services that use TLS and DTLS.
  The recommendations are applicable to the majority of use cases.

  This document was published as RFC 7525 when the industry was in the
  midst of its transition to TLS 1.2.  Years later this transition is
  largely complete and TLS 1.3 is widely available.  Given the new
  environment, updated guidance is needed.

Working Group Summary:

The only signifficant challenge has been that the TLS wg keeps getting proposed work that should really have been sent to UTA and the RFC7525 bis work much more quickly. This has led to a number of "resets" and two separate WGLCs.

Document Quality:

The document is clear and has been widely cited and used in the industry

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Leif Johansson is the Document Shepherd, Francesca Palombini is the Responsible Area Director.

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document and have no concerns other than that there is a risk that a bisbis document will have to be created soon because new research into TLS keeps bringing up issues.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

There has been extensive reivew by the WG during two WGLCs that also resulted in changes and improvements. The document is ready as is.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not at this point

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The support is strong. There are no issues here.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a couple of downrefs but these are mainly because the document is deprecating stuff.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

None

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes, cf above on idnits.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, updating RFC7525

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA actions

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not applicable

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Transport Layer Security (TLS) and Datagram Transport Layer Security
  (DTLS) are widely used to protect data exchanged over application
  protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
  years, the industry has witnessed several serious attacks on TLS and
  DTLS, including attacks on the most commonly used cipher suites and
  their modes of operation.  This document provides recommendations for
  improving the security of deployed services that use TLS and DTLS.
  The recommendations are applicable to the majority of use cases.

  This document was published as RFC 7525 when the industry was in the
  midst of its transition to TLS 1.2.  Years later this transition is
  largely complete and TLS 1.3 is widely available.  Given the new
  environment, updated guidance is needed.

Working Group Summary:

The only signifficant challenge has been that the TLS wg keeps getting proposed work that should really have been sent to UTA and the RFC7525 bis work much more quickly. This has led to a number of "resets" and two separate WGLCs.

Document Quality:

The document is clear and has been widely cited and used in the industry

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Leif Johansson

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document and have no concerns other than that there is a risk that a bisbis document will have to be created soon because new research into TLS keeps bringing up issues.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

There has been extensive reivew by the WG during two WGLCs that also resulted in changes and improvements. The document is ready as is.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not at this point

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The support is strong. There are no issues here.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a couple of downrefs but these are mainly because the document is deprecating stuff.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

None

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes, cf above on idnits.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, updating RFC7525

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA actions

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not applicable

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up. Changes are expected over time.

This version is dated 1 November 2019.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?

BCP

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:

Technical Summary:

Transport Layer Security (TLS) and Datagram Transport Layer Security
  (DTLS) are widely used to protect data exchanged over application
  protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
  years, the industry has witnessed several serious attacks on TLS and
  DTLS, including attacks on the most commonly used cipher suites and
  their modes of operation.  This document provides recommendations for
  improving the security of deployed services that use TLS and DTLS.
  The recommendations are applicable to the majority of use cases.

  This document was published as RFC 7525 when the industry was in the
  midst of its transition to TLS 1.2.  Years later this transition is
  largely complete and TLS 1.3 is widely available.  Given the new
  environment, updated guidance is needed.

Working Group Summary:

The only signifficant challenge has been that the TLS wg keeps getting proposed work that should really have been sent to UTA and the RFC7525 bis work much more quickly. This has led to a number of "resets" and two separate WGLCs.

Document Quality:

The document is clear and has been widely cited and used in the industry

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Leif Johansson

(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.

I have reviewed the document and have no concerns other than that there is a risk that a bisbis document will have to be created soon because new research into TLS keeps bringing up issues.

(4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?

There has been extensive reivew by the WG during two WGLCs that also resulted in changes and improvements. The document is ready as is.

(5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.

Not at this point

(6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.

No specific concerns

(7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?

Yes

(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.

No IPR disclosures

(9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?

The support is strong. There are no issues here.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

There are a couple of downrefs but these are mainly because the document is deprecating stuff.

(12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

Not applicable

(13) Have all references within this document been identified as either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?

None

(15) Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.

Yes, cf above on idnits.

(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

Yes, updating RFC7525

(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

No IANA actions

(18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.

None

(19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, YANG modules, etc.

Not applicable

(20) If the document contains a YANG module, has the module been checked with any of the recommended validation tools (https://trac.ietf.org/trac/ops/wiki/yang-review-tools) for syntax and formatting validation? If there are any resulting errors or warnings, what is the justification for not fixing them at this time? Does the YANG module comply with the Network Management Datastore Architecture (NMDA) as specified in RFC8342?

Not applicable