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

Santosh Chokhani <schokhani@cygnacom.com> Tue, 12 May 2015 20:37 UTC

Return-Path: <schokhani@cygnacom.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 D0B171AD072 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 13:37:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 vKzzAaf05PdT for <tls@ietfa.amsl.com>; Tue, 12 May 2015 13:37:19 -0700 (PDT)
Received: from ipesa2.cygnacom.com (ipesa2.cygnacom.com [65.242.48.201]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB14A1AD06F for <tls@ietf.org>; Tue, 12 May 2015 13:37:18 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqwEABJjUlUKPDLZ/2dsb2JhbABcg2NeBsZ7CoYFAoIMAQEBAQEBgQuEIAEBAQQBAQE3NAsMBAIBCA0EBAEBAR4FBAcnCxQJCAIEAQ0FCIgpCModAQEBAQEBAQEBAQEBAQEBAQEBAQEBEwSLOYQ6CUIHBoQnBZ5dhlKEfIYmg1WBBIEjNoE9b4EDAgUfHIEBAQEB
X-IronPort-AV: E=Sophos;i="5.13,417,1427774400"; d="scan'208";a="90985"
Received: from unknown (HELO svaexch2.cygnacom.com) ([10.60.50.217]) by ipesa2.cygnacom.com with ESMTP; 12 May 2015 16:37:18 -0400
Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch2.cygnacom.com (10.60.50.217) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 12 May 2015 16:37:16 -0400
Received: from svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e]) by svaexch1.cygnacom.com ([fe80::b53e:f4f1:9071:563e%12]) with mapi id 15.00.1076.000; Tue, 12 May 2015 16:37:16 -0400
From: Santosh Chokhani <schokhani@cygnacom.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "mrex@sap.com" <mrex@sap.com>, "ryan-ietftls@sleevi.com" <ryan-ietftls@sleevi.com>
Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OCAAEnXAIABNvSAgABKNACAABSYAIAABimAgAADzgCAAAlvAP//weOQ
Date: Tue, 12 May 2015 20:37:15 +0000
Message-ID: <9f4a6b908fe044c5af767c0e2646f1b3@svaexch1.cygnacom.com>
References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <87lhgtbm1z.fsf@alice.fifthhorseman.net>
In-Reply-To: <87lhgtbm1z.fsf@alice.fifthhorseman.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.60.117.7]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/E8vG1NAec-cNhpb2V4wriCoBxws>
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:37:21 -0000

I do not have objections to server sending a certificate bag so that one or more paths can be formed/built/discovered by the client.

However, I disagree with several things Martin says about AIA chasing and RFC 4158.  To me, most of what he says has been argued on PKIX and I do not see any security concerns.  While one can argue that SIA chasing is ideal since your next step is always from a vetted pointer, as others have pointed out CRL DP and OCSP situation is no different.  If the AIA pointer has poisoned data in it, you will not decode the certificate or the certificate bag correctly.

Besides in a cross-certified world, a server has one view of the trust anchors and a client might reside in cross-certified domain, necessitating AIA chasing on some CA certificate at some point.  If you like, clients can do SIA chasing, but not many folks implement SIA on the producer side (i.e., the CAs) or on the consumer side (i.e., the TLS client).  In that scenario, there would be no need for the server to send certificate chain or bag; simply server certificate will suffice.

BTW, while not related to validating the server certificate, some of the popular browsers have had issues in the area of client authenticated TLS, where the browser will not even present a legitimate client certificate since it terminates on a trust anchor from the browser's perspective and that trust anchor not being in the server's hints list, albeit server can build a path to the client certificate.  Again, this is endemic to cross-certified environments.

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Daniel Kahn Gillmor
Sent: Tuesday, May 12, 2015 4:04 PM
To: mrex@sap.com; ryan-ietftls@sleevi.com
Cc: TLS@ietf.org (tls@ietf.org)
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)

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

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls