Re: [TLS] About encrypting SNI

[Eric Rescorla <[e-mail]>]

On Tue, Apr 15, 2014 at 10:01 AM, Eric Rescorla <[e-mail]> wrote:
>
> Obviously this requires messing with DNS to provide confidentiality and
> secure
> delegation, but we would need confidentiality in any case, and secure
> delegation
> is mostly a matter of working out the record semantics once you've solved
> the
> big problem of securing the DNS. [0]
>

Martin Thomson pointed out to me offline that this sort of conflates two
forms of DNS security:

1. End-to-end resolution security (e.g., DNSSEC or something like DNSCurve
    where there is a chain of delegations all the way down to the leaf
node).
2. Client-to resolver security (e.g., DNScrypt or where the attacker is
     not on-path to your resolver but is on-path to the server) where you
hope
     that your activities are hidden by DNS caching.

Clearly, this proposal will only work when integrity is provided down the
entire
chain, although it might work if there was DNSSEC + client-to-resolver
confidentiality. However, note that:

(a) IETF is just starting to look at standardizing DNS encryption
(b) the existing DNS encryption systems have seen limited deployment
(c) most of the problems with DNSSEC deployment have to do with
intermediate elements which would either block DNS encryption
or (alternately) could use DNS encryption to bypass the intermediary
messing with the DNSSEC records

Given these issues, it still seems like it's at least plausible to consider
DNS
integrity a prerequisite here.

-Ekr





I only just wrote this down, so maybe it's totally messed up, but it seems
> like a
> natural extension of Rich's idea. What do people think?
>
> -Ekr
>
>
>
> [0] Note: I'm not saying this is solved since DNSSEC deployment isn't good
> right now, but if it's not solved then SNI encryption doesn't buy us much.
>
>
>
>
>
>
>
>
>>
>>
>>                 /r$
>>
>>
>>
>> --
>>
>> Principal Security Engineer
>>
>> Akamai Technology
>>
>> Cambridge, MA
>>
>>
>>
>
>