Ben,
Thanks for the feedback on my attack analysis text. I will make some
changes based on
your comments.
*XX*.1 Non-malicious Web PKI CA context
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.
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.)."
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.
__
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 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 above (both on requirements and on CT's role in syntax).
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.
Why would they believe that, given there's no requirement to do such
verification?
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
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
