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.
- [Trans] WGLC started for draft-ietf-trans-threat-… Paul Wouters
- [Trans] REMINDER: WGLC started for draft-ietf-tra… Paul Wouters
- Re: [Trans] REMINDER: WGLC started for draft-ietf… Salz, Rich
- Re: [Trans] WGLC started for draft-ietf-trans-thr… David A. Cooper
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Andrew Ayer
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Andrew Ayer
- Re: [Trans] WGLC started for draft-ietf-trans-thr… David A. Cooper
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Stephen Kent
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Paul Wouters
- Re: [Trans] WGLC started for draft-ietf-trans-thr… David A. Cooper
- Re: [Trans] WGLC started for draft-ietf-trans-thr… David A. Cooper
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Stephen Kent
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Ryan Sleevi
- Re: [Trans] WGLC started for draft-ietf-trans-thr… David A. Cooper
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Ryan Sleevi
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Stephen Kent
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Stephen Kent
- Re: [Trans] WGLC started for draft-ietf-trans-thr… Ryan Sleevi
- Re: [Trans] Fw: Re: WGLC started for draft-ietf-t… Stephen Kent
- Re: [Trans] Fw: Re: WGLC started for draft-ietf-t… Ryan Sleevi
- Re: [Trans] Fw: Re: WGLC started for draft-ietf-t… Rob Stradling
- Re: [Trans] Fw: Re: WGLC started for draft-ietf-t… Stephen Kent
- Re: [Trans] Fw: Re: WGLC started for draft-ietf-t… Stephen Kent