On Tue, Oct 28, 2014 at 2:30 AM, Christian Huitema <huit...@huitema.net> wrote:
> CGA-TSIG is a possible solution to the "secure-provisioning" problem. The > IPv6 CGA address contains a hash of a public key used to secure the > service. If the address is provisioned in a secure manner, then the client > can authenticate the resolver, by verifying that the resolver's certificate > matches the hash in the IPv6 address. I am not sure that this is the best > solution, but it is certainly more secure than pointing the resolver to > "8.8.8.8" and later observing that this is in fact rerouted to the Turkish > police. > > This kind of provisioning is a tradeoff. The main advantage is to not > create a new provisioning channel. No need to be bothered with entering a > certificate, entering the address suffices. But of course the flip side is > that it only works if we update the DNS client and the resolver. If we do > change the client and resolver, a number of alternatives can be used, such > as: > > * Use the same trick as CGA but encode the hash of the certificate as a > name part, e.g. "AF4563ED0B561.example.com". This is probably easier It is also potentially more general. I wrote on this in a paper for the IAB workshop: http://tools.ietf.org/html/draft-hallambaker-presentation-00 Let us imagine that you are issued a new Surface 10 by Microsoft (lets face it, all version numbers are now 10). It is a corporate machine so the root of trust for the machine must be a Microsoft key. So in the back room somewhere, someone has taken out the Microsoft root of roots and signed 'stuff' that interests Microsoft, like the ICANN DNS root and the CA roots installed in the browser. What you would want is to have that as the ultimate root of trust for everything connected to that device. So representing this as a DNS label we might get something like the following: example.com.xx--49AAC1-1D7B6-F6446-702E5-4A1607-3716 Here I have taken the x?-- prefix convention and allocated a new prefix to represent a hash. These are in hex but Base32 encoding is obviously a little better. These are what I call strong DNS names. Note that we only need a 128 bit hash for this particular application because the birthday attack does not apply. It is a very clean and a very general means of encoding root anchors and ensuring that there is close control on the trust. So lets imagine that in .NET there is a stream class 'NetworkStream' with the following constructors: NetworkStream (string Domain, string Service) // SRV service discovery NetworkStream (string Domain, int Port) // Well known port discovery If we give these constructors a strong name, we can in principle use it to construct a secure channel to the selected endpoint that does not depend on any additional root of trust. One consequence of this approach is that it potentially makes network administration a lot simpler because all that you need is a domain name. Now before everyone starts breaking out the champagne because us CAs 'go away'. This is only true if you never need to go outside your own domain and never need to establish yourself as trustworthy externally. What it does mean though is that example.com could set up an internal Web service client that is guaranteed to only accept certs that were issued by the example.com CA directly or by a CA that example.com had cross certified. This would seem to be an excellent security approach for a nuclear power station.
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
