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

Andrew Ayer <agwa@andrewayer.name> Mon, 07 May 2018 19:56 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 7279F129C53 for <trans@ietfa.amsl.com>; Mon, 7 May 2018 12:56:55 -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 yfswca84OHJC for <trans@ietfa.amsl.com>; Mon, 7 May 2018 12:56:53 -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 DF64212783A for <trans@ietf.org>; Mon, 7 May 2018 12:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=andrewayer.name; s=beanwood20160511; t=1525723013; bh=e6chy+9t067GR+jVbvwANyMTZf6J+igCp10TM9vltxc=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=NeOXik7wwx8wqeIyLTz9zpu8F3QISEdbHEPXPk76XwfMsHwebtEVfKLPFtCHbPzKg 239zHE7RnXqdKid9DRDpwS+xUtT2dHYabMGSP31dUhcY347EaEPyOlLs7KNb6txuAt H/1M1bFMzPf98lKsUZjs0n4GLxjTGWkP3YMyUcffeTN1oWg48KW4gPBXS4EF6/Irqp iARgTBDuKVAM7DV5qxSTlpGd2ze/RclasbUoIs9l5an7pBTWUyQ8fmpcnXQOSwdcnu UD+TxS+t/bUPSeCXelr6SpTypsoPCDPUrAG4D7Y7+O19jLX6hrSERsX53l7cL7h0ua RcP10Eq1feqMA==
Date: Mon, 07 May 2018 12:56:52 -0700
From: Andrew Ayer <agwa@andrewayer.name>
To: "David A. Cooper" <david.cooper@nist.gov>
Cc: Paul Wouters <paul@nohats.ca>, Melinda Shore <melinda.shore@gmail.com>, Trans <trans@ietf.org>
Message-Id: <20180507125652.cd2d51d942c699f66a60c02e@andrewayer.name>
In-Reply-To: <cf3fd01c-a1f2-0cd0-d1a2-cda7b9558986@nist.gov>
References: <alpine.LRH.2.21.1804161658150.17034@bofh.nohats.ca> <cf3fd01c-a1f2-0cd0-d1a2-cda7b9558986@nist.gov>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/C3E8KZ6uEsH71SG2a4hWRX_zbKg>
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:56:55 -0000

On Fri, 4 May 2018 14:51:47 -0400
"David A. Cooper" <david.cooper@nist.gov> wrote:

> Section 4.1.1.4 says "Unfortunately, experience suggests that many
> browsers do not perform thorough syntactic checks on certificates, and so
> it seems unlikely that browsers will be a reliable way to detect erroneous
> certificates." and Section 4.2.1.4 says "As noted above (4.1.1.4), most
> browsers fail to perform thorough syntax checks on certificates." These
> sentences should be removed or modified. There is no reason that a
> browser should perform thorough syntactic checks on certificates, and
> there are good reasons for browsers not to. So, this document should
> not be labeling this as unfortunate or a failure. We do not want to
> encourage browsers to perform thorough syntax checks on certificates, as
> this could lead to the same types of problems that TLS has experienced,
> where making a change in something causes deployed products to break.

The trend in Firefox and Chrome is to make their certificate validators
much stricter about "syntactic" errors.  I think the main point of
section 4.1.1.4 is that it's not feasible for browsers to notify other
parties when it detects a syntactically misissued certificate, so these
checks need to be performed by monitors.

I think this sentence should just be dropped, as it's not true anymore
and tries to moralize about a controversial issue.

> Section 5.6, paragraph 4 says that "A Monitor must not rely on certificate
> discovery mechanisms to build the list of valid certificates since such
> mechanisms might result in bogus or erroneous certificates being added
> to the list." What would be the risk if an erroneous certificate was
> added to the list? When a Monitor is obtaining a list of certificates
> for the Subject to be monitored, wouldn't we want erroneous certificates
> to be included in that list so that the Monitor has a chance to detect
> the error?

Monitors look for subject names, not specific certificates.  The list
of valid certificates is so the monitor doesn't raise an alarm when it
finds a legitimate certificate for a monitored subject name.

So the answer to your first question is that the monitor would fail
to alert the Subject about an erroneous certificate.  This could be
clarified in section 5.6.

The answer to your second question is that the monitor would still
detect erroneous certificates, because it's monitoring based on subject
name.  This seems to be clear already from the description of a monitor
in the introduction.

Regards,
Andrew