The Transport Layer Security (TLS) Protocol Version 1.3
draft-ietf-tls-tls13-28

[Ballot comment]
Nice work. Of course, no one reads a 150-page document without wondering about a few things ...

I suspect that

  Because
  TLS 1.3 changes the way keys are derived it updates [RFC5705] as
  described in Section 7.5 it also changes how OCSP messages are
  carried and therefore updates [RFC6066] and obsoletes [RFC6961] as
  described in section Section 4.4.2.1.

is a run-on sentence. Perhaps a period after "section 7.5"?

Is "forward secrecy" (the term used in this draft) the same thing as "perfect forward secrecy" (the term I hear most often, and it does appear in one reference title)?

The use of "mandatory" as the name of a vector in 

  In the following example, mandatory is a vector that must contain
  between 300 and 400 bytes of type opaque.

was pretty hard to parse until I read further. Did anyone else find that confusing?

In this text,

  When multiple extensions of different types are present, the
  extensions MAY appear in any order, with the exception of
  "pre_shared_key" Section 4.2.11 which MUST be the last extension in
  the ClientHello.  There MUST NOT be more than one extension of the
  same type in a given extension block.

I didn't see what to do if the MUST NOT is violated. Is that worth mentioning?

In this text,

  An
  implementation which receives any other change_cipher_spec value or
  which receives a protected change_cipher_spec record MUST abort the
  handshake with an "unexpected_message" alert.  A change_cipher_spec
  record received before the first ClientHello message or after the
  peer's Finished message MUST be treated as an unexpected record type.

  Implementations MUST NOT send record types not defined in this
  document unless negotiated by some extension.  If a TLS
  implementation receives an unexpected record type, it MUST terminate
  the connection with an "unexpected_message" alert.  New record
  content type values are assigned by IANA in the TLS Content Type
  Registry as described in Section 11.

I wondered if there was a difference between an unexpected record type and and unexpected message.

I wondered why

  Newer
  clients or servers, when communicating with newer peers, SHOULD
  negotiate the most preferred common parameters.

was not a MUST.

[Ballot comment]
Thank you for a well written document. I trust that the following DISCUSS point will be addressed:

Relationship to TLS 1.2 needs to be clarified. The document is adding requirements on TLS 1.2 clients. Implementors of TLS 1.2 are not going to (or very unlikely to) read this document. This looks fishy to me. Two examples on page 37:

  TLS 1.2 clients SHOULD also check that the last eight bytes  are not equal to the second value if the ServerHello indicates TLS  1.1 or below

and

A legacy TLS client performing renegotiation with TLS 1.2 or prior  and which receives a TLS 1.3 ServerHello during renegotiation MUST  abort the handshake with a "protocol_version" alert.  Note that  renegotiation is not possible when TLS 1.3 has been negotiated.

There are similar statements on page 45:

  TLS 1.2 implementations SHOULD also process this extension.

and on page 48:

  However, the old semantics did not constrain the signing
  curve.  If TLS 1.2 is negotiated, implementations MUST be prepared
  to accept a signature that uses any curve that they advertised in
  the "supported_groups" extension.

I think you need to clarify whether these normative requirements apply to pure TLS 1.2 clients or TLS clients that implement both 1.2 and 1.3 and choose to use 1.2 for some reason. Or maybe you need to say in the Abstract/Introduction that although this document obsoletes TLS 1.2 it also specifies new requirements on TLS 1.2 implementations. (So it is sort of both "Obsoletes" and "Updates" TLS 1.2 RFC.)

Other comments:

1) On page 47:
The length of the salt MUST be equal to the length of the digest      algorithm

Length of algorithm?

2) DER need a Normative Reference on first use. There are some references on 2nd/3rd use.

3) On page 57:

  The
  server then ignores early data by attempting to decrypt received
  records in the handshake traffic keys until it is able to receive
  the client's second flight and complete an ordinary 1-RTT
  handshake, skipping records that fail to decrypt, up to the
  configured max_early_data_size.

I read this several times and still don't understand what this is saying. It is saying "ignores ... until it is able to receive". I think you either don't mean "ignore" (as in discard the rest) or I misunderstood. I clarifying example or a reference to another section (e.g. with the diagram) would be very helpful here.

4) On page 82:

  When record protection has not yet been engaged, TLSPlaintext  structures are written directly onto the wire.  Once record  protection has started, TLSPlaintext records are protected and sent  as described in the following section

Just to double check: are you saying that before the handshake TLS application layer effectively results in plain text messages (with some extra octets to signal record type)?

5) I am pretty sure that [RFC5116] is a Normative reference. It is required to be understood to implemented TLS 1.3. Also, you have additional requirements on AEADs, which again implies understanding of what they are:

On page 84:

  An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion  greater than 255 octets

and

  An AEAD algorithm where N_MAX is less than 8  bytes MUST NOT be used with TLS

6) The diagram in section 7.1 was a bit cryptic. Maybe explain that when you use '0' you mean as many bytes of 0s as needed for various functions.

[Ballot discuss]
Thank you for a well written document. I will be switching to Yes once the following is addressed/discussed:

Relationship to TLS 1.2 needs to be clarified. The document is adding requirements on TLS 1.2 clients. Implementors of TLS 1.2 are not going to (or very unlikely to) read this document. This looks fishy to me. Two examples on page 37:

  TLS 1.2 clients SHOULD also check that the last eight bytes  are not equal to the second value if the ServerHello indicates TLS  1.1 or below

and

A legacy TLS client performing renegotiation with TLS 1.2 or prior  and which receives a TLS 1.3 ServerHello during renegotiation MUST  abort the handshake with a "protocol_version" alert.  Note that  renegotiation is not possible when TLS 1.3 has been negotiated.

There are similar statements on page 45:

  TLS 1.2 implementations SHOULD also process this extension.

and on page 48:

  However, the old semantics did not constrain the signing
  curve.  If TLS 1.2 is negotiated, implementations MUST be prepared
  to accept a signature that uses any curve that they advertised in
  the "supported_groups" extension.

I think you need to clarify whether these normative requirements apply to pure TLS 1.2 clients or TLS clients that implement both 1.2 and 1.3 and choose to use 1.2 for some reason. Or maybe you need to say in the Abstract/Introduction that although this document obsoletes TLS 1.2 it also specifies new requirements on TLS 1.2 implementations. (So it is sort of both "Obsoletes" and "Updates" TLS 1.2 RFC.)

[Ballot comment]
1) On page 47:
The length of the salt MUST be equal to the length of the digest      algorithm

Length of algorithm?

2) DER need a Normative Reference on first use. There are some references on 2nd/3rd use.

3) On page 57:

  The
  server then ignores early data by attempting to decrypt received
  records in the handshake traffic keys until it is able to receive
  the client's second flight and complete an ordinary 1-RTT
  handshake, skipping records that fail to decrypt, up to the
  configured max_early_data_size.

I read this several times and still don't understand what this is saying. It is saying "ignores ... until it is able to receive". I think you either don't mean "ignore" (as in discard the rest) or I misunderstood. I clarifying example or a reference to another section (e.g. with the diagram) would be very helpful here.

4) On page 82:

  When record protection has not yet been engaged, TLSPlaintext  structures are written directly onto the wire.  Once record  protection has started, TLSPlaintext records are protected and sent  as described in the following section

Just to double check: are you saying that before the handshake TLS application layer effectively results in plain text messages (with some extra octets to signal record type)?

5) I am pretty sure that [RFC5116] is a Normative reference. It is required to be understood to implemented TLS 1.3. Also, you have additional requirements on AEADs, which again implies understanding of what they are:

On page 84:

  An AEAD algorithm used in TLS 1.3 MUST NOT produce an expansion  greater than 255 octets

and

  An AEAD algorithm where N_MAX is less than 8  bytes MUST NOT be used with TLS

6) The diagram in section 7.1 was a bit cryptic. Maybe explain that when you use '0' you mean as many bytes of 0s as needed for various functions.

[Ballot comment]
Thanks to the many pages of people who worked on this document. The result is
surprisingly clear and easy to understand. I'm excited to see TLS 1.3 complete,
and look forward to its widespread deployment.

I have a handful of substantive comments (which may be as much as result of my
unfamiliarity with some of the underlying technologies), followed by several
editorial nits.

===========================================================================
Substantive Comments
---------------------------------------------------------------------------

Abstract:

This document obsoletes 5077, 5246, and 6961; and updates 4492, 5705, and 6066.
Please mention these in the abstract; see
§3.1.D

---------------------------------------------------------------------------

§4.2.1:

>  TLS SHOULD support TLS 1.2.  Servers should be prepared to receive
>  ClientHellos that include this extension but do not include 0x0304 in
>  the list of versions.

This "should" reads as if it should be normative. It also seems that making this
"should" instead of "MUST" could result in the same "can't negotiate to earlier
versions" implementation situation that is mentioned elsewhere in the document.
Consider a server that supports TLS 1.2 and TLS 1.3. It receives a ClientHello
from a client that supports TLS 1.2 and a future TLS 1.4. Let's postulate that
this client doesn't support 1.3 (say, because of some uncurable flaw that
exists in 1.3, but not in 1.2 or 1.4). If the server isn't prepared to deal
with this situation, we end up in the same "can't move versions forward"
corner that led to freezing the legacy version string at 0x0303.

---------------------------------------------------------------------------

§4.2.3:

>        /* Reserved Code Points */
>        private_use(0xFE00..0xFFFF),
>        (0xFFFF)
>    } SignatureScheme;

When a node supports both TLS 1.2 and TLS 1.3, this private use space only
allows for the definition of two private-use hashes that can be used in both
circumstances (as only 0xFE and 0xFF will be recognized by 1.2 as specifying
hashes). I don't know what the use cases for this private use space is; but
given the relatively generous allocation in RFC 5246, is two going to be enough?

---------------------------------------------------------------------------

§5.5:

>  There are cryptographic limits on the amount of plaintext which can
>  be safely encrypted under a given set of keys.  [AEAD-LIMITS]
>  provides an analysis of these limits under the assumption that the
>  underlying primitive (AES or ChaCha20) has no weaknesses.
>  Implementations SHOULD do a key update as described in Section 4.6.3
>  prior to reaching these limits.

Implementing this "SHOULD" is predicated on understanding the contents of
[AEAD-LIMITS], which means [AEAD-LIMITS] needs to be a normative reference.

---------------------------------------------------------------------------

§11:

>  -  TLS SignatureScheme Registry: Values with the first byte in the
>    range 0-253 (decimal) are assigned via Specification Required
>    [RFC8126].  Values with the first byte 254 or 255 (decimal) are
>    reserved for Private Use [RFC8126].  Values with the first byte in
>    the range 0-6 or with the second byte in the range 0-3 that are
>    not currently allocated are reserved for backwards compatibility.

Unless I misunderstand the compatibility mechanisms here, the reservation of
first byte=0-6 seems to assume that no further assignments will be made from
the "TLS HashAlgorithm Registry" (after 4492bis lands). If this is the case, I
would expect the IANA considerations section to include a request that the IANA
close the table to further registrations. The same comment applies to TLS
SignatureAlgorithm Registry.

---------------------------------------------------------------------------

Appendix B:

This is a consolidation of the structures found in the document. Presumably,
Appendix B is normative and the other versions are illustrative? To help deal
with the possibility of conflicts between the two versions, it would be nice if
this were stated explicitly.

===========================================================================
Editorial Nits
---------------------------------------------------------------------------

General:

  ** There are 33 instances of too long lines in the document, the longest
    one being 8 characters in excess of 72.

---------------------------------------------------------------------------

General:

Although both "implementor" and "implementer" are acceptable spellings,
it is unusual for a document to switch back and forth. I recommend consistency.

---------------------------------------------------------------------------

§1:

>  the protocol attributes used to negotiate Elliptic Curves.  Because
>  TLS 1.3 changes the way keys are derived it updates [RFC5705] as

"...derived, it..."

>  described in Section 7.5 it also changes how OCSP messages are

"...Section 7.5. It also..."

---------------------------------------------------------------------------

§1.3:

>  -  Elliptic curve algorithms are now in the base spec and includes
>    new signature algorithms, such as ed25519 and ed448.  TLS 1.3

s/includes/include/

---------------------------------------------------------------------------

§3.4:

>  All values, here and elsewhere in the specification, are stored in
>  network byte (big-endian) order; the uint32 represented by the hex

s/stored/transmitted/

---------------------------------------------------------------------------

§4.2.3:

>  RSASSA-PSS PSS algorithms  Indicates a signature algorithm using
>    RSASSA-PSS [RFC8017] with mask generation function 1.  The digest
>    used in the mask generation function and the digest being signed
>    are both the corresponding hash algorithm as defined in [SHS].
>    The length of the salt MUST be equal to the length of the digest
>    algorithm.  If the public key is carried in an X.509 certificate,
>    it MUST use the RSASSA-PSS OID [RFC5756].  When used in
>    certificate signatures, the algorithm parameters MUST be DER
>    encoded.  If the corresponding public key's parameters present,

"...parameters are present,..."

---------------------------------------------------------------------------

§4.2.6:

>  The "post_handshake_auth" extension is used to indicate that a client
>  is willing to perform post-handshake authentication Section 4.6.2.

"...authentication (Section 4.6.2)."

---------------------------------------------------------------------------

§4.2.11.1:

>  The client's view of the age of a ticket is the time since the
>  receipt of the NewSessionTicket message.  Clients MUST NOT attempt to
>  use tickets which have ages greater than the "ticket_lifetime" value
>  which was provided with the ticket.  The "obfuscated_ticket_age"
>  field of each PskIdentity contains an obfuscated version of the
>  ticket age formed by taking the age in milliseconds and adding the
>  "ticket_age_add" value that was included with the ticket, see
>  Section 4.6.1 modulo 2^32.

"...the ticket (see Section 4.1.6), modulo 2^32."

---------------------------------------------------------------------------

§4.4.3:

>  The context string for a server signature is "TLS 1.3, server
>  CertificateVerify" and for a client signature is "TLS 1.3, client
>  CertificateVerify".  It is used to provide separation between
>  signatures made in different contexts, helping against potential
>  cross-protocol attacks.

Although the example makes it clear, the preceding is the normative description
of behavior. Since the limitations of the RFC format result in line wrapping in
the middle of two strings that must be bit exact for the protocol to function,
it is probably worthwhile setting them off on their own lines so that they don't
contain extra line feeds and indenting spaces.

---------------------------------------------------------------------------

§7.4.1:

>  For finite field groups, a conventional Diffie-Hellman computation is
>  performed.  The negotiated key (Z) is converted to a byte string by
>  encoding in big-endian and padded with zeros up to the size of the
>  prime.

Presumably "...and left padded...", correct?

---------------------------------------------------------------------------

§12.2:

>  [DOW92]    Diffie, W., van Oorschot, P., and M. Wiener,
>            ""Authentication and authenticated key exchanges"",
>            Designs, Codes and Cryptography , 1992.

The ""quoting"" here is odd

>  [HCJ16]    Husak, M., Čermak, M., Jirsik, T., and P.
>            Čeleda, "HTTPS traffic analysis and client
>            identification using passive SSL/TLS fingerprinting",
>            EURASIP Journal on Information Security Vol. 2016,
>            DOI 10.1186/s13635-016-0030-7, February 2016.

s/&268;/"/g

---------------------------------------------------------------------------

§12.3:

This section seems superfluous.

---------------------------------------------------------------------------

§E.1.1:

>  more invocations of HKDF-Expand.  This ordering should always be
>  followed (including in future revisions of this document), in
>  particular, one SHOULD NOT use an output of HKDF-Extract as an input

"...of this document); in particular, one..."
                    ^

---------------------------------------------------------------------------

§E.6:

>  Although TLS 1.3 does not use RSA key transport and so is not
>  directly susceptible to Bleichenbacher-type attacks

It seems that this should cite "Chosen ciphertext attacks against protocols
based on the RSA encryption standard PKCS #1".

===========================================================================

General (deferred to the end due to length):

As a rule of thumb, "that" is used to start restrictive clauses ("Two doors
are in front of you. The door that is on the right leads outside"), while
"which" is used to start non-restrictive clauses ("The only door in the room,
which is made of wood, leads outside.") This document uses "which" where "that"
is called for in numerous locations. Although there are several more than listed
below, I'm highlighting the locations where a literal reading of "which"
technically leads to ambiguity. Each instance has a leading line for context
(except those that occur at the beginning of a paragraph).

§1.1:
>    server: The endpoint which did not initiate the TLS connection.

§1.3:
>      favor of a version list in an extension.  This increases
>      compatibility with servers which incorrectly implemented version

§4:
>    Protocol messages MUST be sent in the order defined in Section 4.4.1
>    and shown in the diagrams in Section 2.  A peer which receives a

§4.1.2:
>      alert.  Note that TLS 1.3 servers might receive TLS 1.2 or prior
>      ClientHellos which contain other compression methods and MUST

§4.1.3:
>    cipher_suite  The single cipher suite selected by the server from the
>      list in ClientHello.cipher_suites.  A client which receives a

>    TLS 1.3 has a downgrade protection mechanism embedded in the server's
>    random value.  TLS 1.3 servers which negotiate TLS 1.2 or below in

§4.1.4:
>    compute partial hash transcripts for multiple hashes in the second
>    ClientHello.  A client which receives a cipher suite that was not

§4.2.1:
>    The "supported_versions" extension is used by the client to indicate
>    which versions of TLS it supports and by the server to indicate which

>    Implementations of this specification MUST send this extension
>    containing all versions of TLS which they are prepared to negotiate

>    If this extension is not present, servers which are compliant with

>    version prior to TLS 1.2 if one side supports a sparse range.
>    Implementations of TLS 1.3 which choose to support prior versions of

>    A server which negotiates a version of TLS prior to TLS 1.3 MUST set

>    ServerHello.version and MUST NOT send the "supported_versions"
>    extension.  A server which negotiates TLS 1.3 MUST respond by sending

§4.2.3:
>    present, then the "signature_algorithms" extension also applies to
>    signatures appearing in certificates.  Clients which desire the

>    The "signature_algorithms_cert" extension was added to allow
>    implementations which supported different sets of algorithms for

>    TLS 1.2 implementations SHOULD also process this extension.
>    Implementations which have the same policy in both cases MAY omit the

>    takes as input an arbitrary-length message, rather than a digest.
>    Algorithms which traditionally act on a digest should be defined in

>      as defined in [SHS].  These values refer solely to signatures
>      which appear in certificates (see Section 4.4.2.2) and are not

>    Legacy algorithms  Indicates algorithms which are being deprecated

>      RSASSA-PKCS1-v1_5 or ECDSA.  These values refer solely to
>      signatures which appear in certificates (see Section 4.4.2.2) and

§4.2.4:
>    [RFC6066], but is more complicated, is not used in TLS 1.3 (although
>    it may appear in ClientHello messages from clients which are offering

§4.2.5:
>    The "oid_filters" extension allows servers to provide a set of OID/
>    value pairs which it would like the client's certificate to match.

§4.2.6:
>    Servers MUST NOT send a post-handshake CertificateRequest to clients
>    which do not offer this extension.  Servers MUST NOT send this

§4.2.7:
>    When sent by the client, the "supported_groups" extension indicates
>    the named groups which the client supports for key exchange, ordered

§4.2.8:
>    MUST verify that (1) the selected_group field corresponds to a group
>    which was provided in the "supported_groups" extension in the

>    original ClientHello; and (2) the selected_group field does not
>    correspond to a group which was provided in the "key_share" extension

§4.2.10:
>    NewSessionTicket message, the associated values are those which were
>    negotiated in the connection which established the PSK.  The PSK used

>    A server which receives an "early_data" extension MUST behave in one

§4.2.11.1:
>    receipt of the NewSessionTicket message.  Clients MUST NOT attempt to
>    use tickets which have ages greater than the "ticket_lifetime" value

>    use tickets which have ages greater than the "ticket_lifetime" value
>    which was provided with the ticket.  The "obfuscated_ticket_age"

§4.2.11.2:
>    message (Section 4.4.4) but with the BaseKey being the binder_key
>    derived via the key schedule from the corresponding PSK which is


§4.3.2:
>    A server which is authenticating with a certificate MAY optionally

>    certificate_request_context  An opaque string which identifies the

>    certificate_request_context  An opaque string which identifies the
>      certificate request and which will be echoed in the client's

>    In prior versions of TLS, the CertificateRequest message carried a
>    list of signature algorithms and certificate authorities which the

>    Servers which are authenticating with a PSK MUST NOT send the

§4.4.2:
>    potentially extraneous certificates and arbitrary orderings from any
>    TLS version, with the exception of the end-entity certificate which


§4.4.2.4:
>    Any endpoint receiving any certificate which it would need to

>    and it is RECOMMENDED that any endpoint receiving any certificate
>    which it would need to validate using any signature algorithm using a


§4.6.1:
>    Note that in principle it is possible to continue issuing new tickets
>    which indefinitely extend the lifetime of the keying material


§4.6.2:
>    CertificateRequest and receiving a response.  In addition, clients
>    which receive multiple CertificateRequests in close succession MAY

§4.6.3:
>    record.  This mechanism allows either side to force an update to the
>    entire connection, but causes an implementation which receives

§5:
>    condition prior to attempting to deprotect the record.  An
>    implementation which receives any other change_cipher_spec value or

>    implementation which receives any other change_cipher_spec value or
>    which receives a protected change_cipher_spec record MUST abort the

§5.5:
>    There are cryptographic limits on the amount of plaintext which can

§6:
>    Note: TLS defines two generic alerts (see Section 6) to use upon
>    failure to parse a message.  Peers which receive a message which

>    length) MUST terminate the connection with a "decode_error" alert.
>    Peers which receive a message which is syntactically correct but

§6.2:
>    bad_record_mac  This alert is returned if a record is received which

§7:
>    The TLS handshake establishes one or more input secrets which are

§8:
>      attempting to retry requests.  However, 0-RTT adds an additional
>      dimension for any server system which does not maintain globally

>    operation, clients will not know which, if any, of these mechanisms
>    servers actually implement and hence MUST only send early data which

§8.2:
>    long as any portion of their recording window overlaps the startup
>    time.  Otherwise, they run the risk of accepting replays which were

§8.3:
>    number of ClientHellos and is a useful optimization for single-use
>    tickets because it allows efficient rejection of ClientHellos which

§9.2:
>    Servers receiving a ClientHello which does not conform to these

§9.3:
>    -  A middlebox which terminates a TLS connection MUST behave as a

>      compliant TLS server (to the original client), including having a
>      certificate which the client is willing to accept, and as a

>      apply to the two connections separately.  Safely deploying a TLS
>      terminator requires additional security considerations which are

>    -  An middlebox which forwards ClientHello parameters it does not

§A:
>    e.g., START) have no formal meaning but are provided for ease of
>    comprehension.  Actions which are taken only in certain circumstances


§C.3:
>    -  As a server, do you send a HelloRetryRequest to clients which

§D:
>    the master secret.  Because TLS 1.3 always hashes in the transcript
>    up to the server CertificateVerify, implementations which support

§E.1:
>    transitively includes the original handshake transcript, because that
>    transcript is digested into the values which produce the Resumption

>    If an exporter is used, then it produces values which are unique and

>    similar security properties.  Note that they do not include the
>    client's certificate; future applications which wish to bind to the

§E.2:
>    Integrity.  An attacker should not be able to craft a new record
>      which is different from an existing record which will be accepted

>    Order protection/non-replayability  An attacker should not be able to
>      cause the receiver to accept a record which it has already

>    sequence number being maintained independently at both sides thus
>    records which are delivered out of order result in AEAD deprotection

>    TLS does not provide security for data which is communicated on a

>    an attacker who learns a traffic secret can compute all future
>    traffic secrets on that connection.  Systems which want such

§E.5:
>    -  Duplication of actions which cause side effects (e.g., purchasing

>    data from being accepted multiple times by any cluster with
>    consistent state; for servers which limit the use of 0-RTT to one

>    window.  Because clients do not know the exact details of server
>    behavior, they MUST NOT send messages in early data which are not

>    behavior, they MUST NOT send messages in early data which are not
>    safe to have replayed and which they would not be willing to retry

§E.5.1:
>    Replays of the ClientHello produce the same early exporter, thus
>    requiring additional care by applications which use these exporters.

[Ballot comment]
Thank you (Editor, Work Group, and all the contributors) for an exceedingly well written document, pragmatic structure, and meaningful appendices (esp Appendix E.5 for 0-RTT).

As a _very_ loose comment that can't really be actioned at this step; I like the various 'handshake' tables however the some of the follow-on paragraphs used to describe packets required a second read to understand. I guess it's a stylistic preference and I'll leave that for the draft editor and RFC Editor to look at in due course (so please don't respond to this particular comment but expect time in the RFC ed process clarifying for the neophyte)

Can some of the subtle text be made a little tighter? (only if your AD believes it worthwhile) For example in section 4.2:

it is written:
"Some cases where a server does not agree to an extension are error
      conditions, and some are simply refusals to support particular
      features.  In general, error alerts should be used for the former
      and a field in the server extension response for the latter."

I think what the WG is trying to say:

"In general, error alerts should be used where a server does not agree to an extension and it is an error condition. When it is a refusal to support a particular feature a field in the server extension response should be used." (all with lack of RFC2119 language)

(..interestingly the bullet following the above is very clear)

Really nice plan to use 0x7f00 as the draft version indicator.

Thank you for dealing with padding as you have. Much appreciated!

[Ballot comment]
I found this document to be clear despite its length and complexity. The Gen-ART reviewer wrote a lengthy review that I encourage the author/WG to look at. Many of his comments relate to stylistic preferences in the text and some of them might have been more actionable earlier in the process (e.g., the suggestion for a minor error code, which I like but wouldn't hold this up over), but they are worth reviewing. For example, I was also confused about the use of "fatal alert" versus "error alert," and I also found the invocation of the SNI check in 4.6.1 to be introduced abruptly.

[Ballot comment]
Thank you for a surprisingly (because of the technical density) readable document - I may use this as an example of a well written but dense document...

Also, thanks to the doc shepherd for a good write-up.

I'm balloting NoObj instead of Yes only because I don't think I have enough background/expertise in the topic.

[Ballot comment]
There has clearly been a lot of work put into this. It's a surprisingly understandable document, given its length and the complexity of the subject. I am balloting yes, but I have a few minor comments and nits. None of these are showstoppers, so please do with them as you will.

*** Substantive Comments:

§4.1.2, first paragraph: " When a client first connects to a server, it is REQUIRED to send the
  ClientHello as its first message. "

Is that intended to prohibit the use of STARTTLS or similar application layer patterns?
(To be clear, this is not an objection, just a clarification request.)

§4.1.2, legacy_compression_methods: "Note that TLS 1.3 servers might receive TLS 1.2 or prior
      ClientHellos which contain other compression methods and MUST
      follow the procedures for the appropriate prior version of TLS."

Is that intended to require TLS 1.3 servers to always be willing and able to negotiate 1.2? §4.2.1
has a similar assertion:

"If this extension is not present, servers which are compliant with
  this specification MUST negotiate TLS 1.2 or prior as specified in
  [RFC5246], even if ClientHello.legacy_version is 0x0304 or later."

But §4.2.3 says:

"Note that TLS 1.2 defines this extension differently.  TLS 1.3
  implementations willing to negotiate TLS 1.2 MUST behave in
  accordance with the requirements of [RFC5246] when negotiating that
  version."

... which seems inconsistent (noting that this paragraph talks about "implementations"
rather than "servers", so perhaps there's a subtle difference?

§4.2.1.1: The section is marked for removal. Do you expect that RFC implementations
will ever need to interop with draft implementations? If so, the information in this section
may continue to be useful for some time.

§D.5: This section has a lot of normative requirements that seem important. I wonder why it has been
relegated to an appendix.


*** Editorial Comments and nits:

§2: "If (EC)DHE key establishment
  is in use, then the ServerHello contains a "key_share" extension with
  the server’s ephemeral Diffie-Hellman share which MUST be in the same
  group as one of the client’s shares. "

missing comma prior to "which".

§4.1.1: "Note that if the PSK can be used without (EC)DHE then non-
  overlap in the "supported_groups" parameters need not be fatal, as it
  is in the non-PSK case discussed in the previous paragraph."

I read "need not be fatal" to mean that it may still be fatal at times. Is that the intent?

§11: The IANA considerations have a number of constructions similar to "SHALL update/has updated".
Is that text expected to collapse to "has updated" at some point?

§E.2.1: [BDFKPPRSZZ16]  : Best citation anchor evar

[Ballot comment]
1) I'm a bit uncertain if obsoleting is the right approach as many other protocols usually do not obsolete older versions. However, I understand that this has been the approach TLS has previously taken and is supported by the way the document is written. Still, I find it especially confusing that also two TLS1.2 extensions are deprecated which are not needed with TLS1.3 anymore but still probably valid to be used with TLS1.2, right?
I would recommend for this version to at least already note in the abstract or very early in the intro that it changes the versioning mechanism itself, and thereby basically declares the TLS handshake as an invariant for all future versions and extensibility is only provided using extensions anymore.

2) Can you provide further explanation (potentially in the draft) why the Pre-Shared Key Exchange Modes are provided in an extra/separate extension?

3) I know previous versions of TLS didn't say that much either, but I find it a bit wired that there are NO requirements for the underlaying transport in this document. Previous version this at least said in the intro that a reliable transport (like TCP) is assumed, but even this minimal information seems to have gotten lost in this document. However, I would usually also expect to seen some minimal text about connection handling, e.g. is it okay to transparently try to reestablish the connection by the underlying transport protocol if it broke for some reason? Or it is okay to use the same TCP connection to first send other data and then start the TLS handshake?

4) Regarding the registration policies: I assume the intend of changing them is to make it easier to specify and use new extensions/mechanism. However, I am wondering why the policies have been changed to "Specification Required" and not "IETF consensus" or RFC Required"?

5) I find it a bit strange that basically the whole working group is listed as contributors. My understanding was that Contributors are people that have contributed a "significant" amount of text, while everybody else who e.g. brought ideas in during mailing list discussion would be acknowledged only.

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

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

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

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

The IANA Services Operator has completed its review of draft-ietf-tls-tls13-24. If any part of this review is inaccurate, please let us know.

The IANA Services Operator has a question about one of the actions requested in the IANA Considerations section of this document.

The IANA Services Operator understands that, upon approval of this document, there are several actions which we must complete.

We understand that some of the actions requested in the IANA Considerations section of this document are dependent upon the approval of and completion of IANA Actions in another document:

ietf-tls-iana-registry-updates

The actions below will be applied, upoin approval of both documents, in coordination with those in ietf-tls-iana-registry-updates.

First, in the TLS Cipher Suite Registry on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

the registration rules for the existing registry will be changed to values with the first byte in the range 0-254 (decimal) are assigned via Specification Required as defined by RFC 8126. Values with the first byte 255 (decimal) are reserved for Private Use as defined by RFC 8126.

IANA Question --> should the reference for this registry be changed from RFC 5246 to [ RFC-to-be ]?

In addition in the TLS Cipher Suite Registry the following suites are to be added to the registry:

+------------------------------+-------------+
| Description | Value |
+------------------------------+-------------+
| TLS_AES_128_GCM_SHA256 | {0x13,0x01} |
| | |
| TLS_AES_256_GCM_SHA384 | {0x13,0x02} |
| | |
| TLS_CHACHA20_POLY1305_SHA256 | {0x13,0x03} |
| | |
| TLS_AES_128_CCM_SHA256 | {0x13,0x04} |
| | |
| TLS_AES_128_CCM_8_SHA256 | {0x13,0x05} |
+------------------------------+-------------+

For each of these new suites, the "DTLS-OK" and "Recommended" columns are both marked as "Yes" for each new cipher suite. This is in coordination with the IANA Actions in [I-D.ietf-tls-iana-registry-updates].

For each of these new suites, the Reference is to be [ RFC-to-be ].

Second, in the TLS ContentType Registry also on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

future values are allocated via Standards Action as defined by RFC 8126. IANA understands that this is not a change to the existing registry.

IANA Question --> should the reference for this registry be changed from RFC 5246 and RFC 7983 to [ RFC-to-be ]?

Third, in the TLS Alert Registry, also on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

future values are allocated via Standards Action as defined by RFC 8126. IANA understands that this is not a change to the existing registry.

IANA Question --> should the reference for this registry be changed from RFC 5246 to [ RFC-to-be ]?

Also, in the TLS Alert Registry, two new registrations are made as follows:

Value: [ TBD-at-Registration ]
Description: missing_extension
DTLS-OK:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: certificate_required
DTLS-OK:
Reference: [ RFC-to-be ]

IANA Question --> What is the value to be used for these new registrations for the field DTLS-OK?

Fourth, in the TLS HandshakeType registry also on the Transport Layer Security (TLS) Parameters registry page located at:

https://www.iana.org/assignments/tls-parameters/

future values are allocated via Standards Action as defined by RFC 8126. IANA understands that this is not a change to the existing registry.

IANA Question --> should the reference for this registry be changed from RFC 5246 to [ RFC-to-be ]?

Also, in the TLS HandshakeType registry, a single registration will be renamed:

Value: 4
Description: NewSessionTicket
DTLS-OK: Y
Reference: [RFC5246]

will become:

Value: 4
Description: new_session_ticket
DTLS-OK: Y
Reference: [ RFC-to-be ]

Also, in the TLS HandshakeType registry, five new registrations will be made as follows:

Value: [ TBD-at-Registration ]
Description: hello_retry_request_RESERVED
DTLS-OK:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: encrypted_extensions
DTLS-OK:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: end_of_early_data
DTLS-OK:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: key_update
DTLS-OK:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Description: message_hash
DTLS-OK:
Reference: [ RFC-to-be ]

IANA Question --> What is the value to be used for these new registrations for the field DTLS-OK?

Fifth, the current draft of this document makes the following request:

"This document also uses the TLS ExtensionType Registry originally created in [RFC4366]. IANA has updated it to reference this document. The registry and its allocation policy is listed below:"

However, the allocation policy seems to be missing from the current draft.

IANA Question --> Is the allocation policy for the TLS ExtensionType Registry changed or modified in any way (it is currently IETF Review as defined in RFC 8126)?

Sixth, in the ExtensionType Values regsitry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

the reference for the registry will be changed to [ RFC-to-be ].

In addition, the following values will be added to the registry:

Value: [ TBD-at-Registration ]
Extension name: key_share
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: pre_shared_key
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: psk_key_exchange_modes
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: early_data
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: cookie
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: supported_versions
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: certificate_authorities
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: oid_filters
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: post_handshake_auth
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

Value: [ TBD-at-Registration ]
Extension name: signature_algorithms_cert
Recommended: Yes
TLS 1.3:
Reference: [ RFC-to-be ]

For each of these new registrations, the "Recommended" column is marked as "Yes" for each new cipher registration. This is in coordination with the IANA Actions in [I-D.ietf-tls-iana-registry-updates].

IANA Question --> Should the same be done for the new TLS 1.3 field?

Seventh, also in the ExtensionType Values regsitry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

We will modify this registry to include a new "TLS 1.3" column which lists the messages in which the extension may appear. This column will initially populated from the following table:

+--------------------------------------------------+-------------+
|Extension | TLS 1.3 |
+--------------------------------------------------+-------------+
| server_name [RFC6066] | CH, EE |
| | |
| max_fragment_length [RFC6066] | CH, EE |
| | |
| status_request [RFC6066] | CH, CR, CT |
| | |
| supported_groups [RFC7919] | CH, EE |
| | |
| signature_algorithms [RFC5246] | CH, CR |
| | |
| use_srtp [RFC5764] | CH, EE |
| | |
| heartbeat [RFC6520] | CH, EE |
| | |
| application_layer_protocol_negotiation [RFC7301] | CH, EE |
| | |
| signed_certificate_timestamp [RFC6962] | CH, CR, CT |
| | |
| client_certificate_type [RFC7250] | CH, EE |
| | |
| server_certificate_type [RFC7250] | CH, EE |
| | |
| padding [RFC7685] | CH |
| | |
| key_share [[this document]] | CH, SH, HRR |
| | |
| pre_shared_key [[this document]] | CH, SH |
| | |
| psk_key_exchange_modes [[this document]] | CH |
| | |
| early_data [[this document]] | CH, EE, NST |
| | |
| cookie [[this document]] | CH, HRR |
| | |
| supported_versions [[this document]] | CH, SH, HRR |
| | |
| certificate_authorities [[this document]] | CH, CR |
| | |
| oid_filters [[this document]] | CR |
| | |
| post_handshake_auth [[this document]] | CH |
| | |
| signature_algorithms_cert [[this document]] | CH, CR |
+--------------------------------------------------+-------------+

Eighth, a new registry is to be created called the TLS Signature Scheme registry.

IANA Question --> Where should this new registry be located? Should it be added to an existing registry page? If not, does it belong in an existing category at http://www.iana.org/protocols?

Values with the first byte in the range 0-253 (decimal) are assigned via Specification Required as defined by RFC 8126. Values with the first byte 254 or 255 (decimal) are reserved for Private Use [RFC8126]. Values with the first byte in the range 0-6 or with the second byte in the range 0-3 that are not currently allocated are reserved for backwards compatibility.

Value Signature Scheme Recommended Reference
-------+-----------------------+---------------------+----------------
0x0000- Unassigned
0x0200
0x0201 rsa_pkcs1_sha1 [ RFC-to-be ]
0x0202 Unassigned
0x0203 ecdsa_sha1 [ RFC-to-be ]
0x0204- Unassigned
0x0400
0x0401 rsa_pkcs1_sha256 [ RFC-to-be ]
0x0402 Unassigned
0x0403 ecdsa_secp256r1_sha256 Yes [ RFC-to-be ]
0x0404- Unassigned
0x0500
0x0501 rsa_pkcs1_sha384 [ RFC-to-be ]
0x0502 Unassigned
0x0503 ecdsa_secp384r1_sha384 Yes [ RFC-to-be ]
0x0504- Unassigned
0x0600
0x0601 rsa_pkcs1_sha512 [ RFC-to-be ]
0x0602 Unassigned
0x0603 ecdsa_secp521r1_sha512 [ RFC-to-be ]
0x0604- Unassigned
0x0803
0x0804 rsa_pss_rsae_sha256 [ RFC-to-be ]
0x0805 rsa_pss_rsae_sha384 [ RFC-to-be ]
0x0806 rsa_pss_rsae_sha512 [ RFC-to-be ]
0x0807 ed25519 Yes [ RFC-to-be ]
0x0808 ed448 [ RFC-to-be ]
0x0809 rsa_pss_pss_sha256 [ RFC-to-be ]
0x080a rsa_pss_pss_sha384 [ RFC-to-be ]
0x080b rsa_pss_pss_sha512 [ RFC-to-be ]
0x080c- Unassigned
0x0803
0xFE00- Private Use
0xFFFF

IANA Question --> The authors request that: "The following values SHALL be marked as "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384, rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519. However, the enum in section 4.2.3 of the current draft does not have entries for:

rsa_pss_sha256
rsa_pss_sha384 and
rsa_pss_sha512

IANA Question --> Is either the enum in section 4.2.3 or the IANA Considerations section incorrect?

IANA Question --> is the signature scheme for value 0x0603 supposed to be:

ecdsa_secp512r1_sha512

and not

ecdsa_secp521r1_sha512

as listed in the enum in section 4.2.3?

The IANA Services Operator understands that these are the only actions required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-03-02):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-tls13@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: UPDATED Last Call:  (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The Transport Layer Security (TLS)
Protocol Version 1.3'
  as Proposed Standard

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
ietf@ietf.org mailing lists by 2018-03-02. 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


  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.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2900/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream)
rfc6962: Certificate Transparency (Experimental - IETF stream)
rfc6979: Deterministic Usage of the Digital Signature Algorithm (DSA)
and Elliptic Curve Digital Signature Algorithm (ECDSA) (informational
- Independent Stream)
rfc7539: ChaCha20 and Poly1305 for IETF Protocols (Informational - IRTF stream)
rfc7748: Elliptic Curves for Security (Informational - IRTF stream)
rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream)
rfc8032: Edwards-Curve Digital Signature Algorithm (EdDSA) (Informational - IRTF stream)

The following Last Call announcement was sent out (ends 2018-03-01):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-tls13@ietf.org, Sean Turner , Kathleen.Moriarty.ietf@gmail.com, tls-chairs@ietf.org, sean@sn3rd.com, tls@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'The Transport Layer Security (TLS)
Protocol Version 1.3'
  as Proposed Standard

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
ietf@ietf.org mailing lists by 2018-03-01. 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


  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.




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

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2900/



The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream)

(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.  The Major web browser vendors and TLS
  libraries vendors have draft implementationsor have
  indicated they will support the protocol in the future.  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 with academic
  community to give them a chance to present their
  findings for TLS.  This has 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.

  note

Personnel

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

  The Document Shepherd is Sean Turner.
  The responsible AD is Kathleen Moriarity.

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

(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.  The Major web browser vendors and TLS
  libraries vendors have draft implementationsor have
  indicated they will support the protocol in the future.  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 with academic
  community to give them a chance to present their
  findings for TLS.  This has 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.

  note

Personnel

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

  The Document Shepherd is Sean Turner.
  The responsible AD is Kathleen Moriarity.

(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, 3447, and 5869 are
  already in the downref registry; RFCs 6962, 6979, 7539, 7748,
  and 8032 are not.  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, and 8032) need to be included
  in the IETF LC and then they need to be added to the downref registry ;)

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

(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.  The Major web browser vendors and TLS
  libraries vendors have draft implementationsor have
  indicated they will support the protocol in the future.  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 with academic
  community to give them a chance to present their
  findings for TLS.  This has resulted in improvements to
  the protocol.

Personnel

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

  The Document Shepherd is Sean Turner.
  The responsible AD is Kathleen Moriarity.

(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, 3447, and 5869 are
  already in the downref registry; RFCs 6962, 6979, 7539, 7748,
  and 8032 are not.  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, and 8032) need to be included
  in the IETF LC and then they need to be added to the downref registry ;)

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

(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.  The Major web browser vendors and TLS
  libraries vendors have draft implementationsor have
  indicated they will support the protocol in the future.  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 with academic
  community to give them a chance to present their
  findings for TLS.  This has resulted in improvements to
  the protocol.

Personnel

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

  The Document Shepherd is Sean Turner.
  The responsible AD is Kathleen Moriarity.

(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, 3447, and 5869 are
  already in the downref registry; RFCs 6962, 6979, 7539, 7748,
  and 8032 are not.  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, and 8032) need to be included
  in the IETF LC and then they need to be added to the downref registry ;)

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

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

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.  The Major web browser vendors and TLS
  libraries vendors have draft implementationsor have
  indicated they will support the protocol in the future.  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 with academic
  community to give them a chance to present their
  findings for TLS.  This has resulted in improvements to
  the protocol.

Personnel

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

  The Document Shepherd is Sean Turner.
  The responsible AD is Kathleen Moriarity.

(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, 3447, and 5869 are
  already in the downref registry; RFCs 6962, 6979, 7539, 7748,
  and 8032 are not.  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, and 8032) need to be included
  in the IETF LC and then they need to be added to the downref registry ;)

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

In order to allow for cryptographic review, we will delay submission of the draft to the IESG until the end of January 2017; there will be an opportunity to address any issues discovered by the cryptographic community prior to submission to the IESG.