Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Tue, 12 May 2015 20:04 UTC
Return-Path: <dkg@fifthhorseman.net>
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 611DC1A88ED for <tls@ietfa.amsl.com>; Tue, 12 May 2015 13:04:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 bIP_cX7MjEB3 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 13:04:03 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 979341A8A08 for <tls@ietf.org>; Tue, 12 May 2015 13:04:03 -0700 (PDT)
Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 62011F984; Tue, 12 May 2015 16:04:01 -0400 (EDT)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 01EB920624; Tue, 12 May 2015 16:03:36 -0400 (EDT)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: mrex@sap.com, ryan-ietftls@sleevi.com
In-Reply-To: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp>
References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp>
User-Agent: Notmuch/0.20~rc1 (http://notmuchmail.org) Emacs/24.4.1 (x86_64-pc-linux-gnu)
Date: Tue, 12 May 2015 16:03:36 -0400
Message-ID: <87lhgtbm1z.fsf@alice.fifthhorseman.net>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/-OQmUMrMwK4bjgBw_XF55W5dGnw>
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
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 20:04:05 -0000
On Tue 2015-05-12 15:29:50 -0400, Martin Rex wrote: > With the prerequisite of a conscious and informed active consent by a human > administrator during out-of-band maintenance/administration, using AIA to > download a certificate can be an accetable security trade-off. > > But a machine/automata/algorithm that will automatically download objects > from URLs from still-untrusted data provided by the peer is definitely > insecure and irresponsible. Doesn't this argument suggest that we should go ahead and relax the text as suggested? If: * automated cert fetching is bad (i'm inclined to agree with you about this, Martin, since it would embed www-like promiscuous network activity in protocols that don't currently suffer from it), and * cert validation is hard (as evidenced by the litany of problems people have getting it right), and * no unified/global trust anchor exists (because people have different perspectives on the world), and * servers don't know what the clients preferred trust anchors are (and probably shouldn't require the client to announce this perspective to perform a TLS handshake, for privacy reasons), and * we need to be able to upgrade existing PKI smoothly, because breaking existing clients will prevent most deployers from ever upgrading anything, Then: * it seems like we ought to explicitly permit servers to ship the certificates capable of forming multiple verification chains in the TLS handshake, so that clients have all the certs they need to find their preferred path, without having to do AIA fetching. Given that servers *already do this*, the argument seems even stronger. I agree with Martin that this is super-dirty and a far more complex system than anyone sane would have designed from first principles. But i still think it's the right thing to do given the ugly state of the network today. --dkg
- Re: [TLS] [tls13-spec] relax certificate_list ord… Salz, Rich
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Andrei Popov
- Re: [TLS] [tls13-spec] relax certificate_list ord… Salz, Rich
- Re: [TLS] [tls13-spec] relax certificate_list ord… Salz, Rich
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ben Laurie
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Watson Ladd
- Re: [TLS] [tls13-spec] relax certificate_list ord… Nikos Mavrogiannopoulos
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Yoav Nir
- Re: [TLS] [tls13-spec] relax certificate_list ord… Daniel Kahn Gillmor
- Re: [TLS] [tls13-spec] relax certificate_list ord… Santosh Chokhani
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Viktor Dukhovni
- Re: [TLS] [tls13-spec] relax certificate_list ord… Yoav Nir
- Re: [TLS] [tls13-spec] relax certificate_list ord… Dave Garrett
- Re: [TLS] [tls13-spec] relax certificate_list ord… Dave Garrett
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex
- Re: [TLS] [tls13-spec] relax certificate_list ord… Ryan Sleevi
- Re: [TLS] [tls13-spec] relax certificate_list ord… Fabrice Gautier
- Re: [TLS] [tls13-spec] relax certificate_list ord… Brian Smith
- Re: [TLS] [tls13-spec] relax certificate_list ord… Yoav Nir
- Re: [TLS] [tls13-spec] relax certificate_list ord… Viktor Dukhovni
- Re: [TLS] [tls13-spec] relax certificate_list ord… Peter Gutmann
- Re: [TLS] [tls13-spec] relax certificate_list ord… Santosh Chokhani
- Re: [TLS] [tls13-spec] relax certificate_list ord… Martin Rex