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

2017-04-22 Thread Eric Rescorla
On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos 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 i

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

2017-04-22 Thread Ilari Liusvaara
On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > wrote: > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > > Do you have any thoughts on what text we should insert here? I admit > > > to being not that

Re: [TLS] draft-rescorla-tls-subcerts-01

2017-04-22 Thread Fossati, Thomas (Nokia - GB/Cambridge, UK)
On 21/04/2017 16:50, "Salz, Rich" wrote: > > Speaking as one of the co-authors of [1]: it is not completely clear to me > > what is the limitation in CT that would prevent it to cope with the > > pervasive use of short-term certificates. Can anyone shed a light on this? > > I believe the concern

Re: [TLS] [Lurk] WG Call for adoption of draft-rescorla-tls-subcerts

2017-04-22 Thread Fossati, Thomas (Nokia - GB/Cambridge, UK)
I've read draft-rescorla-tls-subcerts-01 and have a few comments. It's a well written document and the low-level mechanics look ok. However, I think I have a couple of issues with the overall design. First: it is not self-sufficient. The fact that clients must opt-in implies that servers must h

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

2017-04-22 Thread Kurt Roeckx
On Sat, Apr 22, 2017 at 03:00:17PM +0300, Ilari Liusvaara wrote: > On Sat, Apr 22, 2017 at 07:53:50AM -0400, Eric Rescorla wrote: > > On Fri, Apr 21, 2017 at 10:52 AM, Nikos Mavrogiannopoulos > > wrote: > > > > > On Tue, 2017-04-11 at 13:47 -0700, Eric Rescorla wrote: > > > > > > > Do you have an

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

2017-04-22 Thread Ryan Sleevi
On Sat, Apr 22, 2017 at 5:42 PM, Kurt Roeckx wrote: > > So for OCSP of a subordinate CAs there doesn't seem to be any > requirement for a nextUpdate. > Correct. This is part of the many asynchronicities related to CRLs and OCSP in the BRs (another example: https://cabforum.org/pipermail/public/20