Re: [TLS] Encrypted SNI

On Tue, Jul 3, 2018 at 10:08 AM Bret Jordan wrote: > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has swung so far to one side, the side > of privacy-at-any-cost, that we are unknowingly increasing the risk to > individuals and organi

Re: [TLS] Encrypted SNI

On Tue, Jul 3, 2018 at 5:19 PM Brian Sniffen wrote: > 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

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] 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

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] 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

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 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

+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 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] 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

[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 hangout

I already have a conflict for this, so I will not be attending. -Ekr On Mon, Nov 13, 2017 at 3:57 AM, Darin Pettis wrote: > Sean - thank you for the update and options on rooms. > > Ben and Brett - which room should we meet in? > > Initially opposed to encrypting SNI as it appears to break man

Re: [TLS] Encrypted SNI hangout

Sean - thank you for the update and options on rooms. Ben and Brett - which room should we meet in? Initially opposed to encrypting SNI as it appears to break many services that utilize it but curious to hear more. Thx On Mon, Nov 13, 2017 at 9:17 AM Christian Huitema wrote: > On 11/12/2017

Re: [TLS] Encrypted SNI hangout

On 11/12/2017 4:54 PM, Sean Turner wrote: > Hi! I applaud the initiative for suggesting the hangout [0]. Squatting in > that room ought to be okay but in case the secretariat ends up scheduling > another IETF session in that room the 12 person room (Butterworth) is still > available during th

Re: [TLS] Encrypted SNI hangout

Hi! I applaud the initiative for suggesting the hangout [0]. Squatting in that room ought to be okay but in case the secretariat ends up scheduling another IETF session in that room the 12 person room (Butterworth) is still available during that time: https://www.ietf.org/registration/MeetingW

[TLS] Encrypted SNI hangout

All, Since the TLS session on Monday got canceled what would people think about using that time to talk about encrypted SNI? Bret Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050___ TLS mailing list T

Re: [TLS] Encrypted SNI

On Wed, Jun 7, 2017 at 4:53 AM, Toerless Eckert wrote: > > Thanks. Just in case anyone is counting > I think thats a bad choice that limits the usefulness of 1.3. And it will > just > cause less security in systems where logging etc. is required than if this > was possible by apps to configure. >

Re: [TLS] Encrypted SNI

Thanks. Just in case anyone is counting I think thats a bad choice that limits the usefulness of 1.3. And it will just cause less security in systems where logging etc. is required than if this was possible by apps to configure. Why can i negotiate a cipher suite without encryption but not disabl

Re: [TLS] Encrypted SNI

Correct; certs are never in the clear. There is no scenario where anything will be unencrypted after the hellos in TLS 1.3+. If you're doing anything with an old system that relies on this, the general advice is to upgrade your old system to not do that anymore. If you're logging traffic from so

Re: [TLS] Encrypted SNI

So no options in TLS 1.3 that make it possible to see the server cert in the clear ? On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote: > On 06/02/2017 08:28 AM, Toerless Eckert wrote: > > Another candidate use case coming to mind eg: auditing tht is required in > > many eg: financi

Re: [TLS] Encrypted SNI

On 06/02/2017 08:28 AM, Toerless Eckert wrote: > Another candidate use case coming to mind eg: auditing tht is required in > many eg: financial > environments. In the past i have seen even the requirement for the whole data > streams to be unencrypted > for auditing. Maybe that market segment wou

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 03:28:33PM +0200, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > > If a web service hoster does not provide any useful demultiplexer then it > > > can of course not > > > expect not to get blacklisted across services. Is it not alre

Re: [TLS] Encrypted SNI

On Fri, Jun 2, 2017 at 6:28 AM, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > > If a web service hoster does not provide any useful demultiplexer then > it > > > can of course not > > > expect not to get blacklisted across services. Is it not already co

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > If a web service hoster does not provide any useful demultiplexer then it > > can of course not > > expect not to get blacklisted across services. Is it not already common > > practice to assign > > separate certificates to separate "

Re: [TLS] Encrypted SNI

On Fri, Jun 2, 2017 at 6:31 AM, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote: > > Operators trying to do this by inspecting TLS (and not decrypting) are > > going to have a bad time anyway. With HTTP/2 connection coalescing, even > > if they can see the

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote: > Operators trying to do this by inspecting TLS (and not decrypting) are > going to have a bad time anyway. With HTTP/2 connection coalescing, even > if they can see the certificate, the actual HTTP request could be for any > name in

Re: [TLS] Encrypted SNI

On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert wrote: > Thanks, Benoit > > [hope it's ok. to cross-port and redirect replies to TLS] > > I have not followed TLS 1.3 in detail, so a quick question first: > > Will TLS 1.3 still permit servers to send their certificate and/or SNI in > the clear as

Re: [TLS] Encrypted SNI

On Fri, Jun 02, 2017 at 10:43:00AM +0200, Toerless Eckert wrote: > Thanks, Benoit > > [hope it's ok. to cross-port and redirect replies to TLS] > > I have not followed TLS 1.3 in detail, so a quick question first: > > Will TLS 1.3 still permit servers to send their certificate and/or SNI in the

Re: [TLS] Encrypted SNI

Thanks, Benoit [hope it's ok. to cross-port and redirect replies to TLS] I have not followed TLS 1.3 in detail, so a quick question first: Will TLS 1.3 still permit servers to send their certificate and/or SNI in the clear as an option or will it force server operators to encrypt either/or ? If

Re: [TLS] "Encrypted" SNI

On Thu, May 11, 2017 at 08:01:58PM +0200, Hubert Kario wrote: > > But beware of: > > > > - the adversary can replay this SNI and see what site he gets > > - DDoS risk: servers can't be try lots of crypto (no asymmetric ops, > > no operations that scale linearly with number of sites hosted

Re: [TLS] "Encrypted" SNI

On Thursday, 11 May 2017 16:31:26 CEST Brian Sniffen wrote: > Daniel Kahn Gillmor writes: > > On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote: > >> It certainly was. But then the clear text SNI is a gaping privacy hole > >> in TLS, the kind of issue that should keep us awake at night unt

Re: [TLS] "Encrypted" SNI

On Thu 2017-05-11 00:03:15 +0200, Roland Zink wrote: > Not necessarily as you may for example use the path part of a URL to > distinguish between services. if we're talking about HTTPS, this approach raises a series of potential security issues thanks to the same-origin policy and other host- or

Re: [TLS] "Encrypted" SNI

Daniel Kahn Gillmor writes: > On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote: >> It certainly was. But then the clear text SNI is a gaping privacy hole >> in TLS, the kind of issue that should keep us awake at night until it is >> resolved. We need to make sure that we make progress, r

Re: [TLS] "Encrypted" SNI

On Wednesday, 10 May 2017 21:04:53 CEST Viktor Dukhovni wrote: > > On May 10, 2017, at 2:47 PM, Hubert Kario wrote: > > > > But in general, I wonder if we didn't approach the SNI from the wrong side > > - as I said, we may not need to encrypt it, we just make sure that client > > and server agree

Re: [TLS] "Encrypted" SNI

On Wednesday, 10 May 2017 21:28:48 CEST Ilari Liusvaara wrote: > On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote: > > Yes, encrypted SNI was discussed and ultimately rejected. > > > > But do we really have to send the literal value? Don't we need to just > > make > > sure that the cli

Re: [TLS] "Encrypted" SNI

On Wed 2017-05-10 12:12:34 -0700, Christian Huitema wrote: > It certainly was. But then the clear text SNI is a gaping privacy hole > in TLS, the kind of issue that should keep us awake at night until it is > resolved. We need to make sure that we make progress, rather than rehash > the old argumen

Re: [TLS] "Encrypted" SNI

Not necessarily as you may for example use the path part of a URL to distinguish between services. Roland Am 10.05.2017 um 23:50 schrieb Christian Huitema: On 5/10/2017 2:40 PM, Roland Zink wrote: The SNI extension is optional, so you don't have to send the literal value. Indeed quite so

Re: [TLS] "Encrypted" SNI

On 5/10/2017 2:40 PM, Roland Zink wrote: > The SNI extension is optional, so you don't have to send the literal > value. Indeed quite some number of apps do not send it. Browsers > currently can't know if the SNI is required by the origin servers and > usually send this, but there could be some s

Re: [TLS] "Encrypted" SNI

The SNI extension is optional, so you don't have to send the literal value. Indeed quite some number of apps do not send it. Browsers currently can't know if the SNI is required by the origin servers and usually send this, but there could be some signal to not send it. One example could be a HT

Re: [TLS] "Encrypted" SNI

On Wed, May 10, 2017 at 07:28:51PM +0200, Hubert Kario wrote: > Yes, encrypted SNI was discussed and ultimately rejected. > > But do we really have to send the literal value? Don't we need to just make > sure that the client and server agree on the host that the client wants to > connect? > > C

Re: [TLS] "Encrypted" SNI

On 05/10/2017 02:12 PM, Christian Huitema wrote: > > On 5/10/2017 12:04 PM, Viktor Dukhovni wrote: >>> On May 10, 2017, at 2:47 PM, Hubert Kario wrote: >>> >>> But in general, I wonder if we didn't approach the SNI from the wrong side >>> - >>> as I said, we may not need to encrypt it, we just m

Re: [TLS] "Encrypted" SNI

On 5/10/2017 12:04 PM, Viktor Dukhovni wrote: >> On May 10, 2017, at 2:47 PM, Hubert Kario wrote: >> >> But in general, I wonder if we didn't approach the SNI from the wrong side - >> as I said, we may not need to encrypt it, we just make sure that client and >> server agree on the virtual hos

Re: [TLS] "Encrypted" SNI

> Encryption means key agreement, and requires delaying SNI by a round-trip, > or having published DH shares in DNS, which of course also needs privacy > protection for SNI encryption to matter. With TLS1.3 encryptedExtensions, secure "domain fronting" becomes possible. A am long overdue for a

Re: [TLS] "Encrypted" SNI

> On May 10, 2017, at 2:47 PM, Hubert Kario wrote: > > But in general, I wonder if we didn't approach the SNI from the wrong side - > as I said, we may not need to encrypt it, we just make sure that client and > server agree on the virtual host the connection is going to. They can do that wit

Re: [TLS] "Encrypted" SNI

On Wednesday, 10 May 2017 20:25:22 CEST Viktor Dukhovni wrote: > > On May 10, 2017, at 1:28 PM, Hubert Kario wrote: > > > > Couldn't we "encrypt" the SNI by hashing the host name with a salt, > > sending > > the salt and the resulting hash, making the server calculate the same hash > > with each

Re: [TLS] "Encrypted" SNI

> On May 10, 2017, at 1:28 PM, Hubert Kario wrote: > > Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending > the salt and the resulting hash, making the server calculate the same hash > with each of the virtual host names it supports and comparing with the client > pro

[TLS] "Encrypted" SNI

Yes, encrypted SNI was discussed and ultimately rejected. But do we really have to send the literal value? Don't we need to just make sure that the client and server agree on the host that the client wants to connect? Couldn't we "encrypt" the SNI by hashing the host name with a salt, sending

Re: [TLS] Encrypted SNI

On Sun, Dec 6, 2015 at 6:46 AM, Salz, Rich wrote: > > I'm not sure I understand the design you're suggesting. > > Does the EncryptedExtensions contain the entire hello for the "next hop"? > No. It (at most) says "the stuff that is post-handshake is actually a ClientHello for the next hop". I.e.,

Re: [TLS] Encrypted SNI

> I'm not sure I understand the design you're suggesting. Does the EncryptedExtensions contain the entire hello for the "next hop"? ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Encrypted SNI

On 12/6/15, Dave Garrett wrote: > On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote: >> Can we embed an EncryptedExtension inside an existing EE? That would let >> us do TOR purely within TLS, right? > > If clients are allowed to send any encrypted extensions other than the > tunneling

Re: [TLS] Encrypted SNI

On Saturday, December 05, 2015 08:58:58 pm Salz, Rich wrote: > Can we embed an EncryptedExtension inside an existing EE? That would let us > do TOR purely within TLS, right? If clients are allowed to send any encrypted extensions other than the tunneling extension (that contains the tunneled he

Re: [TLS] Encrypted SNI

On Sat, Dec 5, 2015 at 8:20 PM, Tom Ritter wrote: > On 5 December 2015 at 21:31, Eric Rescorla wrote: > > > > > > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote: > >> > >> On 5 December 2015 at 12:32, Eric Rescorla wrote: > >> > Subject: SNI Encryption Part XLVIII > >> > >> A small concern t

Re: [TLS] Encrypted SNI

On 5 December 2015 at 21:31, Eric Rescorla wrote: > > > On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote: >> >> On 5 December 2015 at 12:32, Eric Rescorla wrote: >> > Subject: SNI Encryption Part XLVIII >> >> A small concern that probably is "No, that can't happen", but I would >> want to be sur

Re: [TLS] Encrypted SNI

On Sat, Dec 5, 2015 at 5:58 PM, Salz, Rich wrote: > Can we embed an EncryptedExtension inside an existing EE? > I'm not sure I understand the design you're suggesting. > That would let us do TOR purely within TLS, right? > See above. > > You said “in the interest of explicit signaling”

Re: [TLS] Encrypted SNI

On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote: > On 5 December 2015 at 12:32, Eric Rescorla wrote: > > Subject: SNI Encryption Part XLVIII > > A small concern that probably is "No, that can't happen", but I would > want to be sure that a normal (non-encrypted SNI) ClientHello would be > unabl

Re: [TLS] Encrypted SNI

On 5 December 2015 at 12:32, Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII A small concern that probably is "No, that can't happen", but I would want to be sure that a normal (non-encrypted SNI) ClientHello would be unable to be wrapped in a new ClientHello to a gateway by a MITM (wi

Re: [TLS] Encrypted SNI

Can we embed an EncryptedExtension inside an existing EE? That would let us do TOR purely within TLS, right? You said “in the interest of explicit signaling” but I think you meant in the interest of avoiding that, right? I still think the “inner/real SNI” is simpler, but will have to think abo

Re: [TLS] Encrypted SNI

On Saturday, December 05, 2015 01:32:11 pm Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension th

Re: [TLS] Encrypted SNI

On Sat, Dec 05, 2015 at 02:15:07PM -0500, Watson Ladd wrote: > I've got another question: how does the client know that the gateway > is supposed to be the gateway? As it stands it seems an attacker can > MITM the Gateway, and recover all SNIs. That's a whole lot different than passively reading

Re: [TLS] Encrypted SNI

On Sat, Dec 5, 2015 at 1:32 PM, Eric Rescorla wrote: > Subject: SNI Encryption Part XLVIII > > Folks, > > TL;DR. > This message describes a technique for doing SNI encryption that just > requires (re)adding EncryptedExtensions to the client's first flight [0] > defining an extension that indicates

[TLS] Encrypted SNI

Subject: SNI Encryption Part XLVIII Folks, TL;DR. This message describes a technique for doing SNI encryption that just requires (re)adding EncryptedExtensions to the client's first flight [0] defining an extension that indicates "tunnelled TLS" and (maybe) a new TLS content type. We would only t

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

How about making fixed length(s) for each message type, then pad it with 0x01 then optional 0x00s? Quynh. From: TLS on behalf of Dave Garrett Sent: Friday, September 25, 2015 2:11 PM To: tls@ietf.org; m...@sap.com Subject: Re: [TLS] Encrypted SNI

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Friday, September 25, 2015 01:10:37 pm Martin Rex wrote: > Because it is not necessarily immediately obvious, you will need > padding also for the Server Certificate handshake messages. > And, because the key exchange is side-effected by properties of > the Server Certificate, you may additional

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Various paddings (is that a word?) will be needed, but the ability to pad things is also in TLS 1.3. We think all the necessary TLS protocol bits are present. -- Senior Architect, Akamai Technologies IM: richs...@jabber.at Twitter: RichSalz ___ T

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Martin Rex wrote: > Salz, Rich wrote: > > > > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started > > a proposal that makes SNI-encryption something that can be deployed and > > tested on the Internet in TLS 1.3. So we'll see if it gets used and works. > > The earlier slides

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Salz, Rich wrote: > > At the TLS interim earlier this week, Brian Sniffen (from Akamai) started > a proposal that makes SNI-encryption something that can be deployed and > tested on the Internet in TLS 1.3. So we'll see if it gets used and works. > The earlier slides notwithstanding, it's somethi

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

Thanks for your detailed and thoughtful review. It's all trade-offs. In previous emails on this thread I acknowledged the co-dependant issue, by calling out dkg's excellement statement of it. At the TLS interim earlier this week, Brian Sniffen (from Akamai) started a proposal that makes SNI-en

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Tue, Sep 22, 2015 at 2:37 PM, Salz, Rich wrote: > We discussed this before. Not that we can't discuss it again. Here's a link > to slides I presented at the Toronto Interim in July 2015. > > > https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing > Thanks f

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

We discussed this before. Not that we can't discuss it again. Here's a link to slides I presented at the Toronto Interim in July 2015. https://drive.google.com/file/d/0B8YgrWYHqacSV2hnZmR3VjJtRUk/view?usp=sharing ___ TLS mailing list TLS@iet

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Tue, Sep 22, 2015 at 1:39 PM, Jacob Appelbaum wrote: > On 9/21/15, Daniel Kahn Gillmor wrote: >> On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni >> wrote: >>> So the client would now need to cache some session data by transport >>> address, and other data by name and port. That's rather co

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On 9/21/15, Daniel Kahn Gillmor wrote: > On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni > wrote: >> So the client would now need to cache some session data by transport >> address, and other data by name and port. That's rather complex. > > This is already done by HTTP/2 clients, since they c

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Fri 2015-08-28 09:22:52 -0700, Viktor Dukhovni wrote: > So the client would now need to cache some session data by transport > address, and other data by name and port. That's rather complex. This is already done by HTTP/2 clients, since they can access multiple servers at the same address:p

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

> How's it done with IPv6, generally? We don't see address-sharing with IPv6, although I wonder if that will change when the routing tables get too big. :) We also don't see anyone willing to go IPv6-only; it's not close to universal enough yet. > I agree that it's a lot of effort for relative

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Friday, August 28, 2015 12:33:31 pm Salz, Rich wrote: > > And how often will the same client visit multiple servers at the same > > transport address? > > Anyone who visits sites hosted by a CDN. And, I suspect, many large portals. How's it done with IPv6, generally? Are there setups where ev

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

> > The idea I had the other day is that we can technically do SNI > > encryption with the current TLS 1.3 draft, as-is. Yeah, some of us talked about this in Dallas, etc., when the "semi-static EDH key" really started to take hold. I showed slides at the interim before IETF 90 in Toronto, that

Re: [TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Fri, Aug 28, 2015 at 12:13:03PM -0400, Dave Garrett wrote: > The idea I had the other day is that we can technically do SNI encryption > with the current TLS 1.3 draft, as-is. All that needs to really be done > is stick it in a 0-RTT EncryptedExtensions, preferably only when the server > specif

[TLS] Encrypted SNI (was: Privacy considerations - identity hiding from eavesdropping in (D)TLS)

On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote: > Having discussions through github is a really bad idea. You're right. I posted a stupidly long side-note in there. I intended to bring it to the list too, which I'll do now. On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote: >