Cullen,
Inline... (and finally getting caught up on past conversations) On 10/24/13 12:23 AM, "Cullen Jennings" <[email protected]> wrote: >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. Ack. > >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. Agreed that it's worth thinking about how the trust chain may be different for different TLDs. >> >> Typo: slide 8 - I think you meant "in that you" - "The CA is "honest" is >> that you can tell if it issues your certiļ¬cate 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. But I want to detect the bad cert *before* someone goes to a site (or in the process of going to a site). I agree that this capability of tracking issued certs would be VERY useful in detection of compromised certs... but this doesn't necessarily seem to me something that can work in real-time. It can be something used to figure out what happened after-the-fact... but in the meantime someone has already gone to to the bad site that they thought was legit. The advantage of DNSSEC/DANE is that the bogus cert can be detected before someone actually goes to the site. If the fingerprint of the cert stored in the TLSA record (and signed with DNSSEC) doesn't match the fingerprint of the cert being offered by the server... then the app knows there is a problem. >>>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 For DANE, I think we're doing pretty well right now with what is defined in RFC 6698 and some of the other drafts. There's a good document out in the DANE working group that is aiming to capture operational experience of using DANE: http://tools.ietf.org/html/draft-dukhovni-dane-ops-01 I'd note that this document initially came about in the process of one of the authors adding DANE support to the postfix email server. (And the authors are seeking comment from other implementors.) On the DNSSEC side, again I think DNSSEC is well-defined in terms of standards... what is happening now, primarily in DNSOP, is looking at how we standardize and automate some aspects of the DNSSEC provisioning process. (For example, tomorrow's DNSOP discussion around mechanisms to facilitate communication of new key material from a child zone to a parent zone.) So I guess what we need to add to your list for DNSSEC / DANE is really documenting (and potentially standardizing in some cases) operational/deployment experience of what needs to be done to get the protocols in use. 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
