Subject: [Trans] comments on Sections 7 + 9 (the last set of comments before Toronto)

From: Stephen Kent <[email-masked]>
Date: Thu, 03 Jul 2014 14:39:41 -0400

*Section 7*

The Security Considerations include some statements that worry me. It 
says "If a server presents a valid signed timestamp for a certificate, 
then the client knows that the certificate has been published in a log." 
This is not quite true, since the certificate may be published later, or 
never at all. Please try to be more precise here.

It also says "...the client knows that the subject of the certificate 
has had some time to notice the misissue and take some action, such as 
asking a CA to revoke a misissued certificate."Since the client doesn't 
know, with certainty, that the Subject is monitoring for mis-issuance, 
the client can't know how long it may be before the mis-issuance may be 
remedied. The statement here needs to note that a client cannot assume 
how long it may be before mis-issuance problems are detected and 
remedied. The last sentence of the first paragraph of this section does 
a good job of noting these limitations, but its message is diluted by 
the preceding statements.

The final paragraph is good, although "transparency" may be too much of 
a euphemism! The lack of a discussion of various scenarios with respect 
to how mis-issuance may occur (see my comments on the Introduction) 
makes it harder for a reader to understand the ways that CT is intended 
to address the problem of certificate mis-issuance. Itmight be 
appropriate to compare CT to key pinning 
(draft-ietf-websec-key-pinning-17.txt) , for example, since both 
mechanisms attempt to deal with some of the same attacks.

*Section 7.1*provides a good explanation of how MMD fits into the CT 
scheme. But it begins with an absolute statement about TLS clients 
rejecting certificates w/o an SCT. Absent a discussion of how to address 
partial deployment, the first sentence does not seem reasonable.

*Section 7.3*seems to offer a warning that some examples of redacted 
names could be dangerous, but it provides only a couple of examples. 
Without a more precise definition of what constitutes a dangerously 
"overly redacted" precertificate, the warning here is not adequate. The 
statement "TLS clients MAY reject a certificate whose corresponding 
precertificate would be overly redacted." seems impossible to implement, 
based on the level of specification presented here. (If a certificate is 
dangerously over-redacted, and we define what that means, maybe a SHOULD 
is more appropriate.) This subsection needs work, and may be indicative 
of a serious problem with respect to the security afforded by redacted 
precertificates.

*Section 7.4*describes how two forms of log misbehavior can be detected. 
The first type of misbehavior is a violation of the MMD. This 
description is a bit worrisome as it specifies relying on a "trusted 
auditor" (a new term) if a client does not want to reveal what 
certificate is of interest. The alternative approach suggested (for a 
client that does not want to reveal what certificates are of interest) 
is to request proofs for a batch of certificates. A more algorithmic 
description of the suggested behavior should be provided, either here or 
in Section 5.4 (which probably needs to be re-written anyway), along 
with a definition for a "trusted auditor" (or just delete the term 
"trusted"). The second type of misbehavior, characterized as violating 
the append-only property, is detected by "global gossiping." This is not 
a reasonable explanation of a countermeasure, given the lack of any 
detailed description of how such gossiping is to take place.

*Section 9*raises an important topic, i.e., key rollover. But saying 
that this topic needs to be addressed in the future is worrisome. The WG 
needs to decide if it's OK to postpone this critical aspect of the 
design to a future document.