On Mon, Mar 9, 2015 at 7:06 AM, Stephen Farrell <[email protected]> wrote:
> > Phill, > > On 09/03/15 05:50, Christian Huitema wrote: > > Then plug the holes in TLS. That ought to be the TLS charter. > > Right. The TLS WG have discussed this exact point a number of > times for TLS1.3. So far, nobody's found a convincing way to > solve the problem, but equally, I don't believe the topic is > closed, if someone finds a workable solution. I'd suggest you > chat to the TLS WG chairs to find out when they think it might > be a good time to bring this up again. And please also check the > WG archive - a bunch of different ideas were discussed already. > Actually I do have a solution but it depends on deployment of DPRIV and ACME first and we would probably want the ECC cipher suites as well. Privacy is hard. It is a lot harder than the security we have done to date because reducing the problem to independent parts does not work so well. It is like the difference between normal automotive engineering and Formula One racing. When you get to the really extreme performance you are not considering the engine as just an engine, it is also the principal structural member of the chasis. This approach is only tractable though if DPRIV in particular is designed in a way that respects the layering model and does not create a circular dependency in the stack. =Architecture We separate service discovery (SRV/MX) from host discovery (A/AAAA) and issue separate keys for each. If a host is co-locating 100 services it will have 100 service TLS certs and keys and one host key. Only the service keys are relied on for authenticating the service and so only those require the full PKIX lifecycle management tools. The host keys are just passed as raw keys through the DNS. =Key provisioning Let us imagine for the sake of argument that ACME is designed in a way that makes deployment of DANE like keys practical. That is the hook that lets me get a key for the host machine into the DNS. Without the ability to automate that part of the administration work, any attempt to introduce host keys is doomed to fail operationally. =Discovery phase The next part of the problem is how to efficiently discover the fact that there is a host key for the initial host exchange. There are many ways that this can be done but they all come down to separating out host discovery from service discovery with an SRV like record that allows us to attach what amounts to a TLSA like record. One of the side benefits of DPRIV is that the performance penalty for multiple DNS query transactions goes away. Whether we go the TCP route or the UDP route, the cost of making queries for five records is the same as the cost of one. =TLS Changes. With ACME and DPRIV in place we can then fix the TLS protocol. Which is fairly straightforward, we simply bolt a key agreement to the host key onto the front of the first client-server message. But this is only straightforward if we can offload all the negotiation part of the scheme off to the DNS. Now this could be seen as a TLS change or it could be seen as an outline for a TCPINC like beast. I prefer the second as we could use this approach as a substitute for TLS in cases where the alternative is to go enclair. If a site is colocating 100 sites and only ten of them have TLS certs, the other 90 still get the benefit of some encryption but there is no authentication component and certainly no padlock icon unless the DNSSEC chain is present and has been checked.
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
