HI Dan, inline …
On Oct 21, 2013, at 6:11 AM, Dan York <[email protected]> wrote: > Cullen, > > On 10/20/13 6:58 PM, "Cullen Jennings" <[email protected]> wrote: > > >> I've been thinking about how to build cloud collaborations systems where >> the data is encrypted and the cloud does not have the keys. Very >> interested in hearing others thoughts on how to do this. > > Good document. In a quick read I naturally have to react to slide 23 > (Trusting DNS) and also slide 11 (Certificate Authority). On slide 23, > you say "Sorry, can't trust this yet.", but what happens as we get more > DNSSEC deployed? We're already seeing increased validation within caching > resolvers and some measurements are showing around 8% of all DNS queries > coming from resolvers that perform validation. We're seeing steady growth > in the number of DNSSEC-signed domains. I know there are those who are > skeptical about DNSSEC deployment, but I'm definitely seeing real > growth... and see a number of trends pointing to that only continuing. No question that things are going the right direction. Let figure out how we could use this and likely when. In fairness it will take time to build something like I am proposing and DNSSEC will be better then than it is now. > > Similarly, on slide 11 you mention the ongoing issue that CA's can issue > bad certs and the goal is to detect this. We do have an existing > mechanism that can help here. DANE (RFC 6698) allows the zone operator to > include a fingerprint of a cert (or an entire cert) in a DNS zone and then > sign that with DNSSEC. Couple that with DNSSEC-validating resolvers and > you've got a way to add an additional layer of trust assertions on top of > the CA infrastructure. Sure, CAs can still issue bad certs, but if the > cert being offered doesn't match the cert fingerprint securely stored in > DNS then the endpoint should know right then to reject the bad cert. Using DANE for belt and suspenders on CAs seems good. I also think it would be well worth think about who is in the trust chain for a domain that was in .us vs say .cn and consider how that might all play out from security point of view. I had not thought much about this but it does deserve thinking about what we can do. > > Typo: slide 8 - I think you meant "in that you" - "The CA is "honest" is > that you can tell if it issues your certificate to someone else but there > is no way to stop it from doing that" oops - yes - The type of thing I was thinking about here are various proposal where CA publish all the certificates they have issued and there are various cryptographic hash chains that make it difficult for them to lie about this. That means a CA might be able to issue your cert to a bad guy but that it would later be possible to detect that. > >> Near the end is a list of things that it would be helpful if the IETF >> standardized. > > Good list! Tell me what to add to this list for DNSSEC / DANE that we are not already doing > Dan > > -- > Dan York > Senior Content Strategist, Internet Society > [email protected] <mailto:[email protected]> +1-802-735-1624 > Jabber: [email protected] <mailto:[email protected]> > Skype: danyork http://twitter.com/danyork > > http://www.internetsociety.org/deploy360/ > _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
