On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > 4.1.1. HelloRetryRequest how many times can it be re-sent by the > > server? I assume only a single one, but it maybe good to make it > > explicit. > > This is forbidden in S 4.1.4. > https://tlswg.github.io/tls13-spec/#hello-retry-request > > If a client receives a second HelloRetryRequest in the same > connection (i.e., where the ClientHello was itself in response to > a > HelloRetryRequest), it MUST abort the handshake with an > “unexpected_message” alert. > > Does this seem sufficient?
I must have missed it. Yes, it seems fine. > > 4.4.2.1. OCSP Status and SCT Extensions > > This is a very nice addition to TLS 1.3. Something that I miss as > an > > implementer is guidelines on how to determine the (time) validity > of an > > OCSP stapled response. Here my point is that OCSP responses have > > several fields optional (e.g., nextUpdate), which make a validation > to > > be hand-wavy. It would be nice to have a profile of OCSP responses > that > > would be recommended for use in TLS, as well or a recommendation of > > what constitutes a "fresh" response for use in TLS. > > Do you have any thoughts on what text we should insert here? I admit > to being not that familiar with the practical matters of OCSP > stapling. My issue with OCSP when used under TLS was how to determine the validity of the response when the nextUpdate field is missing. I've added some text for that introducing an (arbitrary) upper limit at: https://github.com/tlswg/tls13-spec/pull/974 > > 5.1. I miss a maximum number of alerts received per session, or > some > > other alert limiting mechanism (having CVE-2016-8610 in mind). > > All alerts now result in connection termination, so the limit > seems to implicitly be 1. Nice. > > > > 7.5. There is no definition of early_exporter_secret, and it is > unclear > > why it is even mentioned. In short how is this supposed to be used, > and > > why should implementations consider adding an interface to it? > > It is defined in: > https://tlswg.github.io/tls13-spec/#key-schedule > > I added some text to explain why you would want it. Thanks. There is a typo on that description "is define for use" -> "is defined for use". regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
