Subject: Re: [Trans] updated attack analysis

From: Ben Laurie <[email-masked]>
Date: Thu, 5 Feb 2015 13:07:15 +0000

On 22 January 2015 at 16:48, Stephen Kent <[email-masked]> wrote:

>  updated to reflect dropping TLS client behavior specs, no gossip protocol
> yet defined,
> and no stand-alone Auditors.
>
> comments welcome, but I'm abut to head off on vacation, so I won't be able
> to respond immediately
>
> Steve
>  ------
>
> *XX*. Attack Model and Discussion of Detection and Mitigation Options
>
>
>
> Certificate mis-issuance may arise in one of several ways. The ways that
> CT enables a Subject (or others) to detect and redress mis-issuance depends
> on the context and the entities involved in the mis-issuance. This attack
> model applies to the Web PKI context. If CT is applied to other contexts,
> each will require its own attack model, although most of the model
> described here is likely to be applicable.
>
>
>
> Certificates are issued by CAs, so the top level differentiation is
> whether the CA that mis-issued a certificate did so maliciously or not. If
> not, then the next point of differentiation is whether the mis-issuance was
> the result of an error, an attack, or malicious behavior by a CA. In the
> case of an attack or malicious behavior by a CA, it is necessary to
> consider whether the certificate was logged. If the certificate was logged,
> it is necessary to consider whether the log(s) may have conspired with the
> attacker. Finally, one must consider the possibility that a third party
> Monitor might collude with an attacker (or a malicious CA). Here’s an
> taxonomy of attacks and assumptions about the attack environment:
>
> 1. CA
>
> a. Non-malicious CA
>
>                                                                         i.
> Error
>
>                                                                      ii.
> Attack victim
>
> 1. Certificate logged
>
> a. Benign log
>
>
> i.   Self-monitor
>
>
>                                               ii.   Benign 3rd party
> Monitor
>
>
>                                             iii.   Conspiring 3rd party
> Monitor
>
> b. Conspiring log
>
> 2. Certificate not logged
>
> b. Malicious CA
>
>                                                                i.   Certificate
> logged
>
> 1. Benign log
>
> a. Self-monitor
>
> b. Benign 3rd party Monitor
>
> c. Conspiring 3rd party Monitor
>
> 2. Conspiring log
>
>                                         ii.   Certificate not logged
>
>
>
>
>
> The following sections examine each of these cases, for both syntactic and
> semantic mis-issuance. As noted above, the focus here is on the Web PKI
> context, although most of the analysis is applicable to other PKI contexts.
>
>
>
>
>
> *XX*.1 Non-malicious Web PKI CA context
>
>
>
> If a pre-certificate is submitted to a log, prior to issuance of a
> certificate, syntactic mis-issuance can (optionally) be detected, and
> noted. This will happen only if the log performs syntactic checks in
> general, and if the log is capable of performing the checks applicable to
> the submitted (pre-) certificate. (A pre-certificate will be logged even if
> it fails syntactic validation, thus logging takes precedence over detection
> of syntactic mis-issuance.) If syntactic validation fails, this will be
> noted in the SCT returned to the CA. Because this case assumes a
> non-malicious CA, the CA will remedy the syntactic problem and re-submit
> the pre-certificate to a log. In this case syntactic checking by a log
> helps avoid issuance of a malformed certificate.
>
>
>
> If a certificate is submitted by its Subject, we assume that the Subject
> will contact the issuer and request a new certificate if a log indicates
> that the certificate failed the applicable syntactic check. Here too
> syntactic checking by a log enables a Subject to be informed that its
> certificate is malformed and thus may hasten issuance of a replacement
> certificate.
>
>
>
> If the certificate was submitted by a third party, that party might
> contact the Subject or the issuer, but because the party is not the Subject
> of the certificate it is not clear how the issuer will respond.
>
>
>
> Bottom line: Syntactic mis-issuance of a certificate can be avoided by a
> CA if it makes use of logs that are capable of performing these checks for
> the types of certificates that are submitted, and if the CA acts on the
> feedback it receives. If a CA uses a log that does not perform such checks,
> or if the CA requests checking relative to criteria not supported by the
> log, then syntactic mis-issuance will not be detected or avoided by this
> mechanism. Syntactic mis-issuance can be remedied if a Subject submits a
> certificate to a log that performs syntactic checks, and if the Subject
> requests the issuer to fix problems detected by the log. (The issuer is
> presumed to be willing to re-issue the certificate, correcting any
> problems, because the CA is not malicious.)
>

Note that there's nothing special about the log here: anyone can detect
syntactic mis-issuance by simply feeding the certificate to an appropriate
tool.

>
>
> *XX*.1.1 A CA may issue the certificate to an unauthorized party
> (semantic mis-issuance), as a result of an error or because it was the
> victim of a social engineering attack.
>
We will refer to such a certificate as “bogus”. In this case the CA has a
> record of the bogus certificate and it is prepared to revoke the bogus
> certificate once it has confirmed its error. If the CA is submitting (pre-)
> certificates for logging, there will be evidence of the mis-issuance in one
> or more logs. If a Monitor is “protecting” the affected Subject, it will
> detect the mis-issuance, and will alert the Subject. Because the CA has a
> record of the mis-issuance, it should be able to revoke the bogus
> certificate, after investigating, based on the information provided by the
> legitimate certificate Subject. The presence of an embedded SCT in the
> bogus certificate, or an SCT accompanying the bogus certificate is
> irrelevant to the mitigation procedure in this case. (See Note 1 below.)
> Because the mis-issuance was not malicious, there is no notion of a log
> operator or a Monitor conspiring with the CA.
>

>
> *XX*.1.2 A non-malicious Web PKI CA may be the victim of an undetected
> attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance of a
> certificate. In this case the CA is not aware of the mis-issuance and may
> have no record of the certificate content.
>
>
>
> *XX*.1.2.1 The mis-issued certificate may have been submitted to one or
> more logs prior to issuance, to acquire an embedded SCT, or post-issuance
> to acquire a standalone SCT. In either case, a Monitor that is protecting
> the targeted Subject will detect the bogus certificate and can alert the
> Subject. The Subject, in turn, will request the CA to revoke the bogus
> certificate. In this case, the CA will make use of the log entry (supplied
> by the Subject) to determine the serial number of the mis-issued
> certificate, and revoke it (after investigation). (See Notes 1 + 2.) *Since
> there is no requirement for a TLS client to reject a certificate when no
> SCT is provided, the preferred strategy for an attacker is to not log bogus
> certificates*. (See XX.1.2.2 and Note 3.)
>

The lack of a requirement for rejection does not mean that popular TLS
clients will not reject. As you know, Chrome will shortly stop showing EV
indicators for EV certs without valid SCTs, even though there is no
requirement to do so.

It seems to me a more accurate analysis would be along the lines of:

*"If TLS clients do not reject certificates or otherwise notify users when
no SCT is provided, the preferred strategy for an attacker is to not log
bogus certificates*. (See XX.1.2.2 and Note 3.)."

>
>
> *XX*.1.2.2 The bogus certificate may not have been submitted to any logs.
> In this case, Monitors will not detect the bogus certificate. *Since TLS
> clients are not required to reject a certificate that lacks (or is not
> accompanied by) an SCT, or even to notify a user in such situations, the
> attacker will not be thwarted in this case.* (See Note 3.)
>

See above.

>
>
> XX.1.2.3 The bogus certificate may have been submitted to logs that are
> conspiring with the attacker. In this case, Monitors will not detect the
> bogus certificate because the logs will suppress a bogus certificate log
> entry. TLS clients will not reject a bogus certificate in this case,
> because it is accompanied by an SCT. In this scenario, unless Monitors
> “gossip” to detect conspiring logs, the bogus certificate will not be
> detected. *Because there are no requirements for such gossiping, an
> attack of this sort can succeed based on the current CT design.*
>

Again, lack of requirement does not imply lack of implementation. Again, I
would suggest this should be phrased conditionally.

>
>
> XX.1.2.4 If a semantically bogus certificate is submitted to
> non-conspiring logs, a Subject performing self-monitoring will be able to
> detect the bogus certificate and request revocation.
>

Not sure of the relevance of "non-conspiring" here?

> If a Subject relies on a third-party Monitor, and that Monitor conspires
> with the attacker, the Subject will not be alerted and thus will not
> request revocation.
>
>
>
>
>
> *XX*.2 Malicious Web PKI CA context
>
>
>
> *XX*.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log,
> syntactic mis-issuance can be detected, and noted. This will happen only if
> the log performs syntactic checks in general, and if the log is capable of
> performing the checks applicable to the submitted certificate. A (pre-)
> certificate will be logged even if it fails syntactic validation, thus
> logging takes precedence over detection of syntactic mis-issuance.
>
>
>
> Because the CA is presumed to be malicious, the CA may cause the log to
> not perform checks, in one of several ways.
>
> 1.           The CA may assert that the certificate is being issued w/o
> regard to any guidelines (the “no guidelines” reserved CCID).
>
> 2.           The CA may assert a CCID that has not been registered, and
> thus no log will be able to perform a check.
>
> 3.           the CA may check to see which CCIDs a log declares it can
> check, and chose a registered CCID that is not checked by the log in
> question. In this fashion the CA can prevent the log from performing
> checks, and the SCT and log entry will not contain an indication of a
> failed check.
>
> 4.           The CA may submit a (pre-) certificate to a log that is
> known to not perform any syntactic checks, and thus avoid syntactic
> checking.
>
>
>
> *Since there is no requirement that a TLS client can be configured to
> reject a certificate that has not been syntactically checked (as indicated
> by the SCT), a malicious CA need not worry about failing a log-based check.
> Similarly, *
>
> *since there is no requirement for a TLS client to reject a certificate
> that was logged by an operator that does not perform syntactic checks, the
> fourth approach noted above will succeed as well*. If a client were
> configured to know which versions of certificate types are applicable to
> its use of a certificate, the second and third strategies noted above could
> be thwarted.
>

Again, the log has no special role to play in the detection of syntactic
errors: TLS clients that wish to reject such certificates can do so
unaided. Indeed, I would've thought conformance to existing RFCs would
imply such behaviour - and if they don't, surely CT is not the place to fix
that?

>
>
> *XX*.2.2 Because the CA is presumed malicious, it may choose to not
> submit a certificate to a log. This avoids detection of syntactic
> mis-issuance by a log, but it also means there is no SCT for the
> certificate. *Since there is no requirement for a TLS client to reject a
> certificate that lacks (or is not accompanied by) an SCT, this form of
> mis-issuance will succeed. (See Note 3.)*
>

See above (both on requirements and on CT's role in syntax).

>
>
> *XX*.2.3 A malicious CA may submit a certificate to one or more logs that
> collude with this CA to not perform syntactic checks, even though they
> claim to do so. In this case syntactic mis-issuance will not be detected by
> logs.  The log entry and the SCT for a syntactically invalid certificate
> will assert that the certificate syntax was verified. Unless Monitors also
> perform syntactic checks, this form of mis-issuance will not be thwarted.
> TLS clients will believe that the certificate has been syntactically
> verified.
>

Why would they believe that, given there's no requirement to do such
verification?

>
>
> *XX*.2.4 A malicious CA may semantically mis-issue a certificate that is
> syntactically valid. Because it is syntactically valid, logs will not mark
> the bogus certificate as failing a syntax check. The semantically bogus
> certificate may have been issued because the CA was bribed or was compelled
> to issue the certificate. (A CA might be compelled to issue a bogus
> certificate by a government agency or a criminal organization.)  This CA
> might be one or more tiers below a trust anchor (aka root CA).
>
>
>
> *XX*.2.4.1 A bogus certificate may not have been submitted to any logs.
> In this case, Monitors will not detect the bogus certificate. *Since
> there is no requirement for a TLS client to reject a certificate that lacks
> (or is not accompanied by) an SCT, there is no motivation for an attacker
> to submit the certificate in this case. (See Note 3.)*
>

See above.

>
>
> *XX*.2.4.2 A bogus pre-certificate may have been submitted to one or more
> logs, to acquire an embedded SCT, a certificate may have been submitted
> post-issuance (to acquire a standalone SCT). In either case, a
> (non-conspiring) Monitor protecting the targeted Subject will detect a
> bogus certificate and alert that Subject. The Subject, in turn, will
> request the CA to revoke the bogus certificate. In this case, the CA may
> refuse, or substantially delay, to revoke the bogus certificate. It could
> make excuses about inadequate proof that the certificate is bogus, or argue
> that it cannot quickly revoke the certificate because of local, legal
> concerns, etc. In this case, the CT mechanisms have detected mis-issuance,
> but the information logged by CT does not help remedy the problem. (See
> Note 4.)
>
>
>
> *XX*.2.4.3 If a third-party Monitor conspires with the malicious CA, then
> it will not notify the targeted Subject when a bogus certificate is logged.
> If a Subject performs self-monitoring this sort of attack will be avoided.
>
>
>
> *XX*.2.5 A bogus certificate may have been submitted to one or more
> conspiring logs. These logs will issue SCTs, but will hide the log entries
> from some or all Monitors. Any Monitor (even a self-Monitor) from which the
> log is hiding data will not detect the bogus certificate, even if it is
> trying to protect the targeted Subject. If a client accepts an SCT from a
> conspiring log, then the client will not reject the bogus certificate on
> the basis of a missing SCT. In this case CT will not detect the bogus
> certificate.
>
>
>
> The audit function is intended to detect logs that conspire to suppress
> log entries, based on consistency checking of logs and use of a “gossip”
> protocol. It is assumed that Monitors will perform the audit functions
> described in Section <*insert #*>.
>
> A Monitor performing an audit function could alert its clients if the
> Monitor detects evidence of malfeasant log operation. This would cause
> Monitors to avoid using such a log, and clients would reject SCTs generated
> by such a log. *Because there is no defined gossip protocol, CT does not
> provide the necessary info to detect this form of mis-issuance. *(See
> Note 5 below.)
>
>
>
> 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? If a Subject acts as its own
> Monitor, this problem is solved for that Subject. It also is not clear how
> a Monitor becomes aware of all (relevant?) logs, including newly created
> logs. The means by which Monitors become aware of new logs MUST accommodate
> self-monitoring by a potentially very large number of web site operators.
>
>
>
> 2. A CA being presented with evidence of a bogus certificate, in the form
> of a log entry, will need to examine its records to determine if it has
> knowledge of the certificate in question. It also will likely require the
> targeted Subject to provide assurances that it is the authorized entity
> representing the Subject name (subjectAltname) in question. Thus a Subject
> should not expect immediate revocation of a contested certificate. The time
> frame in which a CA will respond to a revocation request usually is
> described in the CPS for the CA. Other certificate fields and extensions
> may be of interest for forensic purposes, but are not required to effect
> revocation nor to verify that the certificate to be revoked is bogus, based
> on applicable criteria. The SCT and log entry, because each contains a
> timestamp from a third party, is probably valuable for forensic purposes
> (assuming a non-conspiring log operator).
>
>
>
> 3. If a TLS client were to reject a certificate that lacks an embedded
> SCT, or is not accompanied by an SCT transported via the TLS handshake,
> this behavior needs to be defined in a way that is compatible with
> incremental deployment. Issuing a warning to a (human) user is probably
> insufficient, based on experience with warnings displayed for expired
> certificates, lack of certificate revocation status information, and
> similar errors that violate RFC 5280 path validation rules. *Until a
> mechanism is defined that accommodates incremental deployment of this
> capability, attackers probably will avoid submitting bogus certificates to
> (non-conspiring) logs as a means of evading detection.*
>
>
>
> 4. A targeted Subject might request the parent of a malicious CA to
> revoke the certificate of the non-cooperative CA. However, a request of
> this sort may be rejected, e.g., because of the potential for significant
> collateral damage. A browser might be configured to reject all certificates
> issued by the malicious CA, e.g., using a CA hot list distributed by a
> browser vendor. However, if the malicious CA has a sufficient number of
> legitimate clients, treating all of them as bogus still represents serious
> collateral damage. If this specification were to require that a browser can
> be configured to reject a specific, bogus certificate identified by a
> Monitor, then the bogus certificate could be rejected in that fashion. This
> mitigation strategy calls for communication between Monitors and browsers,
> or between Monitors and browser vendors. Such communication has not been
> specified, i.e., there are no standard ways to configure a browser to
> reject individual bogus certificates based on info provided by an external
> entity such as a Monitor. Moreover, the same or another malicious CA could
> issue new bogus certificates for the targeted Subject, which would have to
> be detected and rejected in this (as yet unspecified) fashion. Thus, for
> now, CT does not seem to provide a way to mitigate this form of attack,
> even though it provides a basis for detecting such attacks.
>
>
>
> 5. The combination of a malicious CA and one or more conspiring logs
> motivates the definition of an audit function, to detect conspiring logs.
> If a Monitor protecting s 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 Monitors and clients
> reject certificates that contains SCTs from conspiring logs (based on info
> from an audit) will CT be able to deter use of such logs. Thus the means by
> which a Monitor performing an audit function detect such logs, and inform
> TLS clients must be specified for this to be effective. Moreover, if a
> certificate (or TLS handshake) contains more than one SCT, unless the
> client verifies all of them if it is to counter the threat posed by
> conspiring logs.
>
>
>
> Absent a “gossip” protocol that enables Monitors to verify that data from
> logs are reported in a consistent fashion, CT does not provide protection
> against logs that may conspire with, or are victims of, attackers effecting
> certificate mis-issuance. When a gossip protocol is defined and deployed,
> it will be necessary to describe how the CT system will deal with a
> mis-behaving or compromised log. For example, will there be a mechanism to
> alert all TLS clients to reject SCTs issued by such a log? Absent a
> description of a mitigation strategy to deal with mis-behaving or
> compromised logs, CT cannot ensure detection of mis-issuance.
>
>
>
> Monitors play a critical role in detecting semantic certificate
> mis-issuance, for Subjects that have requested monitoring of their
> certificates. A monitor (including a Subject performing self-monitoring)
> examines logs for certificates associated with one or more Subjects. It
> must obtain a list valid certificates for the Subject being monitored, in a
> secure manner.
>
> Note:  A Monitor must not rely on a CA or RA database for this
> information or use certificate discovery protocols; this information must
> be acquired by the Monitor based on reference certificates provided by a
> Subject. If a Monitor were to rely on a CA or RA database (for the CA that
> issued a targeted certificate), the Monitor would not detect mis-issuance
> due to malfeasance on the part of that CA or the RA, or due to compromise
> of the CA or the RA.  If a CA or RA database is used, it does detect
> mis-issuance by an unauthorized CA.  A Monitor must not rely on certificate
> discovery mechanisms to build the list of valid certificates since such
> mechanisms might result in mis-issued certificates being added to the list.
>
>
>
> As noted above, Monitors represent another target for adversaries who wish
> to effect certificate mis-issuance. If a Monitor is compromised by, or
> conspires with, an attacker, it will fail to alert a Subject to a
> mis-issued certificate targeting that Subject, as noted above. It is
> RECOMMENDED that a Subject request certificate monitoring from multiple
> sources to guard against such failures. Operation of a Monitor by a
> Subject, on its own behalf, avoids dependence on third party Monitors.
> However, the burden of Monitor operation may be viewed as too great for
> many web sites, and thus this mode of operation ought not be assumed to be
> universal when evaluating protection against Monitor compromise.
>
>
>
> A final note: Now that certificate pinning has been approved as a standard
> (currently in the RFC Editor’s queue), it is appropriate to factor in its
> use by TLS clients. It would appear that pinning will dramatically reduce
> the set of TLS clients that are vulnerable to mis-issuance; a client that
> pins a certificate for a web site would reject a bogus certificate without
> use of any CT mechanisms. The security considerations section of 6962-bis
> needs to note this, since deployment of pinning appears to reduces the need
> for CT in the Web PKI context.
>

It is Google's view that pinning is not a scalable solution, unlike CT. We
do not agree that pinning reduces the need for CT.

---

From: Karen Seo <[email-masked]>
Date: Mon, 16 Feb 2015 18:39:21 -0500

Folks,

I've found the discussion on the list and the analysis itself helpful in 
clarifying and assessing the aims and mechanisms 6962-bis.  It strikes 
me that it would be similarly helpful to other users/readers of 
6962-bis.  What does the group think of adding it to 6962-bis?

Thank you,
Karen

---

From: Santosh Chokhani <[email-masked]>
Date: Tue, 17 Feb 2015 13:55:13 +0000

Karen,

This is a good idea.  We need the threat analysis to document the assumptions under which the mechanisms are effective and what the residual vulnerabilities are.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Karen Seo
Sent: Monday, February 16, 2015 6:39 PM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Trans] updated attack analysis

Folks,

I've found the discussion on the list and the analysis itself helpful in clarifying and assessing the aims and mechanisms 6962-bis.  It strikes me that it would be similarly helpful to other users/readers of 6962-bis.  What does the group think of adding it to 6962-bis?

Thank you,
Karen

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

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Feb 2015 15:21:36 +0000

On 16 February 2015 at 23:39, Karen Seo <[email-masked]> wrote:
> clarifying and assessing the aims and mechanisms 6962-bis.  It strikes me
> that it would be similarly helpful to other users/readers of 6962-bis.  What
> does the group think of adding it to 6962-bis?

As I indicated in my previous message, it needs some work before it
could be added. However, I do think it is a useful starting point.

---

From: Karen Seo <[email-masked]>
Date: Tue, 17 Feb 2015 13:29:06 -0500

Santosh,

Thank you for the encouragement.

Karen

---

From: Karen Seo <[email-masked]>
Date: Tue, 17 Feb 2015 13:49:58 -0500

I see what you mean. Thank you.

---

From: Karen Seo <[email-masked]>
Date: Tue, 17 Feb 2015 14:04:37 -0500

Folks,

Sorry if my message implied that I thought the text was in its final 
form. I agree that there is not yet consensus on the text/topic and that 
further work is needed. However, if the working group agrees that the 
threat analysis should be added to 6962, then I believe it would be more 
expedient if the text were incorporated into 6962-bis sooner rather than 
later.  Anyone who reviews 6962-bis will then likely review this text, 
increasing the number of eyes on it.  And having the threat analysis in 
the draft will hopefully facilitate its use in ensuring that the 
document is consistent/correct/complete.  Perhaps we could incorporate 
the next revision of the text with any remaining unresolved comments 
placed in the issue tracker?  What do folks think?

Karen

---

From: Ben Laurie <[email-masked]>
Date: Wed, 18 Feb 2015 16:24:52 +0000

On 17 February 2015 at 19:04, Karen Seo <[email-masked]> wrote:
> Folks,
>
> Sorry if my message implied that I thought the text was in its final form. I
> agree that there is not yet consensus on the text/topic and that further
> work is needed. However, if the working group agrees that the threat
> analysis should be added to 6962, then I believe it would be more expedient
> if the text were incorporated into 6962-bis sooner rather than later.
> Anyone who reviews 6962-bis will then likely review this text, increasing
> the number of eyes on it.  And having the threat analysis in the draft will
> hopefully facilitate its use in ensuring that the document is
> consistent/correct/complete.  Perhaps we could incorporate the next revision
> of the text with any remaining unresolved comments placed in the issue
> tracker?  What do folks think?

I would happily use it as a starting point for text in 6962-bis, but I
would feel compelled to remove text that attempts to force issues
which the WG has already decided to defer to later documents (such as
the definition of a gossip protocol), or has decided it does not have
jurisdiction over (such as client behaviour).

---

From: Santosh Chokhani <[email-masked]>
Date: Wed, 18 Feb 2015 18:36:14 +0000

Ben,

The document at least should describe what the residual vulnerability is if the client does not take appropriate/recommended action.

-----Original Message-----
From: Trans [mailto:[email-masked]] On Behalf Of Ben Laurie
Sent: Wednesday, February 18, 2015 11:25 AM
To: Karen Seo
Cc: [email-masked]
Subject: Re: [Trans] updated attack analysis

On 17 February 2015 at 19:04, Karen Seo <[email-masked]> wrote:
> form. I agree that there is not yet consensus on the text/topic and 
> that further work is needed. However, if the working group agrees that 
> the threat analysis should be added to 6962, then I believe it would 
> be more expedient if the text were incorporated into 6962-bis sooner rather than later.
> Anyone who reviews 6962-bis will then likely review this text, 
> increasing the number of eyes on it.  And having the threat analysis 
> in the draft will hopefully facilitate its use in ensuring that the 

I would happily use it as a starting point for text in 6962-bis, but I would feel compelled to remove text that attempts to force issues which the WG has already decided to defer to later documents (such as the definition of a gossip protocol), or has decided it does not have jurisdiction over (such as client behaviour).

---

From: Ben Laurie <[email-masked]>
Date: Wed, 18 Feb 2015 18:50:19 +0000

> The document at least should describe what the residual vulnerability is if the client does not take appropriate/recommended action.

I agree, and that is what I suggested in my response...

---

From: Rob Stradling <[email-masked]>
Date: Wed, 18 Feb 2015 21:07:11 +0000

> I agree, and that is what I suggested in my response...

That sounds like this ticket...

http://trac.tools.ietf.org/wg/trans/trac/ticket/55

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online
Office Tel: +44.(0)1274.730505
Office Fax: +44.(0)1274.730909
www.comodo.com

COMODO CA Limited, Registered in England No. 04058690
Registered Office:
   3rd Floor, 26 Office Village, Exchange Quay,
   Trafford Road, Salford, Manchester M5 3EQ

This e-mail and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed.  If you have received this email in error please notify the 
sender by replying to the e-mail containing this attachment. Replies to 
this email may be monitored by COMODO for operational or business 
reasons. Whilst every endeavour is taken to ensure that e-mails are free 
from viruses, no liability can be accepted and the recipient is 
requested to use their own virus checking software.

---

From: Karen Seo <[email-masked]>
Date: Fri, 20 Feb 2015 20:02:17 -0500

Thanks, Rob.

Ben, Rob, Santosh,

I think we're in agreement but just in case.... I agree with Santosh and 
would like to extend that principle. I think that to ensure that it's 
clear to the readers/users of this technology what vulnerabilities it 
covers and what it doesn't, the document needs to include the entire 
attack/threat taxonomy.  Re: your concern about including 
topics/mitigations that the WG has agreed are out of scope, all attacks 
should be included but the document should describe the WG consensus on 
what mitigation is provided (or is not) by 6962, and what the residual 
vulnerabilities are. In the case of client behavior, if the WG decides 
(as described in Ticket 55) to specify but not mandate checks that a 
client could do, then the relevant section of the analysis would state 
this and indicate the residual vulnerabilities.  I admit I'm not sure 
what would then be put into the Security Considerations section, perhaps 
a brief summary and pointers to the relevant sections of the attack 
analysis.  Per BCP 72, the Security Considerations Section MUST describe 
which attacks are out of scope (and why), which attacks are in-scope, etc.

Karen

On 2/18/15 4:07 PM, Rob Stradling wrote:
>>> The document at least should describe what the residual 
>>> vulnerability is if the client does not take appropriate/recommended 
>>> action.
>>
>>> I would happily use it as a starting point for text in 6962-bis, but 
>>> I would feel compelled to remove text that attempts to force issues 
>>> which the WG has already decided to defer to later documents (such 
>>> as the definition of a gossip protocol), or has decided it does not 
>>> have jurisdiction over (such as client behaviour).
>>>

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Feb 2015 15:41:16 -0500

Ben,
> On 17 February 2015 at 19:04, Karen Seo<[email-masked]>  wrote:
>> Folks,
>>
> jurisdiction over (such as client behaviour)

The WG can elect to move a discussion of client behavior and gossip
protocols into separate docs. That's a good approach to keeping
each do a reasonable size. But, a security analysis of CT needs to
provide a taxonomy of attacks, explore the implications of failures
or compromises of different system elements, and describe residual
vulnerabilities based on what is and is not mandated by the specs.
Thus, by deferring specs for other elements of the system, the analysis
will, of necessity, identify more residual vulnerabilities.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 26 Feb 2015 15:41:22 -0500

Ben,

Thanks for the feedback on my attack analysis text. I will make some 
changes based on
your comments.

> Note that there's nothing special about the log here: anyone can 
> detect syntactic mis-issuance by simply feeding the certificate to an 
> appropriate tool.
I agree. But, if a log elects to offer this service, the results of the 
check visible to all clients
(e.g., TLS and Monitors) and that has two useful benefits. Also, even if 
a log does not perform a
syntax check, the fact that a submitter asserted the type of cert being 
logged is useful to TLS clients,
and maybe to Monitors and the Audit function.
> clients will not reject. As you know, Chrome will shortly stop showing 
> EV indicators for EV certs without valid SCTs, even though there is no 
> requirement to do so.
>
> _"If TLS clients do not reject certificates or otherwise notify users 
> when no SCT is provided, the preferred strategy for an attacker is to 
> not log bogus certificates_. (See XX.1.2.2 and Note 3.)."
I agree with your suggested text change.
>
>     *XX*.1.2.2 The bogus certificate may not have been submitted to
>     any logs. In this case, Monitors will not detect the bogus
>     certificate. _Since TLS clients are not required to reject a
>     certificate that lacks (or is not accompanied by) an SCT, or even
>     to notify a user in such situations, the attacker will not be
>     thwarted in this case._ (See Note 3.)
>
ibid.
>
>     XX.1.2.3 The bogus certificate may have been submitted to logs
>     that are conspiring with the attacker. In this case, Monitors will
>     not detect the bogus certificate because the logs will suppress a
>     bogus certificate log entry. TLS clients will not reject a bogus
>     certificate in this case, because it is accompanied by an SCT. In
>     this scenario, unless Monitors “gossip” to detect conspiring logs,
>     the bogus certificate will not be detected. _Because there are no
>     requirements for such gossiping, an attack of this sort can
>     succeed based on the current CT design._
>
>
> Again, lack of requirement does not imply lack of implementation. 
> Again, I would suggest this should be phrased conditionally.
In the context of a standard, one OUGHT NOT (as per 6919) rely on client 
behavior that is not mandated.
I could re-phrase this, but there is a bigger issue lurking here. If 
mandated client behavior is
out of scope for 6269-bis, i.e., if the doc focuses only on the 
operation of logs, then I believe
the doc cannot be evaluated (and thus approved by the WG) until 
ancillary docs specifying client
behavior have been completed. My argument is that we don't know if the 
spec for log operation
is complete and correct until we know what log clients will do based on 
interactions with a log,
processing of SCTs, etc.
>     __
>     non-conspiring logs, a Subject performing self-monitoring will be
>     able to detect the bogus certificate and request revocation.
>
>
If logs conspire with a CA, they may not report a log entry for a bogus 
cert to an affected subject.
>
>     _Since there is no requirement that a TLS client can be configured
>     to reject a certificate that has not been syntactically checked
>     (as indicated by the SCT), a malicious CA need not worry about
>     failing a log-based check. Similarly, _
>
>     _since there is no requirement for a TLS client to reject a
>     certificate that was logged by an operator that does not perform
>     syntactic checks, the fourth approach noted above will succeed as
>     well_. If a client were configured to know which versions of
>     certificate types are applicable to its use of a certificate, the
>     second and third strategies noted above could be thwarted.
>
>
> Again, the log has no special role to play in the detection of 
> syntactic errors: TLS clients that wish to reject such certificates 
> can do so unaided. Indeed, I would've thought conformance to existing 
> RFCs would imply such behaviour - and if they don't, surely CT is not 
> the place to fix that?
I noted above why syntax checking by logs is beneficial. Experience 
shows that a number of TLS clients
have been very bad about checking certs relative to existing RFCs, so 
having such checks offered
by logs is beneficial for that reason too. CT is supposed to create an 
infrastructure that helps
detect/deter issuance of "mis-issued" certs?  Syntactically broken certs 
are mis-issued, relative
to a specified cert profile, whether that DV, EV, S/MIME, or whatever.

>     *XX*.2.2 Because the CA is presumed malicious, it may choose to
>     not submit a certificate to a log. This avoids detection of
>     syntactic mis-issuance by a log, but it also means there is no SCT
>     for the certificate. _Since there is no requirement for a TLS
>     client to reject a certificate that lacks (or is not accompanied
>     by) an SCT, this form of mis-issuance will succeed. (See Note 3.)_
>
>
see my (distinct) replies to you comments above.
>
>     *XX*.2.3 A malicious CA may submit a certificate to one or more
>     logs that collude with this CA to not perform syntactic checks,
>     even though they claim to do so. In this case syntactic
>     mis-issuance will not be detected by logs. The log entry and the
>     SCT for a syntactically invalid certificate will assert that the
>     certificate syntax was verified. Unless Monitors also perform
>     syntactic checks, this form of mis-issuance will not be thwarted.
>     TLS clients will believe that the certificate has been
>     syntactically verified.
>
>
Since there appear to be NO TLS client requirements today :-).

As I mentioned earlier, until we have a complete set of specs for client 
behavior, TLS
clients and Monitors, we can't have high confidence that the CT log spec 
is right.
>
>
>     ***XX*.2.4.1 A bogus certificate may not have been submitted to
>     any logs. In this case, Monitors will not detect the bogus
>     certificate. _Since there is no requirement for a TLS client to
>     reject a certificate that lacks (or is not accompanied by) an SCT,
>     there is no motivation for an attacker to submit the certificate
>     in this case. (See Note 3.)_
>
>
> See above.
I'll change this to be consistent with the text change you noted earlier.
>
>     A final note: Now that certificate pinning has been approved as a
>     standard (currently in the RFC Editor’s queue), it is appropriate
>     to factor in its use by TLS clients. It would appear that pinning
>     will dramatically reduce the set of TLS clients that are
>     vulnerable to mis-issuance; a client that pins a certificate for a
>     web site would reject a bogus certificate without use of any CT
>     mechanisms. The security considerations section of 6962-bis needs
>     to note this, since deployment of pinning appears to reduces the
>     need for CT in the Web PKI context.
>
>
> It is Google's view that pinning is not a scalable solution, unlike 
> CT. We do not agree that pinning reduces the need for CT.
Well, some part of Google obviously believes pinning is a useful 
solution, since all three editors for
the pinning spec are from Google :-).

More to the point, we're developing an IETF RFC; Google's "view" is just 
one input. Thus your
very terse reply is not a basis for failing to address this obvious issue.

Steve