[Trans] ***SPAM*** 8.1 (5) Re: DNSSEC also needs CT

[Daniel Kahn Gillmor <[e-mail]>]

On 05/12/2014 02:01 PM, Nico Williams wrote:
> On Mon, May 12, 2014 at 12:54 PM, Joseph Bonneau <[e-mail]> wrote:
>>> Clients (lazily perhaps).  The public.  Domain owners.  Registrars.
>>
>> Certainly possible, but I wonder how much this will happen in a world of
>> thousands of DNSSEC-CT logs existing for various domains. Some of them
> 
> 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.

> 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).

> At any rate, the first-order problem in a
> hierarchical public key system is keeping the roots and intermediates
> closest to the roots honest.

agreed that the primary concern is transparency, monitoring, and
auditability of accumulated centralized control.

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.

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"?


So if Alice registers example.co.uk, she wants to do misissuance review
for that zone.  But in a DNSSEC context, she needs to do misissuance
review of the parent zones as well.  That is, she wants to ensure that
.uk is not publishing spoofed records about the .co.uk nameservers and
zone signing keys (how does she know if a change in DNSSEC records at
this layer is a legitimate change?).  And she also wants to ensure that
.co.uk is not publishing spoofed records about the example.co.uk zone.

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?)

	--dkg