Paul, At 2016-12-13 11:16:08 -0800 "Paul Hoffman" <paul.hoff...@vpnc.org> wrote:
> On 13 Dec 2016, at 6:46, Shane Kerr wrote: > > > IIRC the idea of using IPsec was also discussed somewhere. IIRC, IPsec > > may have problems traversing NAT. It is also usually implemented by > > the > > kernel, which may cause deployment issues. I *want* IPsec to be an > > option here, but realistically I don't think it is. > > IPsec will always have worse characteristics for DOS than DTLS, and > probably worse than TLS. Why do want it to be an option here? IPsec seems desirable because somehow it seems better to be able to layer on top of security at the lowest level possible? Layer 3 instead of layer 4? Although I guess the only extra information we would be exposing with TLS or DTLS would be the port numbers, which seems minimally useful to an attacker. > >> 2) Which authentication(s) to use? > > > > I really like the CGA approach, but realistically I don't think that > > would be accepted. If we think that it would be, then I'm all for it. > > Why do you think it would not be accepted? It could be used where > available, and fall back to current authentication when it isn't. CGA requires IPv6, and the hash is only 60-some bits long, so maybe it is both too futuristic and not future-proofed at the same time. Like I said, I really like it but I can see push-back. > > Otherwise I think we should lean towards putting authentication > > tokens in the DNS itself. > > OK, now I'm confused. I thought this is what you meant by "CGA > approach". Can you explain the difference? CGA authenticates IP addresses by encoding the public key in the address itself. Because of this there is no need to publish a public key; if you have the IP address you can already authenticate the holder has the private key. There is literally nothing else for DNS to publish beyond what it already does (the IP address of the authoritative DNS server). If we don't use CGA then we have to publish the public keys somehow. Those keys are the authentication tokens that we have to publish, and I think that DNS makes sense for this. > > AIUI the draft, if we want to use DNS the problem is that we want to > > know how to encrypt a session to a name server, but we can't look up > > anything about the name server in the DNS because we don't yet know > > how > > to encrypt a session to the name server. > > The draft drifts towards that, but I don't think it is the right problem > statement. Instead, we should be going towards "encrypt wherever > possible, but don't limit yourself if you can't." I think that's fair, but I'm not sure that we have to give up on full encryption. Maybe, but lets see if we can figure something out! :) Cheers, -- Shane
pgph1HYF9fjmU.pgp
Description: OpenPGP digital signature
_______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
