Re: [TLS] consensus call: changing cTLS and ECH to standards track

I support moving both drafts to standards track. For ECH, there is a definite need to encrypt the SNI and other fields as a complement to using encrypted DNS. We have implemented draft versions, and will implement and use the final certain of ECH + HTTPSSVC. For cTLS, this is a prime

Re: [TLS] Bikeshedding ECHO

ECH is good. Go for it! Tommy > On May 20, 2020, at 11:34 AM, Erik Nygren wrote: > >  > > ECH works for me. (I really don't care between ECH and ETCH and thing both > are fine.) > > Erik > > >> On Wed, May 20, 2020 at 2:20 PM Christopher Wood >> wrote: >> On Tue, May 19, 2020, at

Re: [TLS] Bikeshedding ECHO

ECHO is more fun to say, but I do see how it can be confusing (sounding like some sort of ping) when out of the context of TLS. To that end, I’d have a minor preference for “ETCH”. Thanks, Tommy > On May 7, 2020, at 3:52 PM, Christopher Wood wrote: > > Erik raises some compelling reasons to

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

but potentially run out. Thanks, Tommy > On Feb 2, 2020, at 11:05 AM, Tommy Pauly > wrote: > > > >> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni wrote: >> >> On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: >> >>> If you did ne

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 2, 2020, at 9:53 AM, Viktor Dukhovni wrote: > > On Sun, Feb 02, 2020 at 06:42:56AM -0800, Tommy Pauly wrote: > >> If you did need a sentinel to indicate that you wanted to try to reuse >> a ticket (which you can always try if you want), it would make mo

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Feb 2, 2020, at 3:52 AM, Viktor Dukhovni wrote: > > On Sat, Feb 01, 2020 at 08:05:28PM -0800, Watson Ladd wrote: > >>> Sorry, no idea what that above means. And is it simpler than the >>> proposal under discussion (which got some fine-tuning in early >>> feedback)? >> >> So one

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Jan 31, 2020, at 6:14 PM, Stephen Farrell > wrote: > >  > Hiya, > > I have no particular position about this draft but > am curious about 2 things: > > #1 I don't get why it's not possible for postfix to > determine the best way to manage tickets based on the > destination port to

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hi Nico, As a point on the process, I don't think anyone is proposing rubber-stamping. We are instead only suggesting that a set of work that has consensus does not need to be held up by adding new work that does not have consensus. The outcome of points raised during a WGLC does not need to

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

Hi Viktor, > On Jan 31, 2020, at 5:24 PM, Viktor Dukhovni wrote: > >> On Jan 31, 2020, at 8:15 PM, Rob Sayre wrote: >> >> If the scope of a document can be continually expanded during last call, it >> can be indefinitely postponed. > > I'm not proposing a change of scope. The document

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

First off, thanks for the lively discussion on ticket reuse! I think it's a valid use case and something that should continue to be discussed. However, for the purposes of the WGLC for this draft, draft-ietf-tls-ticketrequests, it may be best to separate the conversation. It seems that the

Re: [TLS] Adoption call for draft-rescorla-tls-ctls

I support adoption of this work. Best, Tommy > On Nov 21, 2019, at 1:36 PM, Sean Turner wrote: > > At IETF 105, ekr presented cTLS (Compact TLS) [0][1][2] to both the TLS WG > and the LAKE BOF, which is now a chartered WG [3]. After some discussions, > the ADs suggested [4] that the TLS WG

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Nov 20, 2019, at 11:48 AM, Viktor Dukhovni wrote: > > On Wed, Nov 20, 2019 at 10:40:20AM +0800, Tommy Pauly wrote: > >>>- 0x01-0xfe => client wants single-use tickets: >>>+ send up to that many tickets on full handshake, >>>

Re: [TLS] WGLC for draft-ietf-tls-ticketrequests

> On Nov 19, 2019, at 5:20 PM, Daniel Migault > wrote: > > Hi, > > Just to followup the discussion. I support Viktor,'s proposal as it provides > the ability to the client to specify what it wants rather than let the server > guess. What I am wondering is whether we are catching all

Re: [TLS] Adopting HTTPSVC for ESNI

I'm also supportive of this change, and in general of using HTTPSSVC for the transmission of ESNI keys, speaking as an implementer at Apple. With regards to the per-version structure, I agree with Steven that the structure of the configuration should be able to change between versions. I think

Re: [TLS] SVCB and HTTPSSVC records: draft-nygren-dnsop-svcb-httpssvc-00

> On Sep 24, 2019, at 7:32 AM, Stephen Farrell > wrote: > > > Hi Erik, > > FWIW, if browsers preferred this to an ESNI RR and > we could forget the ESNI RR then I'd be ok with that. > I'm not clear if they do or not though. Regarding the status of which RR we use, I think the main goal for

Re: [TLS] draft-kinnear-tls-client-net-address comments

The QUIC and TLS drafts were written together, and are quite similar as you note. The intention is to use the TLS extension over TLS/TCP connections, and the QUIC extension for QUIC/UDP. I agree that QUIC as a protocol benefits more from the extension than TLS does, but applications on top of

[TLS] TLS 1.3 in iOS

Hi all, Last week, we shipped the first developer seed of iOS 12.2. Among other features, TLS 1.3 is now enabled by default for the entire system. All users of Network.framework and NSURLSession APIs will now negotiate TLS 1.3. The number of TLS 1.3 capable clients on the Internet should take

Re: [TLS] WG adoption call: draft-wood-tls-ticketrequests

As a co-author, I do support adoption, as this will help optimize client connection racing. Tommy > On Nov 8, 2018, at 8:07 AM, Martin Thomson wrote: > > Adopt it. It's a small, useful feature. > On Wed, Nov 7, 2018 at 2:48 PM Sean Turner wrote: >> >> At TLS@IETF103, there was consensus in

Re: [TLS] [Curdle] New Version Notification for draft-ietf-curdle-pkix-04.txt

I've gone through my review of the draft as well, and I think this version looks good! Thanks, Tommy > On Apr 3, 2017, at 11:25 AM, David Schinazi wrote: > > Thanks for the update! > > I've reviewed -04 and I think the draft is ready to move forward. > > Regards, >