> On Mar 8, 2018, at 08:10, Eric Rescorla <e...@rtfm.com> wrote: > > > > 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.
Fix in https://github.com/tlswg/tls13-spec/pull/1169 > 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 :) It’s at least on the same page so it’s not too hard to scan lower. If we called it hooziewazit it’ll still be after it ;) > 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! I made it a MUST in: https://github.com/tlswg/tls13-spec/pull/1172 spt _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
