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

Yoav Nir <> Wed, 13 May 2015 05:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 70CEF1AC3E1 for <>; Tue, 12 May 2015 22:59:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id r1VjN3H_46HY for <>; Tue, 12 May 2015 22:59:23 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:400c:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D71001AC3DB for <>; Tue, 12 May 2015 22:59:22 -0700 (PDT)
Received: by wgin8 with SMTP id n8so32057808wgi.0 for <>; Tue, 12 May 2015 22:59:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=vIA9kFIaqpgXRXkSl2EB9W2LN7PkMkTx7R6HAkeGQnA=; b=bcZQDLB+GqlcvegSwlFNHxp6fyGsFQm6zmTUyz2L14vgXxdulkDSp+LiA5nGn0kIa4 H9UXSzxpIxGpPeCTtnK0nGarNc/Ya2u/NbHh01rDMtzueOoH4qbv6cawsjE2bQLirUaz HHCLgfPJM/Hzk/VAnmiK/D5ljKmm1wYWUlMaW2z+ht47Pj5yDeLbL55ZUtqUUXPOebg9 JLrKb4P78UcvFY62wlj/ChrlAmduow7fMoaSdAVJZPVjdW8vtm9E651I8wLGSxtCiN6z ZpOXt4ppm2M7WHxPtr/oKF9WNxVlvVXJhhDuvNtmfT5UlzTViQxnzHN4EOtT6RXQnEDF My7A==
X-Received: by with SMTP id pl10mr11407414wic.70.1431496761639; Tue, 12 May 2015 22:59:21 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id hu1sm6207318wib.6.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 12 May 2015 22:59:20 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_4F8B5D50-4DFB-4A8F-8B33-FA09405C1765"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir <>
In-Reply-To: <>
Date: Wed, 13 May 2015 08:58:54 +0300
Message-Id: <>
References: <> <> <>
To: Brian Smith <>
X-Mailer: Apple Mail (2.2098)
Archived-At: <>
Cc: " (" <>
Subject: Re: [TLS] [tls13-spec] relax certificate_list ordering requirements to match current practice (#169)
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 May 2015 05:59:25 -0000

> On May 13, 2015, at 3:28 AM, Brian Smith <> wrote:
> Yoav Nir < <>> 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”.