On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos <n...@redhat.com> wrote:
> 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 This text looks good to me, but it is is a normative change and we've been through WGLC so I'd like to hear from a few other people that they're OK with it (or have the chairs tell me that silence is consent). David Benjamin? Richard Barnes? Ryan Sleevi? Thanks, -Ekr > > > > > 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
