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

On 20 November 2012 23:47, Tom Ritter <tom@ritter.vg> wrote:
> On 17 November 2012 22:57, Paul Wouters <paul@nohats.ca> 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...

This looks about right to me, just one clarification. Also, as others
have said, CT-DNSSEC is probably not the right name for it!

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

In CT this is a signature from the log that is in effect a promise to
include the cert in the log. This is so that the CT log server can
respond immediately to a certificate request without having to
generate a whole new tree. We did this in the interest of reliability
and uptime (since there can only be one correct tree, it is required
that all responses from a server farm are ordered, which is
considerably more demanding than it is to store certificates for later
ordering, in short).

However, if DNSSEC servers are prepared to wait a while, sometimes,
then we could make it an actual merkle path - this was the original
design of CT, but CAs didn't like the delay.

>  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.com
> chain 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
>
> _______________________________________________
> therightkey mailing list
> therightkey@ietf.org
> https://www.ietf.org/mailman/listinfo/therightkey
>