Re: [TLS] DNS-based Encrypted SNI

Looks neat. 1) TFO DOS vector: is the idea servers will disable TFO under strain but not be able to disable ESNI? 2) “clients might opt to attempt captive portal detection to see if they are in the presence of a MITM proxy, and if so disable ESNI.” If I’m operating a great firewall, I can use

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

I haven't chimed in on the mailing list on this draft, but I'm one of the people who had discussions with browserfolk in hallways, in the corners of interim meetings for HTTP2, and other such places, in order to see what it would take to get a start on TLSA use by browsers. Due to the floods of tr

Re: [TLS] DNS-based Encrypted SNI

On Tue, Jul 3, 2018 at 11:20 AM, Ben Schwartz < bemasc=40google@dmarc.ietf.org> wrote: > > One concern I've heard many times is that we can't add non-A/ queries > to a browser's critical path because there are middleboxes and buggy > recursives that will just drop them, leading to a DNS ti

Re: [TLS] DNS-based Encrypted SNI

On Mon, 2 Jul 2018, Eric Rescorla wrote: It is strongly recommended not to use TXT records. Why not use a new RRTYPE? Everything these days knows how to serve unknown record types (see RFC 3597). The only possibly exception is provisioning tools of small players, but this

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

On Tue, 3 Jul 2018, Allison Mankin wrote: 2.  Do you support the reserved bytes in the revision for a future pinning mechanism? ​Reserving the bytes without a mechanism is not a good idea, so no.  I think the method for modifications or another approach is something to be worked on in future

Re: [TLS] DNS-based Encrypted SNI

On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters wrote: > On Mon, 2 Jul 2018, Eric Rescorla wrote: > > It is strongly recommended not to use TXT records. Why not use a new >> RRTYPE? Everything these days knows how to serve unknown record >> types >> (see RFC 3597). The only possibl

[TLS] tls - Requested sessions have been scheduled for IETF 102

Dear Sean Turner, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:00 requested) Monday, 16 July 2018, Afternoon Session I 1330-1530 Room Name: Place du Canada size: 300

[TLS] Encrypted SNI

From a discussion on the PATIENT list found here: https://www.ietf.org/mail-archive/web/patient/current/msg00078.html From my personal perspective, we need to be careful with all of these efforts. It feels like the pendulum

Re: [TLS] Encrypted SNI

+1 From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Bret Jordan Sent: Tuesday, July 3, 2018 1:08 PM To: tls@ietf.org Subject: [TLS] Encrypted SNI From a discussion on the PATIENT list found here: https://www.ietf.org/mail-archive/web/patient/current/msg00078.html From my personal perspecti

Re: [TLS] Encrypted SNI

On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote: > From a discussion on the PATIENT list found here: > https://www.ietf.org/mail-archive/web/patient/current/msg00078.html > > > > From my personal perspective, we n

Re: [TLS] DNS-based Encrypted SNI

One of the things we found out with CAA is that this extremely optimistic view of the support for unknown RR types by large hosting providers is not accurate. -Tim > -Original Message- > From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Paul Wouters > Sent: Monday, July 2, 2018 11:53

Re: [TLS] Encrypted SNI

+1 On Tue, Jul 3, 2018 at 12:08 PM Bret Jordan wrote: > From a discussion on the PATIENT list found here: > https://www.ietf.org/mail-archive/web/patient/current/msg00078.html > > > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has

Re: [TLS] Encrypted SNI

On Tue, Jul 3, 2018 at 3:49 PM, Benjamin Kaduk wrote: > On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote: >> From a discussion on the PATIENT list found here: >> https://www.ietf.org/mail-archive/web/patient/current/msg00078.html >>

Re: [TLS] Encrypted SNI

So-called "Enterprise" infrastructure has delayed the work of this group for at least a year. Noone of the people creating that mess has reached out to this group to explain why they constantly break TLS - let alone apologize for it. I believe there's a large overlap of the actors breaking TLS wit

Re: [TLS] Encrypted SNI

On Tue, Jul 3, 2018 at 10:08 AM, Bret Jordan wrote: > From a discussion on the PATIENT list found here: https://www.ietf.org/mai > l-archive/web/patient/current/msg00078.html > > > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has swun

Re: [TLS] Encrypted SNI

Hanno Böck writes: > So-called "Enterprise" infrastructure has delayed the work of this group > for at least a year. Noone of the people creating that mess has reached > out to this group to explain why they constantly break TLS - let alone > apologize for it. > > I believe there's a large overla

Re: [TLS] DNS-based Encrypted SNI

On Tue, Jul 3, 2018 at 7:26 AM, Sniffen, Brian wrote: > Looks neat. > > 1) TFO DOS vector: is the idea servers will disable TFO under strain but > not be able to disable ESNI? > I hadn't thought about it, but that seems right. I'm not really seeing why this is a DOS vector? At present, if you're

Re: [TLS] DNS-based Encrypted SNI

2018-07-04 0:55 GMT+09:00 Eric Rescorla : > > > On Tue, Jul 3, 2018 at 8:40 AM, Paul Wouters wrote: >> >> On Mon, 2 Jul 2018, Eric Rescorla wrote: >> >>> It is strongly recommended not to use TXT records. Why not use a >>> new >>> RRTYPE? Everything these days knows how to serve unknow

Re: [TLS] draft-ietf-tls-dnssec-chain-extensions security considerations

On Tue, Jul 03, 2018 at 10:41:18AM -0400, Allison Mankin wrote: > I haven't chimed in on the mailing list on this draft, but I'm one of the > people who had discussions with browserfolk in hallways, in the corners of > interim meetings for HTTP2, and other such places, in order to see what it > wo

Re: [TLS] Encrypted SNI

On Tue, 3 Jul 2018, Eric Rescorla wrote: but in this particular case, can't enterprise just strip ESNI records from DNS? Not if endnodes within the enterprise also use DNSSEC. Unless you want the enterprise to run authoritative fake DNSSEC for the entire world. It also requires installing int

Re: [TLS] Encrypted SNI

>So-called "Enterprise" infrastructure has delayed the work of this group >for at least a year. Noone of the people creating that mess has reached >out to this group to explain why they constantly break TLS - let alone >apologize for it. >I believe there's a large overlap of the actors breaking T

Re: [TLS] DNS-based Encrypted SNI

On Tue, Jul 03, 2018 at 07:50:00PM +, Tim Hollebeek wrote: > One of the things we found out with CAA is that this extremely optimistic view > of the support for unknown RR types by large hosting providers is not > accurate. As context, problems with CAA were not limited to various DNS hosters

Re: [TLS] DNS-based Encrypted SNI

On Mon, Jul 02, 2018 at 04:39:14PM -0700, Eric Rescorla wrote: > > I just submitted: > > https://tools.ietf.org/html/draft-rescorla-tls-esni-00 > > This draft describes a DNS-based approach to doing encrypted SNI. > > Previously, we had thought this wouldn't work because only sites that > wer

[TLS] Seeking reviews for draft-ietf-mmusic-sdp-uks

TLS People, The use of DTLS for real-time media doesn't get a whole lot of attention here, but there's some work in MMUSIC on fixing a problem with the interaction between an external signaling protocol and (D)TLS. This came out of some of the 1.3 analysis we were doing a while back. It's not a

[TLS] Broken browser behaviour with SCADA TLS

The following is an attempt to condense some off-list discussions with SCADA folks about the broken behaviour of some browsers when it comes to interaction with SCADA devices running TLS. tl;dr: Chrome is practically unusable, at the other end of the scale Firefox is fine, and there's something we