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