(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?
This draft is targeted at “Proposed Standard” and it is completely
appropriate given the expected widescale deployment as well as
the fact that TLS 1.2 was “Proposed Standard” and dependency
of other protocols on TLS1.3 (e.g., QUIC). Yes the header indicates
“Proposed Standard”.
(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
This document specifies version 1.3 of the Transport Layer Security
(TLS) protocol. TLS allows client/server applications to communicate
over the Internet in a way that is designed to prevent eavesdropping,
tampering, and message forgery.
Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
The document is the work product of the members of the TLS
WG. There is strong consensus in the working group for this
document. The area that was most controversial was around
the inclusion of a 0-RTT mode that has different security
properties than the rest of TLS. s1.3 lists the major differences
from TLS1.2, as agreed by the contributors; we do not think
that the RFC needs to list the changes that occurred between
each draft.
The draft has had 3 WGLCs to address various issues. At this
point there are no known outstanding issue.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
There are over 10 interoperable implementations of the
protocol from different sources written in different
languages. Major web browser vendors and TLS
library vendors have draft implementations or have
indicated they will support the protocol. In addition to
having extensive review in the TLS working group,
the protocol has received unprecedented security
review by the academic community. Several TRON (TLS
Ready or Not) conferences were held in conjunction with
the academic community to give them a chance to present
their findings for TLS. These conferences resulted in
improvements to the protocol.
Please note that ID-nits complains about the obsoleted/
updated RFCs not being listed in the abstract. This is
intentional because the abstract is now a concise and
comprehensive overview and is free form citations, as
per RFC7322.
Personnel
Who is the Document Shepherd? Who is the Responsible Area
Director?
The Document Shepherd is Sean Turner.
The responsible AD is Kathleen Moriarty.
(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.
The document shepherd has reviewed the document and believes
it is ready for publication
(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
No. Extensive review has been performed on this document.
Interoperable implementations exist.
(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.
This document has had extensive review form the security and
cryptographic community.
(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.
The previous AD had concerns with the 0-RTT mode that supports early
data. This early data is subject to replay attacks and is only safe to use
when the replay of data does not have negative consequences. Note
that s2.3 (page 21) provides a warning about the use of early data and
indicates that protocols MUST NOT use it unless there is an application
profile for early data’s use.
(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.
A third party IPR disclosure has been filed for the
document https://datatracker.ietf.org/ipr/2900/. The disclosure is
the same as for TLS 1.2. The following disclosure
https://datatracker.ietf.org/ipr/1044/ states that implementors
do not need a license.
(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?
There is strong consensus from a large number of individuals
in the working group.
(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 https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
ID Nits complains about missing obsoletes/updates information in
the abstract, but see the response to question #16 for information
about these nits.
There are some incorrectly noted missing references; these are part
of figures or the presentation syntax.
Two obsolete informational references are noted, but these should
remain because the references work as is; the registries were originally
defined in 4346 and 4366, i.e., the fact these RFCs were updated later
is irrelevant.
There are downref-related nits noted, but these are addressed by
question #15.
(12) Describe how the document meets any required formal review
criteria, such as the MIB 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?
No
(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.
ID nits reports three possible downrefs: SHS, X690, and X962.
None of these are downrefs.
ID nits also reports 8 downrefs: RFCs 2104 and 5869 are
already in the downref registry; RFCs 6962, 6979, 7539, 7748, 8017,
and 8032 are not; RFC8017 was as RFC 3447. 6962 (Certificate
Transparency) is an experimental RFC; 6979 is referred to
normatively by many other drafts and frankly this is an “algorithm”
reference so this is totally normal (algorithms are always
informational); 7539, 7749, and 8032 are already referred
to normatively by many RFCs so it seems like all of these should
already be in the downref registry and shouldn’t be an issue.
These 5 RFCs (6962, 6979, 7539, 7748, 8017, and 8032) need to
be included in the IETF LC and then they need to be added to the
downref registry ;)
Note that references to RFC 4346 and 4366 are intentional.
(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.
This draft obsoletes 2 drafts and updates 4. They are listed on the
title page, not listed in the abstract, and are discussed in the
introduction. The chairs and author feel this is sufficient, i.e., we
don’t need it in the abstract. Few people can remember without
context what the contents of an RFC are the author and chairs both
feel that the explanation in s1 (last para) is sufficient. Note that
other appropriate locations also repeat the updates/obsoletes, e.g.,
s2.3, s.4.2.6.
The one interesting obsoletes/updates issue is that this draft does
include optional updates for TLS1.2 that a TLS1.3 implementation
might want to support to negotiate TLS1.2. It would look odd to
include 5246 in both the updates and obsoletes header fields and
overall we’re obsoleting 5246 so that’s what was done, i.e., 5246
is obsoleted by this document but not updated by it.
(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 5226).
The changes to IANA’s TLS-related registries as a result of TLS1.3
are quite extensive, but most of them are made in
https://datatracker.ietf.org/doc/draft-ietf-tls-iana-registry-updates/.
The changes to registry policies are also reflected in
draft-ietf-tls-tls13 when the registry was retained. Note that some
registries have been orphaned and some have had space allocated
for TLS1.3 and pre-TLS1.3.
(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.
This draft creates one new registry: TLS SignatureScheme Registry.
The registry is divided between Specification Required and Private
Use space. The registration policies for this space align with similar
TLS-related registries
(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, etc.
There have been numerous published analyses of the security of some
or all of TLS 1.3, including at least three using automatic theorem provers
(ProVerif, Tamarin, and F*). A detailed list of papers analyzing TLS 1.3
can be found in Appendix E.