Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis

Andrew Ayer <agwa@andrewayer.name> Mon, 07 May 2018 19:32 UTC

Return-Path: <agwa@andrewayer.name>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E99FE128961 for <trans@ietfa.amsl.com>; Mon, 7 May 2018 12:32:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=andrewayer.name
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOgJhMu-tYTI for <trans@ietfa.amsl.com>; Mon, 7 May 2018 12:32:09 -0700 (PDT)
Received: from thompson.beanwood.com (thompson.beanwood.com [IPv6:2600:1f14:a46:c400:6107:163e:4681:134e]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A076126FDC for <trans@ietf.org>; Mon, 7 May 2018 12:32:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1525721522; bh=X8gHThKj9WgP1c88eZ7nAFENTxN+iU8LkD2R6ZqtNic=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=X3wmAc+LBZ33B02Ks/+rPni9jXpkobEj6bY5FxFjiRXXLALq+A7kfq7Q8ma3EMQ+N d27zyvOeSygG6DeuxpI16MZYYv2ThT10iC5wgEQvkqAuYwLRrDTUboFYmaeZsxKCGp qfc+WBH74EbzI8Glsne9T5/enIRmxV0q7is5sTQLE0Oi6QbNRTbAJ9j4qfYcKYlv7o DVsuxuXihs01sfXNQVM8jqXrAhvoaIiFpvKQ1eaoiSMyjgazYEPkE4H8LkpO09rJkO QKHrc7H3EbrnRowSc7LR2UJahlQ0XAkfCo6I+GdzTNbJh192NRkRL/5a6j62z8NWkR l2eqr7reiIVeA==
Date: Mon, 07 May 2018 12:29:41 -0700
From: Andrew Ayer <agwa@andrewayer.name>
To: Paul Wouters <paul@nohats.ca>
Cc: Trans <trans@ietf.org>, Melinda Shore <melinda.shore@gmail.com>
Message-Id: <20180507122941.300b69582fa3acdb52b625af@andrewayer.name>
In-Reply-To: <alpine.LRH.2.21.1804161658150.17034@bofh.nohats.ca>
References: <alpine.LRH.2.21.1804161658150.17034@bofh.nohats.ca>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/IijSa8IPZ0oZ9fr1xmq-ETMjnss>
Subject: Re: [Trans] WGLC started for draft-ietf-trans-threat-analysis
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2018 19:32:13 -0000

draft-ietf-trans-threat-analysis-13 has a number of issues that ought
to be fixed before it's published.

A. Logs do not check for syntactic misissuance

Sections 4.1.1.1 and 4.2.1.1 give the impression that logs check,
or ought to check, submitted certificates for syntactic misissuance.
Page 20 says that syntactic misissuance will be detected "only if" a
(pre-)certificate is submitted to a log that performs syntactic checks.

This is not an intended function of logs, and not a single one of the
58 logs currently in operation performs syntactic misissuance checks.
Furthermore, having logs perform this function would violate separation
of concerns.  Instead, monitors perform syntactic misissuance checks.
crt.sh, for instance, runs all certificates through several certificate
linters.

Page 20 says that "syntactic checking [of pre-certificates] by a log
helps avoid issuance of an erroneous certificate."  This is contrary to
RFC6962 and RFC6962-bis, which both state that issuing a pre-certificate
is a binding commitment by the CA to issue a certificate.  It would
be dangerous for a CA to follow the advice on page 20, as browsers
rightly consider misissuance of a pre-certificate to be equivalent to
misissuance of a real certificate.  CAs must perform syntactic checks on
the TBSCertificate prior to signing anything.

Section 4.2.1.1 is premised on two I-Ds that were not adopted by trans
and have expired.

I suggest that sections 4.1.1.1 and 4.2.1.1 be removed entirely.


B. Conflation of log misbehavior and CA misbehavior

Page 4 says that if a bogus SCT is discovered, it would trigger
a revocation request.  Page 26 says that browsers need to "reject
certificates that contain SCTs from conspiring logs."

Page 3 says "if an RP verified that a certificate that claims to have
been logged has a valid log entry, the RP would have a higher degree of
confidence that the certificate is genuine."

But behavior of a log says nothing about whether a certificate was
properly issued.  A properly-issued certificate might be logged to a
a misbehaving log, and a misissued certificate might be logged to a
well-behaved log.

Therefore, browsers should not consider a certificate more likely to
be genuine just because it's logged, and if a certificate contains an
embedded SCT from a log that's known to be bad, the browser should reject
only that SCT, and still check SCTs from other logs.  And there is no need
to revoke a properly-issued certificate just because it's submitted to
a log that misbehaves.

Section 5.3 says that "evidence of a bogus or erroneous certificate"
can be "in the form of a log entry and/or SCT."  An SCT is irrelevant
for this, as it attests only to log behavior.


C. Response to log misbehavior

On pages 4, 9, and 13, the draft says that monitors should not "trust"
or "rely upon" misbehaving logs.  But monitors don't trust or distrust
logs - they just view logs as a source of certificates.  Browsers, on
the other hand, do trust and distrust logs.  For example, after two logs
(WoSign and Startcom) issued bad SCTs, they were distrusted by Chrome, but
Cert Spotter and crt.sh continued monitoring them until they shut down.

The document should be updated to remove mention of monitors trusting or
relying upon logs, and to make clear that the primary response to a
misbehaving log is for browsers to distrust it.


D. Signature/chain mutation attack

There's another way a log can misbehave which ought to be mentioned in
section 3.1.1.2.  A misbehaving log that conspires with a CA could log
a misissued certificate, but mutate the certificate's signature or chain
such that the certificate is no longer cryptographically attributable to
the CA.  The CA could then plausibly deny that it issued the certificate.
Since the signature and chain are not part of the Merkle Tree, the SCT
will be accepted by browsers and be auditable, despite the log entry
being mutated and useless for responding to the misissuance.

Monitors should be sure to validate the signature and chain of logged
certificates so that this misbehavior can be detected.


E. Chrome is requiring SCTs now

As David A. Cooper pointed out, Chrome is now requiring new certificates
to contain SCTs, so sections 3.1.2.2, 3.2.2.1, and 5.4 need updates.


F. Organization

The organization of the draft seems sub-optimal.  At a high level, the
document is broken up into semantic and syntactic misissuance, and then
into malicious vs non-malicious CA.  Within these categories, the document
discusses the implications when the certificate is logged, not logged,
or when the log is misbehaving.  Very often, these implications are the
same regardless of the type of misissuance or the culpability of the CA.
As a result, there is a lot of duplication, often with minor differences
in wording, which makes the document harder to understand.

I think the structure of section 5, which discusses issues as standalone
concepts, is a better model.  Alternatively, the duplication could be
removed from sections 3 and 4 and replaced by references to prior sub-sections.


G. Minor comments

Page 3 says "'bad-CA-lists' a CA as noted above".  "Bad-CA-list" hasn't
been defined and doesn't appear to be noted above.

Page 3 talks about "validat[ing]" an SCT, which is ambiguous, as it
could refer to checking the SCT's signature, or auditing the SCT for
inclusion. I suggest replacing "validates" with "audits" and replacing
"is invalid" (in the same sentence) with "fails auditing."

Page 4 says that "a CA benefits from CT when it detects a (mis-issued)
certificate that represents the same Subject name as a legitimate
certificate issued by the CA." How is a CA supposed to know if the
certificate is misissued or not?

Page 10 says that a monitor/auditor will detect a misbehaving log when
it "sees the bogus certificate."  It also needs to see the SCT.

Section 3.1.2.1 talks about a Subject being able to detect the lack of
an SCT in a certificate that it is issued.  Since this is part of the
section on "Semantic misissuance," which is defined in the Introduction
as a certificate issued to someone who isn't the Subject, it's unclear
to me what the point of this sub-section is. A Subject, by definition,
would never be issued a semantically misissued certificate.

Section 3.3.1 ends with "If the bogus certificate is detected and
logged, browsers that require an SCT will reject the bogus certificate."
Wouldn't the logging of a certificate cause an SCT to be issued, and
thus allow it to be *accepted* by browsers that require an SCT?

The last paragraph of section 3.5 talks about the attack in 3.4 and
should be moved.