On Friday, March 10, 2017 10:29:30 am Viktor Dukhovni wrote:
> Instead of looking for a kludgey replacement SNI in DNS (that won't get
> deployed,
> and provides rather weak obfuscation) it seems more sensible to publish keys
> in
> DNS that make it possible to encrypt the entire client HELLO,
> On Feb 7, 2017, at 11:12 AM, Ben Schwartz wrote:
>
> Like a lot of people here, I'm very interested in ways to reduce the leakage
> of users' destinations in the ClientHello's cleartext SNI. It seems like the
> past and current proposals to fix the leak are pretty
On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote:
> Hi TLS,
>
> Like a lot of people here, I'm very interested in ways to reduce the
> leakage of users' destinations in the ClientHello's cleartext SNI. It
> seems like the past and current proposals to fix the leak are pretty
>
On Fri, Mar 10, 2017 at 7:33 AM Martin Rex wrote:
> CABrowser-Forum defines the rules which browsers implemenent on
> top of rfc2818 section 3.1 server endpoint identity checks
> of server certificates.
This is neither accurate nor correct. The CA/Browser Forum neither
describes
Ilari Liusvaara wrote:
> On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote:
>>
>> You don't understand the purpose of SNI and how the (already weak)
>> rfc2818 section 3.1 server endpoint identification and CABrowser Forum
>> public CA Domain validation has been designed to work.
>
>
On Fri, Mar 10, 2017 at 09:25:41AM +0100, Martin Rex wrote:
>
> You don't understand the purpose of SNI and how the (already weak)
> rfc2818 section 3.1 server endpoint identification and CABrowser Forum
> public CA Domain validation has been designed to work.
SNI has extremely little to do with
Ben Schwartz wrote:
> Martin Rex wrote:
>
>>Ben Schwartz wrote:
>>>
>>> Like a lot of people here, I'm very interested in ways to reduce the
>>> leakage of users' destinations in the ClientHello's cleartext SNI. It
>>> seems like the past and current proposals to fix the leak are
Ben Schwartz wrote:
>
> Like a lot of people here, I'm very interested in ways to reduce the
> leakage of users' destinations in the ClientHello's cleartext SNI. It
> seems like the past and current proposals to fix the leak are pretty
> difficult, involving a lot of careful cryptography and
For me, the main drawback here (besides the futuristic assumptions), is the
continued reliance on the DNS infrastructure. Even when using TLS, the DNS
is architecturally hostile to privacy, e.g., due to resolvers operated by
ISPs or the client subnet extension.
I'm sympathetic to the desire to
On 7 Feb 2017, at 18:12, Ben Schwartz wrote:
> Hi TLS,
>
> Like a lot of people here, I'm very interested in ways to reduce the leakage
> of users' destinations in the ClientHello's cleartext SNI. It seems like the
> past and current proposals to fix the leak are pretty
On 2/7/2017 9:11 AM, Ben Schwartz wrote:
> ...
>
> I proposed to treat IPv4 and IPv6 separately because a "dual stack"
> domain owner might reasonably have very different configurations for
> their IPv4 and IPv6 servers. For example, a domain owner might use
> shared hosting for IPv4, but assign
I read the doc. I’m a little dumb, but I think a more expanded ladder diagram
for Figure 2 would have helped me.
The basic process is query DNS, get the SNI record value, and use that as the
SNI value when connecting to the domain, right? But I’m not sure of the
interaction of CNAME entries
On Tue, Feb 07, 2017 at 11:12:12AM -0500, Ben Schwartz wrote:
> Hi TLS,
>
> Like a lot of people here, I'm very interested in ways to reduce the
> leakage of users' destinations in the ClientHello's cleartext SNI. It
> seems like the past and current proposals to fix the leak are pretty
>
13 matches
Mail list logo