[TLS] I-D Action: draft-ietf-tls-dtls-connection-id-07.txt

2019-10-21 Thread internet-drafts
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security WG of the IETF. Title : Connection Identifiers for DTLS 1.2 Authors : Eric Rescorla Hannes

Re: [TLS] I-D Action: draft-ietf-tls-ticketrequests-03.txt

2019-10-21 Thread Hubert Kario
On Saturday, 19 October 2019 03:38:02 CEST internet-dra...@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. This draft is a work item of the Transport Layer Security WG > of the IETF. > > Title : TLS Ticket Requests >

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Sun, Oct 20, 2019 at 2:41 PM Rob Sayre wrote: > Hi, > > I was implementing https://tools.ietf.org/html/draft-ietf-tls-esni-02 > (since I believe that version is what Firefox and Cloudflare currently > ship), and I had a difficult time parsing this part of the draft: > > struct { >

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

2019-10-21 Thread Hubert Kario
On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > which can be found here: > >https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > > It will run until November 1, 2019. Please indicate whether

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote: > Judging by the mailing list archives, the design of the field is >>> intentional. It's not clear to me why "zeros" wasn't specified as >>> variable-length with a prose restriction, though. >>> >> >> Because then you have a spurious length

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

2019-10-21 Thread Richard Barnes
On Mon, Oct 21, 2019 at 11:44 AM David Benjamin wrote: > On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > >> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: >> > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, >> > which can be found here: >> > >> >

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

2019-10-21 Thread David Benjamin
On Mon, Oct 21, 2019 at 12:11 PM Richard Barnes wrote: > On Mon, Oct 21, 2019 at 11:44 AM David Benjamin > wrote: > >> On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: >> >>> On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: >>> > This email starts a call for adoption of

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: > On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla wrote: > >> >> >> On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote: >> >> >> >>> Judging by the mailing list archives, the design of the field is > intentional. It's not clear to me why "zeros"

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

2019-10-21 Thread David Benjamin
On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > > which can be found here: > > > >https://tools.ietf.org/html/draft-davidben-tls13-pkcs1-00 > >

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

2019-10-21 Thread Hubert Kario
On Monday, 21 October 2019 17:43:52 CEST David Benjamin wrote: > On Mon, Oct 21, 2019 at 9:42 AM Hubert Kario wrote: > > On Friday, 18 October 2019 20:44:03 CEST Christopher Wood wrote: > > > This email starts a call for adoption of draft-davidben-tls13-pkcs1-00, > > > > > > which can be found

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 6:06 AM Eric Rescorla wrote: > >> >> I hadn't seen the fixed-but-variable length construction that the "zeros" >> field uses before (although I haven't written much TLS code). >> > > It is used in other places. See, for instance: >

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 7:41 AM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 7:32 AM Rob Sayre wrote: > > > >> Judging by the mailing list archives, the design of the field is intentional. It's not clear to me why "zeros" wasn't specified as variable-length with a prose

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 1:09 PM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 1:07 PM Rob Sayre wrote: > >> On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla wrote: >> >>> On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell < >>> stephen.farr...@cs.tcd.ie> wrote: >>> Not yet,

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Stephen Farrell
Hiya, On 21/10/2019 21:02, Eric Rescorla wrote: >> Sure, but the point holds though. If ESNIKeys are changed every >> N seconds, and any new certificate is loaded during that time, >> then the server operator can't tell the lengths that the CAs >> might produce in future. So with the current

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Stephen Farrell
Hiya, On 21/10/2019 20:01, Rob Sayre wrote: > On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell > wrote: > >> My guess is that all of the above will lead to everyone >> always using 260 for this value, making it pointless >> and somewhat wasteful. >> > > Whether it's wasteful depends on how

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Stephen Farrell
On 21/10/2019 20:14, Rob Sayre wrote: > I have seen MTUs under 1500 many times, but nothing under 1200. Is there > data on this? (I honestly haven't seen any) My assumption is that maybe 90% of names are <60 octets. That means padding_length of 260 is wasting roughly 200 octets, almost all the

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 19:08, Eric Rescorla wrote: > > No. You want padding to be set to be the longest size that you would send > > to any origin in the anonymity group, and the server knows this. > > In the past, I've argued that

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Stephen Farrell
Hiya, On 21/10/2019 20:29, Eric Rescorla wrote: > The question is not the server, but the operator. Sure, but the point holds though. If ESNIKeys are changed every N seconds, and any new certificate is loaded during that time, then the server operator can't tell the lengths that the CAs might

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Mon, Oct 21, 2019 at 1:07 PM Rob Sayre wrote: > On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla wrote: > >> On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell < >> stephen.farr...@cs.tcd.ie> wrote: >> >>> >>> >>> Not yet, that's true. OTOH, the 260 value wasn't decided on >>> the list either

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 21:02, Eric Rescorla wrote: > >> Sure, but the point holds though. If ESNIKeys are changed every > >> N seconds, and any new certificate is loaded during that time, > >> then the server operator can't tell the

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 12:10 PM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 20:01, Rob Sayre wrote: > > On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell < > stephen.farr...@cs.tcd.ie> > > wrote: > > > >> My guess is that all of the above will lead to everyone > >> always using 260 for

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell wrote: > > Hiya, > > On 21/10/2019 20:29, Eric Rescorla wrote: > > > The question is not the server, but the operator. > > Sure, but the point holds though. If ESNIKeys are changed every > N seconds, and any new certificate is loaded during that

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 1:03 PM Eric Rescorla wrote: > On Mon, Oct 21, 2019 at 12:48 PM Stephen Farrell < > stephen.farr...@cs.tcd.ie> wrote: > >> >> >> Not yet, that's true. OTOH, the 260 value wasn't decided on >> the list either that I recall. > > > IIRC it was there at the time of adoption.

Re: [TLS] Adoption call for draft-davidben-tls13-pkcs1

2019-10-21 Thread Sean Turner
> On Oct 21, 2019, at 12:19, David Benjamin wrote: > > (What's the usual order of operations here? It seems weird to change a > document mid-adoption-call, and, if the document is adopted, it also seems > weird to make the first TLSWG revision different from the document from the > adoption

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: > >> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you >> just mean it would be superfluous. >> > > Yes, that is what I mean. > OK. To be clear, I understand why

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 11:41 AM Stephen Farrell wrote: > My guess is that all of the above will lead to everyone > always using 260 for this value, making it pointless > and somewhat wasteful. > Whether it's wasteful depends on how big typical ClientHello (without early data) messages are. If

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 11:09 AM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre wrote: > >> On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla wrote: >> >>> >>> >>> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: >>> Sorry if I'm being dense here. Couldn't "zeros" have

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Eric Rescorla
On Mon, Oct 21, 2019 at 10:55 AM Rob Sayre wrote: > On Mon, Oct 21, 2019 at 9:45 AM Eric Rescorla wrote: > >> >> >> On Mon, Oct 21, 2019 at 7:56 AM Rob Sayre wrote: >> >>> Sorry if I'm being dense here. Couldn't "zeros" have a length? Maybe you >>> just mean it would be superfluous. >>> >> >>

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Christian Huitema
On 10/21/2019 11:08 AM, Eric Rescorla wrote: > > 3) Why is the length of "zeros" implicit rather than explicit? Is > it to save a few bytes, or is there a deeper reason? > > > It saves bytes on the wire. It's also the way we've done other zero > padding. There also off-by-one or

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Stephen Farrell
Hiya, On 21/10/2019 19:08, Eric Rescorla wrote: > No. You want padding to be set to be the longest size that you would send > to any origin in the anonymity group, and the server knows this. In the past, I've argued that this is not necessarily true and hence the current padding scheme is not a

Re: [TLS] Delegated Credentials Question about PSS

2019-10-21 Thread Martin Thomson
On Thu, Oct 17, 2019, at 14:32, Watson Ladd wrote: > In TLS 1.3 it seems to have been assumed this wouldn't happen and we > could split signature algorithms from signature algorithms cert. > > If that's not actually the case it affects more than just DCs. DCs are > a good way to restore

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Patrick McManus
wildcards are real in both dns and http services.. (also the dns entries might be invisible to the http provider thanks to cname indirections.. though obviously service names are not.) On Mon, Oct 21, 2019 at 4:56 PM Eric Rescorla wrote: > > > On Mon, Oct 21, 2019 at 1:46 PM Stephen Farrell >

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Rob Sayre
On Mon, Oct 21, 2019 at 4:59 PM Patrick McManus wrote: > wildcards are real in both dns and http services.. (also the dns entries > might be invisible to the http provider thanks to cname indirections.. > though obviously service names are not.) > That all seems right. I was wondering where the

Re: [TLS] draft-ietf-tls-esni feedback

2019-10-21 Thread Ben Schwartz
On Mon, Oct 21, 2019 at 3:24 PM Stephen Farrell wrote: > > > > On 21/10/2019 20:14, Rob Sayre wrote: > > I have seen MTUs under 1500 many times, but nothing under 1200. Is there > > data on this? (I honestly haven't seen any) > > My assumption is that maybe 90% of names are <60 octets. > That