[Trans] Comments on draft-ietf-trans-threat-analysis-12.txt

Eric Rescorla <ekr@rtfm.com> Sun, 12 November 2017 04:25 UTC

MIME-Version: 1.0
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 12 Nov 2017 04:24:47 +0000
Message-ID: <CABcZeBOMpwoxvi8KBqAQGdigw1hYRUJB7Y0dFArDv39KSZS9zg@mail.gmail.com>
To: trans@ietf.org
Content-Type: multipart/alternative; boundary="001a114edd481dfaf5055dc18bec"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/9DF0bjk_6AFPS2GbmWhvN0ZaS1s>
Subject: [Trans] Comments on draft-ietf-trans-threat-analysis-12.txt
Precedence: list

This document appears to be in pretty good shape. I noted a few minor
areas for improvement, mostly editorial.


S 1.
   A relying party (e.g., browser) benefits from CT if it rejects a
   bogus certificate, i.e., treats it as invalid.  An RP is protected
   from accepting a bogus certificate if that certificate is revoked,
   and if the RP checks the revocation status of the certificate.  (An

I would add "directly" after benefits, because, as you note later
in this section, it also benefits of CT leads to revocation of
a bogus cert.


Figure 1:
In this diagram, all the left <s are missing. I expect you have
a failure to escape.

S 2.
   To make use of forged web site certificates, an adversary must be
   able to direct a TLS client to a spoofed web site, so that it can
   present the forged certificate during a TLS handshake.  An adversary
   may achieve this in various ways, e.g., by manipulation of the DNS
   response sent to a TLS client or via a man-in-the-middle attack.  The

I'm not sure I would characterize this as a MITM attack, but rather
as an active attack on the TLS connection itself. Maybe
"by manipulation of the DNS response... or, in the case of an
on-path attacker, directly intercepting the TLS connection"


   "malicious" CA.  A nation state also might compromise a CA in another
   country, to effect issuance of bogus certificates.  In this case the

Why limit this to "in another country"? This form of attack is also
available in the same country.


S 3.2.1.1.1.
The fact that CT doesn't ensure revocation is a really good point.
I think it would be worthwhile to make this point earlier, perhaps
in Section 1 where you discuss the basic theory of CT. I'd also
expand on this in two ways:

- A CA can use OCSP stapling to indefinitely extend the lifetime
  of a revoked certificate (you observe this in S 3.5)

- If a CA is able to pass off deliberate missisuance as accidental
  misissuance, it can in effect issue a completely bogus cert
  and keep it live permanently without consequence.


S 3.2.2.1.
Although there is nothing in IETF, Chrome has announced plans to
require CT for certificates with issuance dates after a certain
flag day, thus resulting in a gradual phase in, so it's probably
worth noting that at least in some cases people are working on
this.

S 3.3.
   discussions in Section 3.2 are applicable.  Section 3.3 explored the
   undetected compromise of a CA in the context of attacks designed to
   issue a bogus certificate that might avoid revocation (because the
   certificate would appear on distinct certificate paths).

As this phrase appears in S 3.3, I think you have a mistake here of
some kind.


S 4.1.1.1.
You seem to have some sort of rendering error where you repeatedly
have "(pre )certificate" rather than "(pre-)certificate")


S 4.2.1.1.
Please expand CCID on first user here.


-Ekr

[Trans] Comments on draft-ietf-trans-threat-analy… Eric Rescorla