Re: [Trans] updated definition and attack analysis text

[Rick Andrews <[e-mail]>]

Steve,

RFC 6962 says "In order to avoid logs being spammed into uselessness, it is required that each chain is rooted in a known CA certificate", and that's a syntactic check, isn't it? So it's not a question of whether logs will perform syntax checks or not, it's a question of how much syntactic checking will be required.

Comments on your text are inline.

-Rick

From: Trans [mailto:[e-mail]] On Behalf Of Stephen Kent
Sent: Wednesday, October 01, 2014 10:51 AM
To: [e-mail]
Subject: [Trans] updated definition and attack analysis text

Ignoring (for the moment) the suggestion to not consider syntactic mis-issuance,
and the topic of whether logs might perform syntax checks on certs submitted to them,
I have revised the attack analysis text. It at least provides a sense of the style
and structure one wants in such text, and which is missing from 6962-bis.

I've expanded the definitions of mis-issuance based on the message exchanges
Ben and I had, to more clearly describe the cases of syntactic and semantic
mis-issuance that are outside of the scope for CT, or that may be detectable only
if a Subject operates its own Monitor. I also added structure to group the attack cases,
to make for easier reading. I' ve kept the "notes" style, but these could be folded into
the attack case analysis if desired. (It would just introduce some redundancy.)

Steve

------
A certificate is characterized as mis-issued if the certificate does not conform to the requirements established by CA Browser Forum (CABF) documents for "domain validation" (DV) or "extended validation" (EV) certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance takes two primary forms syntactic mis-issuance and semantic mis-issuance.
Missing a colon after "forms".

Most instances of the syntactic *form* of mis-issuance can be detected by examining a certificate against a set of criteria extracted from the CABF guidelines. Based on whether a certificate purports to be a DV or an EV certificate, one can examine it against almost all of the syntactic constraints imposed by the guidelines. Appendix A, Section A.1 enumerates the syntactic criteria to be used in this case. These checks can be performed by a log before issuing an SCT, and if a (pre-) certificate fails these checks, it *the SCT* should not be issued. This behavior is RECOMMENDED to provide feedback to CAs, to detect potential syntactic mis-issuance before the certificate is issued.


<Discuss classes of adversaries, motivations, and capabilities>


1. Criminals



2. Hacktivists


3. Nation states (intelligence organizations)


4. Other?
Malicious or non-malicious Web PKI CAs operating improperly?

If the certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. Because the CA is non-malicious, it will remedy the syntactic problem and re-submit the (pre-) certificate to a log again. Thus syntactic mis-issuance of this type will be thwarted.
But only if the log behaves as RECOMMENDED above.

2.2 A Malicious Web PKI CA
 2.2.1 If a certificate is submitted to a log prior to issuance (a pre-certificate), the (generally) detectable forms of syntactic mis-issuance (Section 1, 1.a) will be detected, and the certificate will not be logged. However, because the CA is presumed to be malicious, the certificate may be issued anyway. Thus checking for syntactic mis-issuance in this case does not, per se, prevent such mis-issuance. However, if clients reject a certificate that lacks (or is not accompanied by) an SCT, this form of mis-issuance will be thwarted in this case.
Again, only if the log behaves as RECOMMENDED above.


Notes:


1. If a CA submits a bogus certificate to one or more logs, but these logs are not watched by a Monitor that is protecting the targeted Subject, CT will not mitigate this type of mis-issuance attack. It is not clear whether every Monitor MUST offer to track every Subject that requests protection. Absent such a guarantee, how do Subjects know which set of Monitors will provide "sufficient" coverage. Of course, if a Subject acts as its own Monitor, this problem is solved for that Subject.
This raises the question of how a Monitor is supposed to know about all the logs, when new ones are added, etc.



5. The combination of a malicious CA and one or more conspiring logs motivates the use of Auditors, to detect conspiring logs. If a Monitor protecting *a* Subject does not see mis-issued certificates, it cannot alert the Subject. If one or *more* SCTs are present in a certificate, or passed via the TLS handshake, a client has no way to know that the logged certificate is not visible to Monitors. Only if clients reject certificates that contains SCTs from conspiring logs will CT be able to deter use of such logs. Thus the means by which Auditors detect such logs, and inform TLS clients must be specified. Moreover, if a certificate (or TLS handshake) contains more than one SCT, the client MUST verify all of them if it is to counter the threat posed by conspiring logs.