Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Tue, 12 May 2015 19:16 UTC

Return-Path: <ryan-ietftls@sleevi.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11B3B1A7034 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:16:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 rIXC6DzcNdR1 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 12:16:14 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 181BF1A8940 for <tls@ietf.org>; Tue, 12 May 2015 12:16:14 -0700 (PDT)
Received: from homiemail-a109.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTP id CDD752007E5A3; Tue, 12 May 2015 12:16:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=CRMmXqnnXVvhe3vBpVdnSqeQBBw=; b=XJJ+ovnZZJ0CGeEbx HFWocj9ffGTJ369iyIGLUZpT90GvqxSDIfm2XNVNfFrtQHcUyS6NGPcdXymVlU+h am4jdBkNAOtCOvz2WWTBQIQRbHQRc6K9DJ/NlikoqJZgN6VFXt/IANVr6N6UK/dg 3/c+kIYn/jbRuPCMyFIAcyGNKQ=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a109.g.dreamhost.com (Postfix) with ESMTPA id 622AF2007E5A2; Tue, 12 May 2015 12:16:12 -0700 (PDT)
Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 12:16:13 -0700
Message-ID: <8d15ecf26f59aecebe0e210c95e68cea.squirrel@webmail.dreamhost.com>
In-Reply-To: <20150512185410.648121B2EB@ld9781.wdf.sap.corp>
References: <20150512185410.648121B2EB@ld9781.wdf.sap.corp>
Date: Tue, 12 May 2015 12:16:13 -0700
From: "Ryan Sleevi" <ryan-ietftls@sleevi.com>
To: mrex@sap.com
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/LDMJwmH36t0xE_lzlQXuq-6mtVU>
Cc: "TLS@ietf.org \(tls@ietf.org\)" <tls@ietf.org>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: ryan-ietftls@sleevi.com
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 12 May 2015 19:16:15 -0000

On Tue, May 12, 2015 11:54 am, Martin Rex wrote:
>  X.509 would require an omniscient trusted directory to perform certificate
>  path discovery, and the Certificate Path Validation algorithm in
>  rfc5280 section 6.1 clearly rules out AIA chasing as a permissible
>  approach for certificate path discovery, because this approach would
>  be clearly insecure and irresponsible.

Again, Martin, you're making unsubstantiated and inaccurate claims.

To the extent it's relevant to the discussion for the TLS WG, I will
simply note that RFC 5280 does not say anything about path discovery
precisely because discovery is out of scope for validation. Validation is
consistent, while discovery depends on a myriad of cases and protocols
outside of the narrow view of TLS. e.g. the validation of certificates in
PKCS#7 or in S/MIME.

So yes, RFC 5280 doesn't discuss how to do path discovery, because it's
out of scope, even though it repeatedly describes extensions and options
for how to do path discovery *that rely on parsing the untrusted
certificate*

RFC 5280 does not call AIA chasing as insecure, and in fact, acknowledges
it exists precisely to make discovery possible.

However, to the points at hand, at least it establishes why you object to
the change. You view it as predicated upon a fundamentally insecure
algorithm. While I (and many others, as evidenced by implementation and
discussion) would disagree with you, and I personally feel your claims of
standards imprimatur to be lacking, it at least provides a clear rationale
for your disagreement.

I don't think it'd be helpful for consensus building for me to try and
demonstrate where I think even RFC 5280 would disagree with your
conclusions, but if others feel themselves swayed by Martin's arguments, I
would be happy to add that fuel to the discussion.