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

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
<https://ietf.org/standards/ids/checklist/> §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., &#268;ermak, M., Jirsik, T., and P.
>             &#268;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.

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.

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.

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

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!