Skip to main content

Shepherd writeup

(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 

  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.


  Who is the Document Shepherd? Who is the Responsible Area

  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.


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

  A third party IPR disclosure has been filed for the
  document  The disclosure is
  the same as for TLS 1.2.  The following disclosure 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.) 


(11) Identify any ID nits the Document Shepherd has found in this
document. (See and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be

  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?


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


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