Subject: [Trans] changes to attack analysis

From: Stephen Kent <[email-masked]>
Date: Tue, 03 Mar 2015 15:54:44 -0500

based on comments from Ben, I made changes to the attack model text.

The diffs appear below.

Steve
------

*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_If clients do not reject certificates 
or otherwise notify usersIf clients do not reject certificates or 
otherwise notify userswhen 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 _Ifclients _are _donot _required to _reject _a certificate 
that lacks (_certificates or _is not accompanied by) an SCT, or even 
to_otherwisenotify _a user in such situations_users when no SCT is 
provided, the preferred strategy for an attacker _will_is tonot _be 
thwarted in this case_log bogus certificates.(See Note 3.)

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_Untilthere _are no requirements_is a (mandatory to 
implement) specificationfor _such _gossiping, an attack of this sort can 
succeed_based on the current CT design_.__

__

*XX*.2.1

_Since there is no requirement that a _If TLS _client can be configured 
to _clients do not reject _a certificate_certificatesthat _has_donot 
appear to have been syntactically checkedby a log(as indicated by the 
SCT), a malicious CA need not worry about failing a log-based check. 
Similarly, __

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

*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 _If 
clients do not reject _a certificate that lacks (_certificates or _is 
not accompanied by) an _otherwise notify users when no SCTis provided, 
this form of mis-issuance will succeed. (See Note 3.)

*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. A TLS clientsclient that relies on a syntactic checking 
by a log will believe that the certificate has been syntactically 
verifiedin this circumstance.

*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 _If clients do not reject _a 
certificate that lacks (_certificates or _is not accompanied by) an 
_otherwise notify users when no SCT_, there is no motivation_is 
provided, the preferred strategyfor an attacker _to submit the 
certificate in this case_is to not log bogus certificates. (See Note 3.)

*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_Untilthere is _no defined gossip 
protocol_a (mandatory to implement) specification for gossiping, CT 
_does not provide the necessary info_cannot be relied uponto detect this 
form of mis-issuance. (See Note 5 below.)

Notes:

1.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(mandatory to implement) “gossip” protocol that enables Monitors 
to verify that data from logs are reported in a consistent fashion, CT 
does notcannot claim to 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.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 6 Mar 2015 13:57:35 +0000

This is getting quite hard to read as a whole - could you provide the
complete, revised text? Thanks!

If I get it soon, I can try to use it as a basis for a new section in the
I-D before Monday's submission deadline...

Some minor comments below.

On 3 March 2015 at 20:54, Stephen Kent <[email-masked]> wrote:

> 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*If
> clients do not reject certificates or otherwise notify users If 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 *
> If clients *are *do not *required to *reject *a certificate that lacks (*certificates
> or *is not accompanied by) an SCT, or even to*otherwise notify *a user in
> such situations*users when no SCT is provided, the preferred strategy for
> an attacker *will*is to not *be thwarted in this case*log bogus
> certificates. (See Note 3.)
>
>
>
> because it is accompanied by an SCT. In this scenario, unless Monitors
> detected. *Because*Until there *are no requirements*is a (mandatory to
> implement) specification for *such *gossiping, an attack of this sort can
> succeed* based on the current CT design*.
>
>
>
>
>
>
>
>
>
> *XX*.2.1
>
>
>
> *Since there is no requirement that a *If TLS *client can be configured
> to *clients do not reject *a certificate*certificates that *has*do not appear
> to have been syntactically checked by a log (as indicated by the SCT), a
> malicious CA need not worry about failing a log-based check. Similarly,
>
> *since*if 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.
>

I still don't really understand this point: the log has no power to check
syntax that is not also available to a client, so I don't see how the log
checking/not checking syntax is interesting - a malicious CA presumably
cannot know what all clients will do? Because of this, I also still do not
see the real value of logs checking syntax - I am not fundamentally against
it, but it doesn't seem to me to add much.

> certificate. *Since there is no requirement for a TLS client to *If
> clients do not reject *a certificate that lacks (*certificates or *is not
> accompanied by) an *otherwise notify users when no SCT is provided, this
> form of mis-issuance will succeed. (See Note 3.)
>
>
>
> *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. A
> TLS clientsclient that relies on a syntactic checking by a log will
> believe that the certificate has been syntactically verified in this
> circumstance.
>

Again, this seems to me to reduce the value of syntactic checks.

> In this case, Monitors will not detect the bogus certificate. *Since
> there is no requirement for a TLS client to *If clients do not reject *a
> certificate that lacks (*certificates or *is not accompanied by) an *otherwise
> notify users when no SCT*, there is no motivation* is provided, the
> preferred strategy for an attacker *to submit the certificate in this
> case*is to not log bogus certificates. (See Note 3.)
>
>
>
>
>
>
>
> 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.
>
>
>
> Monitors to avoid using such a log, and clients would reject SCTs generated
> by such a log. *Because*Until there is *no defined gossip protocol*a
> (mandatory to implement) specification for gossiping, CT *does not
> provide the necessary info*cannot be relied upon to detect this form of
> mis-issuance. (See Note 5 below.)
>
>
>
> Notes:
>
>
>
> 1.           The combination of a malicious CA and one or more conspiring
> logs motivates the definition of an audit function, to detect conspiring
> 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 (mandatory to implement) “gossip” protocol that enables Monitors
> to verify that data from logs are reported in a consistent fashion, CT does
> notcannot claim to 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.
>

It is not clear to me that gossip has to be mandatory. So long as some
fraction of participants gossip, then clients are protected from
non-targeted attacks. Obviously this does not remove the need to specify
gossip, which is clearly required for CT to fully realise its potential.

Indeed, it is important that gossip is not required to be 100% universal -
if it were, then a single malicious gossiper would break the protocol!
Obviously absent a spec I can't rigorously show how we can avoid that, but
nevertheless, from my and others' informal work on the topic, I am
confident that we can.

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

---

From: Stephen Kent <[email-masked]>
Date: Fri, 06 Mar 2015 11:12:43 -0500

Ben,

Happy to oblige.  The revised text is attached.

As for your comments:

    I still don't really understand this point: the log has no power to
    check syntax that is not also available to a client,

In principle that's true, but in practice we have seen many instances 
where client software
fails to perform checks established by standards. Thus logs represent an 
opportunity to
do a better job (since they are new code) and perhaps help save clients 
from bad code.

    so I don't see how the log checking/not checking syntax is
    interesting - a malicious CA presumably cannot know what all clients
    will do? Because of this, I also still do not see the real value of
    logs checking syntax - I am not fundamentally against it, but it
    doesn't seem to me to add much.

A malicious CA can determine (via testing) which clients, by browser 
type and version,
fail to perform certain syntactic checks. If the CA is creating a bogus 
cert with a
particular set of clients in mind, this may suffice.

    It is not clear to me that gossip has to be mandatory. So long as
    some fraction of participants gossip, then clients are protected
    from non-targeted attacks. Obviously this does not remove the need
    to specify gossip, which is clearly required for CT to fully realise
    its potential.

Remember that IETF standards almost always specify mandatory to 
implement (MTI) features, not
mandatory to use (MTU) features. I believe your comment above supports 
my argument that gossip needs
to be MTI, but not MTU.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Fri, 6 Mar 2015 16:20:58 +0000

> Happy to oblige.  The revised text is attached.

Thanks.

> syntax that is not also available to a client,
>
> so I don't see how the log checking/not checking syntax is interesting - a
> malicious CA presumably cannot know what all clients will do? Because of
> this, I also still do not see the real value of logs checking syntax - I am
> not fundamentally against it, but it doesn't seem to me to add much.
>
>  A malicious CA can determine (via testing) which clients, by browser type
> and version,
Perhaps we need a mechanism analagous to TLS extensions that allow CT logs
to extend their validation and advertise that fact?

>
> Remember that IETF standards almost always specify mandatory to implement
> (MTI) features, not
> mandatory to use (MTU) features. I believe your comment above supports my
> argument that gossip needs
> to be MTI, but not MTU.
>

I am not so sure, but in any case, this is a debate for the gossip RFC.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 6 Mar 2015 18:50:28 +0000

I had a go at incorporating this, but in the process, I realised it is
probably not quite ready yet. I could have a go at editing it myself, but I
will definitely not have time before Monday's deadline.

I suspect more revision is required before it can be incorporated. I have
comments, but they will probably have to wait a while.

I do now have a version that is in xml2rfc format, though - more or less.

---

From: Eran Messeri <[email-masked]>
Date: Sun, 8 Mar 2015 12:48:55 +0000

where client software
opportunity to
from bad code.

Can we put the extra checks logs may do in the CtExtensions field of the
SCT? That way the additional checks can be defined in a separate document.
In principal I agree that providing extra information to TLS clients about
the certificates they receive is useful. Given it's not entirely clear what
clients do with this information (and complicates the log implementation)
my only suggestion is we make this an extension rather than a mandatory
part of the spec.

>
>> so I don't see how the log checking/not checking syntax is interesting -
a malicious CA presumably cannot know what all clients will do? Because of
this, I also still do not see the real value of logs checking syntax - I am
not fundamentally against it, but it doesn't seem to me to add much.
and version,
cert with a
(MTI) features, not

---

From: Stephen Kent <[email-masked]>
Date: Mon, 09 Mar 2015 16:39:57 -0400

Eran,

> ...
> > In principle that's true, but in practice we have seen many 
> instances where client software
> > fails to perform checks established by standards. Thus logs 
> represent an opportunity to
> > do a better job (since they are new code) and perhaps help save 
> clients from bad code.
>
>
> Can we put the extra checks logs may do in the CtExtensions field of 
> the SCT? That way the additional checks can be defined in a separate 
> document.
> In principal I agree that providing extra information to TLS clients 
> about the certificates they receive is useful. Given it's not entirely 
> clear what clients do with this information (and complicates the log 
> implementation) my only suggestion is we make this an extension rather 
> than a mandatory part of the spec.
>
I identified two reasons for including cert type assertion in the log 
request and
adding that plus cert syntactic validation results in the SCT. One, 
noted above,
is that many TLS clients have, historically, not done a good job of cert 
syntax checking,
and this represents an opportunity to help improve that situation. 
Second, the current
(and previous) text is vague  about what checks a log does perform when 
performing
cert path validation. Using the cert type assertion and allowing a log 
to advertise
what types of checks it performs (based on IANA-registered values) 
removes this ambiguity
for submitters.

I think the cert type marking and checking info should be included in 
the base spec, if only to
address the second problem

Steve

---

From: Rob Stradling <[email-masked]>
Date: Mon, 09 Mar 2015 23:12:16 +0000

>> the SCT? That way the additional checks can be defined in a separate
<snip>
> the base spec, if only to address the second problem

+1 to Eran's suggestion of using the CtExtensions field, regardless of 
whether Steve's proposed cert compliance checks are included in the base 
spec or a separate document.  I can't think of any better place (than 
CtExtensions) in which to put optional fields into an SCT.

Incidentally, +1 to Steve's recent comment...
"The description of the extensions field seems to be inspired by X.509v3.
That's OK, but one needs to define a top-level format for extensions to
ensure backward compatibility (as per v3 extensions)to make this work.
That level of specification is missing here."

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Stephen Kent <[email-masked]>
Date: Wed, 11 Mar 2015 11:38:54 -0400

Rob,
> whether Steve's proposed cert compliance checks are included in the 
> base spec or a separate document.  I can't think of any better place 
> (than CtExtensions) in which to put optional fields into an SCT.
I'm arguing that there must be a way to a log to advertise what checks 
it performs when
it does cert path validation to one of the trust anchors that it 
advertises. This should
not be optional.

But, I agree that this does not require a submitter to assert a cert type.
However, there still seems to be considerable benefit to having the SCT 
declare
to a client what cert path validation was performed as part of log 
acceptance.
> That level of specification is missing here."
thanks.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Thu, 12 Mar 2015 10:43:48 -0400

Ben,
>
>
> ...
>
>     A malicious CA can determine (via testing) which clients, by
>     browser type and version,
>     fail to perform certain syntactic checks. If the CA is creating a
>     bogus cert with a
>         It is not clear to me that gossip has to be mandatory. So long
>         as some fraction of participants gossip, then clients are
>         protected from non-targeted attacks. Obviously this does not
>         remove the need to specify gossip, which is clearly required
>         for CT to fully realise its potential.
>
>
> Perhaps we need a mechanism analagous to TLS extensions that allow CT 
> logs to extend their validation and advertise that fact?
I don't see how your comment relates to the discussion above. 
Nonetheless, I note that there
is a proposed mechanism to embed this info in the SCT, along with the 
mechanism by which a submitter
declares the type of cert being submitted (relative to IANA-registered 
validation criteria).
I envisioned using this in case logs elect to perform cert validation 
relative to profiles
such as the CABF DV and EV cert specs. But, one might consider using it 
to inform consumers
of SCTs of the cert path validation performed by a log.

Steve