[TLS] Spencer Dawkins' No Objection on draft-ietf-tls-tls13-26: (with COMMENT)

[Spencer Dawkins <[e-mail]>]

Spencer Dawkins has entered the following ballot position for
draft-ietf-tls-tls13-26: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/



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