We have lots of talk about TLS and DNS leaking privacy sensitive information.

These are obviously linked in that there is little point in protecting
DNS if the subsequent conversation to the endpoint is en-clair. And
SNI leakage is likely to undo any DNS security scheme.


I have a mechanism that can protect SNI but it is predicated on a DNS
privacy solution. So we solve that first and then use the solution to
attack the SNI issue.

In my approach to DNS privacy I am most concerned about the
client-resolver link. My approach can be applied in the
resolver-authoritative link but it needs to compliment other
approaches such as label minimization etc.




Premise 1: The DNS resolver is a trusted service. At minimum the
service is trusted to protect the confidentiality of the queries it
makes. In most cases the resolver is also trusted to return data to
the client if it exists (and this is desirable). The degree of trust
may be higher, especially if the DNS resolver is being run by the
party relying on it.

Premise 2: Since SNI privacy is essentially an extension of the DNS
privacy concerns it is logical that a service trustworthy for one is
trustworthy for the other.

Conclusion: A DNS resolver is an appropriate entity to broker
credentials to encrypt the TLS handshake including SNI.


My Private DNS approach is built on two main building blocks. The
first is a key exchange service. This is currently built on top of TLS

http://tools.ietf.org/html/draft-hallambaker-wsconnect-07

The connection protocol itself isn't very important here. The
important part is the output of this exchange is:

* A shared secret
* A set of cryptographic parameters
* An opaque secret identifier which may contain the above information
plus encrypted account information to allow a kerberos-style stateless
server to use the token for encryption.


Once we have such a token, Private-DNS is straightforward. The whole
draft is only 15 pages, most of which are examples:

http://tools.ietf.org/html/draft-hallambaker-privatedns-00


Now let us consider the TLS case and let us further consider a
situation in which the Authoritative DNS server for the TLS server
supports the Private DNS protocol and the resolver has established a
ticket with that server.

In this situation we have all the ingredients to deploy a full
Kerberos-style solution. We might want to introduce a
ticket-granting-ticket type concept but even that isn't essential
unless traffic analysis is a big concern.


At this point we can use the Kerberos* trust framework established in
the tickets for a variety of purposes:

1) Encrypt the TLS handshake

2) Pre-empt some or all of the handshake.

3) Skip TLS entirely and just encrypt and authenticate the transport
under the ticket mediated key. Call this protocol UYFM (its probably
not the acronym you are thinking of)


Note 1: Although we are encrypting the session, the trust context is
not end-to end. There are four parties that know secrets that are
sufficient to decrypt or spoof the traffic.

So this would not be an alternative to TLS for online commerce or
banking and it would be a lousy approach to password security. This is
not going to be as robust as TLS. It is however going to be vastly
superior to raw IP.

This approach would be a very good one for an objective of eliminating
plaintext traffic. So it would be good for the SNI and handshake part
of TLS.


Note 2: To apply the protocol in practice we would need to have a
management protocol that allows the TLS server and DNS server to
communicate. But this is a critical need in any case.


Note 3: To enable the introduction of the protocol we would need to
either publish the necessary data in the DNS or jack up the level of
abstraction a notch as I propose in Omnibroker.


* We can use Kerberos tickets but it is not necessary for any party to
know the internal structure of a ticket other than the party who
created the ticket except in the case of ticket granting tickets.



-- 
Website: http://hallambaker.com/