Re: [therightkey] Defining CT-for-PKIX and CT-for-DNSSEC

[Tom Ritter <[e-mail]>]

On 17 November 2012 22:57, Paul Wouters <[e-mail]> wrote:

> CT-PKIX addresses an issue where there are 600 roots and you can't
> trust all of them (although TLSA solves that too). I'm still unsure
> what CT-DNSSEC would solve, as just pulling history from DNS does not
> add anything, and I have no idea how to authenticate to the CT-DNSSEC
> audit log to start an alternative path of trust, especially if you are
> defendining against a rogue root or rogue .com key being used secretly
> to sign alternative records, or a compromised DNSSEC private key.


I'd like to state what I think CT-DNSSEC would solve, and how it would
work.  I'll use .com as my example root, and google as my example CT
notary.  Hopefully I don't screw up the DNSSEC part or the CT part too
much...

I submit an entry for the DS record for example.com to the .com operator.
 The operator in turn contacts google but preferably multiple notaries and
says "This is the DS record for example.com" and google puts it into their
log, and gives back a signed statement as proof of such.  It then enters
this proof in some new type of record, we'll call it DSProof.  After the
.com operator has the proof, it updates the DS and DSProof records.

Now a user wants to connect securely to example.com.  They query the A
record for example.com, and get back the response plus the RRSIG, the
signature for the A record.  However, the client can't check the signature,
it doesn't have the key.  I'm unsure if in implementations this query
happens in parallel, in the same query or what - but it reaches out and
gets the ZSK for example.com, the KSK for example.com, and the DS record
for example.com - so it has the complete chain of keys from example.com ->
.com -> (root).  At this point it can verify the entire chain of
signatures.  But when it retrieves the DS record for example.com it also
retrieves the DSProof.

The client can verify that the DSProof is valid and comes from the google
notary (I'm not 100% sure if this is a signature of a merkle path ending in
a signature but it functions like a signature.)  The client ensures that
the DSProof is valid and from the google notary, meaning it has an entry in
the append-only merkel tree, which we can verify (and there
are verifiers for it.)  That gets into the CT side of things.

At this point, everything under example.com - whether it's the A record or
the TLSA record - is signed as normal, and the signatures under
example.comchain to a key that has been entered into a public log.  If
a TLD wants
to fraudulently sign a response for the A or TLSA record for a site, they
will have to also enter the key into the notary.  The operator of
example.com will be able to see there is a DS record they did not authorize
in the notary, and can start investigations or other mitigation processes.
 (Ideally the presence of the notaries will be the deterrent against the
attack.)

I think CT-DNSSEC is important.  We've seen domain seizures before. The new
gTLD program will open the internet to vast numbers of root operators, and
not all of them will be competent or lack malice.  Root keys will get
stolen.  Maybe it'll be .bugatti and not .bank but it will still happen.
 We should build this in now, while we can flesh it out pre-widespread
deployment of DNSSEC.

-tom