Re: [TLS] comments on draft-ietf-tls-tls13-19

[Eric Rescorla <[e-mail]>]

On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos <[e-mail]>
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
>
>