On Wed, Mar 7, 2018 at 9:25 PM, Spencer Dawkins < spencerdawkins.i...@gmail.com> wrote:
> 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"? > Thanks, yes. 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)? > Close enough. The basic problem is that people get hung up on "perfect". So, consider the case where you generate a fresh DH key every hour or so, but you reuse it for that period. It's clear you get forward secrecy once that key s deleted but is that "perfect" because you have a window of exposure uring that hour? So, we just decided to use "forward secret" 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? > I don't :) 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? > I don't think it's necessary. In general, you can always abort on a protocol violation like this, but there's no known reason you would *need* to, other than it would create interop problems if (say) A thinks extension #1 matters and B thinks #2 matters, but of course there are lots of possible causes of interop. This is different from cases where there are clear security problems if you don't check some value or something. > 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. > Ah, good. One alert for two conditions: 1. An unexpected record type at the record layer. 2. An unexpected handshake message. I wondered why > > Newer > clients or servers, when communicating with newer peers, SHOULD > negotiate the most preferred common parameters. > > was not a MUST. > Ugh, this is actually not even a normative statement, It's just a statement of what the protocol is supposed to do. Good catch! -Ekr
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls