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

Santosh Chokhani <schokhani@cygnacom.com> Wed, 13 May 2015 12:55 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 7BFA21A90CD for <tls@ietfa.amsl.com>; Wed, 13 May 2015 05:55:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 zD_jqpk28rh0 for <tls@ietfa.amsl.com>; Wed, 13 May 2015 05:55:27 -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 6BCFD1A90AD for <tls@ietf.org>; Wed, 13 May 2015 05:55:26 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: ArQKADVJU1UKPDLY/2dsb2JhbABcgkVKVF4GgkpOyU8CHIEeTAEBAQEBAYELQQWDWgEBAQMBIwpMBQsCAQUDDQEDBAEBASMEAwICAh8RFAkIAgQBDQUIEYd+AwoIBbVejS4NhHwBAQEBAQEBAQEBAQEBAQEBAQEBAQEXizqCTYI4BgGCaIFFBZAgi1ABgnqGVIR+gwmDH4NXI2GBWYE9PjGBAyIggQEBAQE
X-IronPort-AV: E=Sophos;i="5.13,420,1427774400"; d="scan'208,217";a="91536"
Received: from unknown (HELO svaexch1.cygnacom.com) ([10.60.50.216]) by ipesa2.cygnacom.com with ESMTP; 13 May 2015 08:55:24 -0400
Received: from svaexch1.cygnacom.com (10.60.50.216) by svaexch1.cygnacom.com (10.60.50.216) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Wed, 13 May 2015 08:55:23 -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; Wed, 13 May 2015 08:55:23 -0400
From: Santosh Chokhani <schokhani@cygnacom.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Brian Smith <brian@briansmith.org>
Thread-Topic: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
Thread-Index: AQHQieY/gmukibBgKEmnwP9D0xEiS513auKA//+u2OCAAEnXAIABNvSAgABKNACAABSYAIAABimAgAADzgCAAAZpgIAATOoAgABcbwCAAC+ToA==
Date: Wed, 13 May 2015 12:55:22 +0000
Message-ID: <cf9a644498a74eb3b870970eef93ed22@svaexch1.cygnacom.com>
References: <20150512192950.C93F21B2EB@ld9781.wdf.sap.corp> <939995E0-4ED0-479A-8B3A-628FE2C8C31B@gmail.com> <CAFewVt6cCKk95BH9e9hzAvgqFJwDhiAM-mHUPtGittqQ1=C9qw@mail.gmail.com> <A052A1F5-C178-4187-ADC9-11D2AE0E69A0@gmail.com>
In-Reply-To: <A052A1F5-C178-4187-ADC9-11D2AE0E69A0@gmail.com>
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: [108.31.66.4]
Content-Type: multipart/alternative; boundary="_000_cf9a644498a74eb3b870970eef93ed22svaexch1cygnacomcom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PTcfr8m1SXHb_EX6zomZ0b6GhM4>
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: Wed, 13 May 2015 12:55:33 -0000

I agree with Yoav.

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Yoav Nir
Sent: Wednesday, May 13, 2015 1:59 AM
To: Brian Smith
Cc: TLS@ietf.org (tls@ietf.org)
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)


On May 13, 2015, at 3:28 AM, Brian Smith <brian@briansmith.org<mailto:brian@briansmith.org>> wrote:

Yoav Nir <ynir.ietf@gmail.com<mailto:ynir.ietf@gmail.com>> wrote:
> 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.

In that sense, how is AIA different from revocation checking? Whether you use CRLs or OCSP, you’re following a URL in the (still untrusted or at least possibly revoked) certificate to retrieve an object.

When you fetch CRLs or OCSP responses, you are using a URL that has been authenticated by a trusted issuer, assuming you do revocation checking from the root to the end-entity, which is the safer way of doing it. Whereas, in AIA cert fetching you are making a request to an unauthenticated URL. That is quite a big difference, because it is much harder to get a CA to sign a certificate with your chosen OCSP URL than it is to just forge your own certificate with whatever AIA caIssuers URL you want to have.

Ultimately, a client shouldn't fetch OCSP responses or CRLs either, for many reasons. One of the big reasons is that those fetches greatly increase the attack surface of the client beyond what is otherwise necessary. Instead we need to move to a model where revocation information is always provided within the TLS handshake (e.g. OCSP stapling and/or short-lived certificates).

Consequently, we shouldn't accept AIA cert fetching as good or even reasonable behavior based on analogies to revocation information fetching.

I see. I understand the difference, I just don’t think it matters. I also disagree with your assertion that clients shouldn’t fetch OCSP responses, CRLs or AIAs. Sending stapled OCSP responses or an entire certificate chain is a good optimization and makes the TLS handshake end more quickly. I can see why people would like that. But fetching these things from the Internet is no different from fetching other items from the Internet. Clients do this all the time.

I agree that this increases the attack surface, but what kinds of attacks are we talking about? A very mild DoS attack by pointing the client at a URL with a petabyte of random data? An invalid CRL? A badly formatted CA certificate that will cause a buffer overflow on the client?  That kind of certificate could have been sent in the handshake. These risks seem to me to be part life on the Internet. They’re not worth the issues of sending large objects over UDP for DTLS for example.  So I agree that for regular TLS sending the entire chain is the right thing to do, as is sending a stapled OCSP response. I just don’t think building a chain through other means is in any way “bad”.

Yoav