On Mon, Apr 27, 2015 at 2:03 PM, Christian Huitema <[email protected]> wrote:
> Bottom line, DNS/DTLS/UDP does not have much of an advantage over > DNS/TLS/TCP. It looks more like gratuitous complexity. Agreed Which is why I propose what is in effect a STLS (Staleless TLS) in which each UDP request packet (optionally) contains the full state required to decrypt it at the server. I use TLS over TCP to establish the STLS state however. If TLS/1.3 or TLS/2.0 was in a different situation then building DPRIV on that would make more sense to me. But I think those are quite a way off and for TLS/2.0 I would really like to adopt the same approach I am proposing here. 95% of the complexity in IPSEC and TLS is in the negotiation of the key agreement and there is absolutely no reason why we could not use the same key agreement mechanism for both. That is the point where PKI is involved, etc. DPRIV is only one half of the problem we have to solve here. If the solution to DPRIV is going to be any use, we also have to address the TLS SNI issue. I have a plan to solve the full problem. I don't think the folk saying 'yeah lets stick to what we know' do. My plan is: 1) Encrypt and Authenticate the client-resolver loop in a fashion that makes multiple DNS resource record queries practical. 2) Distinguish between keys for services 'www.example.com' from keys for hosts 'host23.colocation.com'. Publish ECC keys for the latter in the DNS 3) Rewrite the TLS handshake so that the initial exchange takes place under the host key. Thus SNI is always encrypted to the host. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
