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. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
