On Tue, May 13, 2014 at 9:53 AM, Daniel Kahn Gillmor <[email protected]> wrote: > On 05/12/2014 02:01 PM, Nico Williams wrote: >> The ones that matter most are the TLDs and the root. Those get so >> many users that they will be caught MITMing, if they do. > > I think technically what we care about is the public registries, not the > TLDs. This was my point about the public suffix list and DBOUND: that > we care about .co.uk just as much as we care about .net. > > I know that some people use the term TLD to refer to the public > registries instead of "top-level domains", but i think it's worthwhile > to be precise in this discussion.
That's fair. I do tend to think of co.uk. as a TLD... for lack of a better term (is there one?), yes. You're quite right: if a zone is (has) a public registrar(s) then it should be audited w/o privacy. Whereas if it doesn't sell registrar services, then it is less important that it log names: we can assume that names below it are roughly in the same administrative domain as the zone itself. >> If evilhosting.com has lots of customers, then they'll help audit it, >> else they might not. > > If evilhosting.com is handing out subdomains to its customers and > expecting them to act as different administrative sub-zones, then > evilhosting.com effectively *is* a public registry, and as such it needs > to be auditable as well. (it also needs to be considered a public > registry for the sake of cookies and other same-origin policy things on > the web, for example, so that jbonneau.evilhosting.com can't set cookies > that would apply to dkg.evilhosting.com). Agreed. > Who is actually doing the monitoring and auditing is a separate > question, though. > > note that CT appears to differentiate between monitoring (RFC 6962 > section 5.3) and auditing (RFC 6962 section 5.4) in this way: > > Auditors make sure that SCTs are cryptographically valid against an > STH, and that one STH chains properly to another; > > Monitors make sure that the whole log itself is cryptographically > valid, looking at all the data. > > Neither of these activities describes the actual checks that would need > to happen for misissuance to be detected. As noted in section 7.2, > "interested parties" need to think about how to monitor to ensure that > items with their administrative domains are not logged by other parties. I would think that domain owners are "interested parties", and/or maybe agents they delegate to (e.g., hosting companies). I can audit the logs for my domain's parent zone. But yes, this probably needs to be covered in more detail. (Are there FOSS implementations of monitors/auditors?) > If this is neither "Monitoring" nor "Auditing" maybe we need a name for > this kind of activity, so we can discuss it more directly? how about > "misissuance review"? It seems to fall into "monitoring" given the text of the RFC. > How does she know what logs to look in for this misissuance review? Is > there a way she can do this review efficiently? I think these questions > are relevant for regular CT as well, but a DNSSEC-focused CT adds the > wrinkle of delegated zones. (maybe this isn't actually worse than X.509 > PKI with its fully-delegated intermediate CAs though?) No, it's easier! With the name contraint-free TLS PKI the domain owner has to check... every root CA. With DNSSEC, which has strict name constraints, there's only one issuer for each zone cut. Nico -- _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
