Subject: [therightkey] CT Qs

From: Trevor Perrin <[email-masked]>
Date: Tue, 22 Jan 2013 15:07:15 -0800

Hi,

Some questions, based on draft-05:

(1) Is there going to be a DNS-based protocol for retrieving audit proofs?

(2) Why are the RFC 5878 / RFC 4680 Authorization Extension and
SupplementalData mechanisms used to convey the SCT, instead of
defining a new TLS Extension?  (RFC 5878 is an Experimental-track TLS
Extension; CT adds a new extension value to it to signal that an SCT
is included in an RFC 4680 SupplementalData handshake message; this
seems more complex than just putting the SCT directly in a TLS
Extension).

(3) Some things about "precertificates" are unclear to me, in draft-05:
 - If the precert is signed by the "CA certificate that will sign the
final certificate", as described in the second bullet in 3.1, does
this CA cert also need to contain the "Certificate Transparency" EKU
extension from the first bullet?
 - In the SCT for a precertificate, what exactly does the log sign?
Is it the TBSCertificate including the poison extension, or is the log
expected to remove the poison extension prior to signing?
 - How exactly does a TLS client verify an SCT for a precert?  Does
the client need to remove the SCTs and recalculate the original
TBSCertificate's ASN.1 to verify?
 - Related to previous: why is it necessary for SCTs and
MerkleTreeLeafs to have different cases for precerts and certs?  Could
the signature be calculated on a "normalized" form of the
TBSCertificate which is the same for certs and precerts (i.e. the
TBSCertificate with poison and SCT extensions removed?)

(4) Why is the SCT's timestamp and CtExtensions included in the
MerkleTreeLeaf?  If the Merkle Tree was built directly on hash(cert)
leaves instead of hash(SCT fields), then the audit path mechanism
could be deployed earlier / independently from SCTs, i.e. browsers
could retrieve and check audit paths for certs regardless of whether
the TLS server had presented an SCT.  Perhaps CT doesn't envision that
use case, but it seems potentially useful.  So I'm wondering if it
might be worth decoupling the SCTs from the merkle trees to provide
more deployment flexibility.

Trevor

---

From: Ben Laurie <[email-masked]>
Date: Wed, 23 Jan 2013 00:19:24 +0000

> (1) Is there going to be a DNS-based protocol for retrieving audit proofs?

Yes. Not in this I-D.

> seems more complex than just putting the SCT directly in a TLS

At the time the mechanism was defined, Experimental track was more
standardised than what we were defining. We could indeed contemplate
defining our own extension if we go beyond Experimental ourselves.

> expected to remove the poison extension prior to signing?

This is more clearly explained in the next revision.

> TBSCertificate's ASN.1 to verify?

Yes.

> TBSCertificate with poison and SCT extensions removed?)

We did consider that, but it is not what the code does currently.
There's no particular reason it could not be done that way, as far as
I currently know.

> more deployment flexibility.

I think there are two semi-separate issues here:

1. The log must be held to a promise to include a cert within a
certain time, which is why it signs an SCT. I think it is correct that
you could construct a working system that then built a Merkle tree on
the cert alone (I may have missed an attack, though[1]), but I don't
think this actually has any advantage over a tree built on the SCT
(see point 2), given that you have to make an SCT anyway.

2. If you built a Merkle tree based on the cert alone, what would the
correct action of a client which saw a cert with no SCT be? Sure, it
could check the log and see it was not in it - but then what? It can't
reject it, perhaps it is the first CT-enabled client to see the cert
(or one of the first). The fact it lacks an SCT shows it hasn't
participated in voluntary logging. So the correct action is to log it,
and obtain an SCT for it (which can later be shown if the log fails to
include the cert). So why not just always attempt to log it? If its
already there you'll (probably) get an SCT in the past. Otherwise,
monitors can pick it up and take appropriate action. BTW, I am not
against logs providing a way (e.g. via DNS) to pre-check whether a
cert exists in the log before attempting to log it, but I don't think
that needs to be part of the CT spec.

In any case, we are not primarily attempting to build a system that
solves a half-way problem - we want full deployment of CT.

[1] There are, of course, distinct weaknesses compared to a system
built on SCTs - for example, the tree is no longer self-timestamping
and so claims about timing become more difficult to substantiate.

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

---

From: Trevor Perrin <[email-masked]>
Date: Wed, 23 Jan 2013 11:25:46 -0800

On Tue, Jan 22, 2013 at 4:19 PM, Ben Laurie <[email-masked]> wrote:
>> defining a new TLS Extension?
[...]
> defining our own extension if we go beyond Experimental ourselves.

Defining your own TLS Extension seems simpler, why not do it from the start?

I'd be curious if potential implementors have an opinion.  The
difference is roughly:

WITH A CT TLS EXTENSION:
 - ClientHello contains a TLS extension to indicate CT support
 - ServerHello contains a TLS extension with:
   - 2 byte length of SignedCertificateTimestampList
   - sequence of:
     - 2 byte length of SCT
     - SCT

WITH THE 5878 TLS EXTENSION:
 - ClientHello contains a TLS extension with a list of single-byte
values, one of which indicates CT support
 - ServerHello contains a TLS extension with a list of single-byte
values, one of which indicates SCTs are present
 - Following ServerHello is an RFC 4680 SupplementalData message:
   - 3 byte length
   - sequence of SupplementalDataEntry, each with:
     - 2 byte type
     - 2 byte length
     - (if type = "authz_data", then the body of this entry is):
       - 2 byte length
       - sequence of AuthorizationDataEntry, each with:
         - 1 byte type (which may indicate an SCT is present)
         - (length field for SCT?  unclear in draft-05)
         - SCT

(I think this is right but the structures in 5878 section 3 don't
actually match 4680 (errata?), nor does draft-05 define the encoding
of an SCT into an AuthorizationDataEntry, so I'm not sure.)

Anyways, 5878/4680 seem like unnecessary layers of parsing.

> There's no particular reason it could not be done that way, as far as

It would seem simpler, since clients would not need separate code
paths for precerts and "fully-logged" certs.  Also, this would
simplify the data structures since you could eliminate the
"entry_type" from the LogEntry, SCT, and MerkleTreeLeaf.

Related comment: There should probably be Security Considerations
about logging TBSCertificates, since I think there are some subtle
issues that arise from logging TBSCertificates if you're using
revocation systems based on the full certificate (like OCSP, CRLsets,
etc.).

For example, a rogue CA could potentially issue a rogue sub CA with
the same name as some existing CA, and this rogue sub CA could issue
rogue certs with TBSCertificates that match existing certificates.  If
such a rogue certificate was issued that matched a revoked cert for
which an attacker had compromised the private key, the rogue cert
could be used with the revoked cert's SCT, but might not itself be
revoked (since revocation methods like OCSP and CRLsets scope
revocations to the issuer's key hash).

So, revocation systems would need to be cognizant of this risk and
revoke the TBSCertificate, it seems?

>> could be deployed earlier / independently from SCTs,
[...]
> and obtain an SCT for it

Or just report it to someone you trust who logs it for you - the
browser doesn't need the SCT in this case.

> So why not just always attempt to log it?

It's more efficient if the browser could fetch an audit proof without
also needing an SCT, and it would be simpler if Merkle Tree Leaves
were just defined like:

       struct {
           Version version;
           opaque tbscertificate<1...65535>;
           }
       } MerkleTreeLeaf;

I guess these aren't the strongest arguments, but I don't see that
this simplication loses anything important.

> solves a half-way problem - we want full deployment of CT.

Sure, but if it's going to take awhile to get SCTs universally
deployed, it would be nice to get some of the benefits of CT earlier.
That's why I like the idea of using scanning and online checks to
populate logs until SCTs are ubiquitous (at which point the CAs and
TLS servers will have assumed the responsibility of populating logs).

> and so claims about timing become more difficult to substantiate.

I don't see the weakness - the log is ordered, periodically signed
with a timestamp (TreeHeadSignature), and monitored, so won't you have
good timing data for log entries regardless?

Trevor

---

From: Emilia Kasper <[email-masked]>
Date: Thu, 24 Jan 2013 13:10:10 +0100

> I'd be curious if potential implementors have an opinion.  The

We've already implemented 5878 for OpenSSL and Apache. The wider benefit of
a more general mechanism is that adding new types of authorization data
(Revocation Transparency?) will in the future not require upgrading servers
again.

> "entry_type" from the LogEntry, SCT, and MerkleTreeLeaf.

Not strongly opposed to it, though it would leverage the re-signing attack
you describe below to existing certificates, too.

> revoke the TBSCertificate, it seems?

A little far-fetched as an attack - but yes. CAs can include an Authority
KeyID extension in new (TBS)Certificates logged by CT, to protect against
this.

> this simplication loses anything important.

We don't know what the CT extensions will be yet but I imagine we'll want
to have them included in the tree, so that monitors can examine them.

Also, the SCT timestamps serve as a hint for the location of the entry in
the tree - makes it easier to design efficient privacy-friendly client
protocols (briefly mentioned in Sect. 7.3 of the current draft version).

Best,
Emilia

---

From: Trevor Perrin <[email-masked]>
Date: Thu, 24 Jan 2013 13:18:29 -0800

Hi Emilia,

I'll comment on 5878 separately, to your other points:

> you describe below to existing certificates, too.

I guess, though a rogue CA #2 could submit precerts for existing
certs, thus exposing them to this attack from other rogue CAs... even
more far-fetched, I admit, but I tentatively think there should be a
better solution to that attack in general, as opposed to just partly
limiting who is exposed to it.

> KeyID extension in new (TBS)Certificates logged by CT, to protect against

I think the Authority Key Identifier is matched against whatever
Subject Key Identifier is declared in the issuing CA cert.  So, I
*think* it can be chosen by an attacker to match a target
TBSCertificate, and doesn't help here?

Maybe there should be some other X.509v3 critical extension, allowing
the TBSCertificate to contain a reference to the issuer's public key?
That might be easier than modifying revocation systems?

> We don't know what the CT extensions will be yet but I imagine we'll want to
> have them included in the tree, so that monitors can examine them.
>

Hmm.  You could always define a new leaf type if you need
extensibility, and having clients lookup entries based on time ranges
(or leaf_index ranges) doesn't seem to require actually hashing the
SCT's timestamp into the leaf.

So I'm not convinced you're gaining anything worth the loss in
simplicity and flexibility of a simpler leaf based directly on
certificates.

But it's a design decision, there's arguments both ways...

Trevor

---

From: Emilia Kasper <[email-masked]>
Date: Fri, 25 Jan 2013 19:02:11 +0100

> TBSCertificate, and doesn't help here?
Right...

> That might be easier than modifying revocation systems?

What we could do, I think, is stick the TBSCertificate issuer's public key
under the SCT signature. Keep in mind the goal, for us, is to bind the
TBSCertificate that appears in the log to the certificate the TLS client
sees.

> extensibility,

The extensions, as we proposed them, are meant to maintain backwards
compatibility with old TLS-CT clients.

> and having clients lookup entries based on time ranges

> But it's a design decision, there's arguments both ways...

Sure.

Cheers,
Emilia

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 26 Jan 2013 08:53:00 -0800

> TBSCertificate that appears in the log to the certificate the TLS client

I'd put it a bit differently: an end-entity cert or TBSCert is not a
fully self-contained object, it depends on some context from its cert
chain.  So in addition to binding the end-entity cert or TBScert into
the SCT and MerkleTreeLeaf, you may need to bind some of this context,
to ensure that log monitors and TLS clients are seeing the same
things.  Issuer public keys are an important piece of context, because
in some revocation protocols, like OCSP, they determine who can revoke
the cert.

So I think the TBSCert vs. full cert distinction is a bit of a red
herring.  Even if you bind a full cert, I think you still want to bind
its issuer public key.  Otherwise you're relying on the cert's
signature to bind the issuer public key, which seems like an unusual,
possibly unsafe use of crypto (though correct me if I'm wrong!)

Anyways, is there other context from the cert chain that needs
binding?  What about:
 - Issuer keys or names from other certs in the chain?
 - The end-entity cert's signatureAlgorithm?
 - Name constraints?
 - Certificate policies?
 - Anything else?

Trevor