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

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Nov 2012 08:01:10 -0800

CT-for-PKIX helps a web site administrator determine if a trusted CA ever issued a certificate that should not have been issued.  

CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS server in the hierarchy above the leaf zone ever included a DS record that should not have been included.

It would be good to have agreement on the above; feel free to offer changes and see if the authors agree. Then we can talk about the relationship between the two.

--Paul Hoffman

---

From: Shumon Huque <[email-masked]>
Date: Sat, 17 Nov 2012 13:18:39 -0500

> It would be good to have agreement on the above; feel free to offer changes and see if the authors agree. Then we can talk about the relationship between the two.

Sounds reasonable to me.

Does "CT" need to be renamed for DNSSEC? Since we're talking about 
transparency of delegation records/keys and not X.509 certificates. 
If C means "certification" in the general sense, then I suppose it
might still be applicable since a (signed) DS record certifies the
authenticity of the secure entry point key in a subordinate zone.

-- 
Shumon Huque
University of Pennsylvania.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Sat, 17 Nov 2012 14:32:48 -0500

> authenticity of the secure entry point key in a subordinate zone.

"DST"?

The definitions sound reasonable, but I'm at a loss as to why you would bother with "CT-for-DNSSEC".  The whole point of CT is that the space of X.509 issuers is very large, and the certificates can be presented by any server on the Internet.    It's a hassle to check every, say, HTTPS server on the Internet to see if a cert with your name is being provided.

In DNSSEC, the set of "issuers" is very small (parent domains), and the DS records originate from a well-defined set of sources (authoritative servers for those domains).  Checking those servers is not that much more difficult than checking a CT log, and doesn't require any new protocol.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Nov 2012 11:37:42 -0800

> In DNSSEC, the set of "issuers" is very small (parent domains), and the DS records originate from a well-defined set of sources (authoritative servers for those domains).  Checking those servers is…

Maybe you missed the earlier discussion of this in the past few days.

Rogue DS records might not be detectable to the party with the leaf record. For example, assume the domain name example.newtld. The owner of example has put DS record A in the newtld zone. If the owner of newtld goes rogue and shows DS record B to a limited number of requests (such as to a particular geographic region or set of network addresses), the party with the private key associated with B can spoof example, and the owner of example would not know unless he could see B.

--Paul Hoffman

---

From: Carl Wallace <[email-masked]>
Date: Sat, 17 Nov 2012 16:50:12 -0500

On 11/17/12 2:37 PM, "Paul Hoffman" <[email-masked]> wrote:

>>>> CT-for-PKIX helps a web site administrator determine if a trusted CA
>>>>ever issued a certificate that should not have been issued.
>>>> 
>>>> CT-for-DNSSEC helps a DNS zone administrator determine whether a DNS
>>>>server in the hierarchy above the leaf zone ever included a DS record
>>>>that should not have been included.
>>>> 
>>>> It would be good to have agreement on the above; feel free to offer
>>>>changes and see if the authors agree. Then we can talk about the
>>>>relationship between the two.
>>>> 
>>> 
>>> Sounds reasonable to me.
>>> 
>> The definitions sound reasonable, but I'm at a loss as to why you would
>>bother with "CT-for-DNSSEC".  The whole point of CT is that the space of
>>X.509 issuers is very large, and the certificates can be presented by
>>any server on the Internet.    It's a hassle to check every, say, HTTPS
>>server on the Internet to see if a cert with your name is being provided.
>> 
>> In DNSSEC, the set of "issuers" is very small (parent domains), and the
>>DS records originate from a well-defined set of sources (authoritative
>>servers for those domains).  Checking those servers is not that much
>>more difficult than checking a CT log, and doesn't require any new
>>protocol.
>
>Rogue DS records might not be detectable to the party with the leaf
>record. For example, assume the domain name example.newtld. The owner of
>example has put DS record A in the newtld zone. If the owner of newtld
>goes rogue and shows DS record B to a limited number of requests (such as
>to a particular geographic region or set of network addresses), the party
>with the private key associated with B can spoof example, and the owner
>of example would not know unless he could see B.

Who is intended to be able to contribute to the log?  It seems like for
this to provide the desired visibility, any client should be able to.  For
CT, at least, I thought this was not to be the case.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Nov 2012 18:06:35 -0500 (EST)

> CT, at least, I thought this was not to be the case.

How do you authenticate that? You cannot use the DS/DNSKEY for
authentication because then the CT audit log is useless to detect
compromises.

And you cannot say "The CA industry" either, which is the answer for the
CT-PKIX version. If you make CT-DNSSEC go through the CA industry, it
will cost $10/year or more to get in the audit log.

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 17 Nov 2012 17:24:07 -0800

On Nov 17, 2012, at 3:06 PM, Paul Wouters <[email-masked]> wrote:

> How do you authenticate that?

The submission includes the whole DNSSEC chain to the root, similar to what it does for CT-for-PKIX.

> You cannot use the DS/DNSKEY for

The purpose is to detect inclusion of DS keys that are not valid to the end host, not to detect "compromise". You have been following this mailing list, yes?

> CT-PKIX version.

OK, so maybe you haven't been following the mailing list or reading the draft. In the CT-for-PKIX proposal, individuals can submit their own certificate.

> If you make CT-DNSSEC go through the CA industry, it

Thank you, Strawman McBogusArg!

--Paul Hoffman

---

From: Carl Wallace <[email-masked]>
Date: Sat, 17 Nov 2012 20:32:42 -0500

On 11/17/12 8:24 PM, "Paul Hoffman" <[email-masked]> wrote:

>OK, so maybe you haven't been following the mailing list or reading the
>draft. In the CT-for-PKIX proposal, individuals can submit their own
>certificate.

Under this approach, how does the log come to have certificates that a
legitimate owner would like to be made aware of?  I understand the utility
of including the CT in the certificate and having an individual submit
their certificate (or the CA on their behalf) but locking down a log to
these sorts of inputs would seem to limit their usefulness for detecting
rogue certs.

---

From: Paul Wouters <[email-masked]>
Date: Sat, 17 Nov 2012 22:57:46 -0500 (EST)

> these sorts of inputs would seem to limit their usefulness for detecting

But allowing anyone to submit "new" certificates, allows hackers to do
the same. How is this authenticated?

For the TLS cert, the "out of band" was via DNS its the MX record. Which
has in fact reduced the security of the CA vouching system. With DNSSEC,
and compromise there, it means even less.

>From my remote participation, I understood the CT audits were
restricted, and that only CAs could submit entries for the audit log,
which is why when this was mentioned I channeled via jabber about
"security through money", and that I thought this was an invalid approach.
(especially for CT-DNSSEC, as publishing DS records is free, unlike
getting a "recognised" PKIX certificate)

On the lists I now hear anyone can submit, which also raises issues.
Perhaps there are very different thoughts for CT-PKIX-CA versus
CT-PKIX-selfsigned that I'm not aware of.

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.

Paul

---

From: Carl Wallace <[email-masked]>
Date: Sun, 18 Nov 2012 07:56:17 -0500

>the same. How is this authenticated?

For CT, by chaining to a given set of roots.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Nov 2012 10:25:16 +0000

> the same. How is this authenticated?

Your questions confuse me. Have you read the draft? Or any of the
various informal descriptions?

> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Nov 2012 10:30:23 +0000

> these sorts of inputs would seem to limit their usefulness for detecting

The idea is that the log contains all certificates the browser might
otherwise say are valid. If the cert would not be validated by the
browser anyway, there's no real point it being in the log - and so,
for pragmatic reasons (i.e. spam prevention), our current plan is to
not allow such certificates to be logged.

---

From: Carl Wallace <[email-masked]>
Date: Mon, 19 Nov 2012 06:49:28 -0500

>not allow such certificates to be logged.

That is only true for browsers that hard fail on missing/broken CT
extensions.  I've not followed why hard failing on this is expected to
work but not for other existing mechanisms.  We still have 15+ year olds
extensions that don't cause hard failures.  Pushing the extension into the
certificate and only accepting certs that have it just makes this part of
the issuance machinery.

In any case, I have a hard time seeing why you would reject certificates
signed by a public CA (or any other CA that is covered by the log).  CA
operators and legitimate domain owners should be interested in these and
the signature check ought to be good enough for spam prevention unless
things are more broken than is commonly reported.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Nov 2012 13:08:21 +0000

On 19 November 2012 11:49, Carl Wallace <[email-masked]> wrote:
> extensions.

What is only true? That there's no point it being in the log if the
browser would reject it anyway? I don't understand that.

> I've not followed why hard failing on this is expected to

The extension does not have to be in the certificate, it can also be
in the TLS handshake.

> things are more broken than is commonly reported.

We would not reject them. Why do you think we would?

---

From: Carl Wallace <[email-masked]>
Date: Mon, 19 Nov 2012 08:20:42 -0500

>We would not reject them. Why do you think we would?

A misunderstanding I hope.  If you are saying that browsers/observers
can/would submit certificates that chain through a CA covered by the log
then I have no issue.  If (as I had come to think) the log is fed during
issuance, then I think a significant part of the potential value is lost.

Part of the problem in tracking this right now is the TBD in section 3 of
the draft.  I'll refrain from further comment until that text is present,
since that should clarify things.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 19 Nov 2012 13:34:15 +0000

> issuance, then I think a significant part of the potential value is lost.

Anyone can submit to the log. The log (at least our log!) will accept
any certificate chained through a public CA.

> since that should clarify things.

I will at least outline what will be in the messages soon.

---

From: Tom Ritter <[email-masked]>
Date: Tue, 20 Nov 2012 18:47:09 -0500

> 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

---

From: Ben Laurie <[email-masked]>
Date: Wed, 21 Nov 2012 10:52:13 +0000

On 20 November 2012 23:47, Tom Ritter <[email-masked]> wrote:
> 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!

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