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

Brian Smith <> Wed, 13 May 2015 00:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 286731A8825 for <>; Tue, 12 May 2015 17:28:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id V2gTu1JU10po for <>; Tue, 12 May 2015 17:28:05 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F1551A87D0 for <>; Tue, 12 May 2015 17:28:05 -0700 (PDT)
Received: by oign205 with SMTP id n205so19191394oig.2 for <>; Tue, 12 May 2015 17:28:05 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=grE8weNDMQntMZFE4F7pVgymc6qx/P/8GGoKM+aZxvc=; b=GN4nRa6DLol0dYLQb9EHDaQo3LNMtEgy8y+WOgQh0VPfruyT4sTfIkMYpEdnZqzszj zY7o/BYfZ1+sB8T6XvgovEZzHfmOYgDQuwyj3huR5gr1HpQYGo1Xogwo02GhHBMAwPqH ANQuKzT0+67Tluu2iEp1qeYQH0/T/tFGN7ruHU7KBwpuN4WTaHlp04K405aEoqVVv5xs 4Q7gnJ3TokQyawgbNyCBZHzmnMuX6YQudllhxFinhkwXubiYfdxdporGaOpvLZEh/JJM 9rcygwALxh0AlPAbrPeTpWEKsPki8tX+cm8zAhkdjqK1GTWQG9LZkuKAWFeUp0K36LYq 98Lw==
X-Gm-Message-State: ALoCoQmTDpv2fsfnX5gVV/FUw10JUfYvFHaclrsHwGzC2liwxJvBAFk0/InMEMqupTcsqVK2VXuO
MIME-Version: 1.0
X-Received: by with SMTP id fg9mr14056868oeb.83.1431476885041; Tue, 12 May 2015 17:28:05 -0700 (PDT)
Received: by with HTTP; Tue, 12 May 2015 17:28:04 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Tue, 12 May 2015 14:28:04 -1000
Message-ID: <>
From: Brian Smith <>
To: Yoav Nir <>
Content-Type: multipart/alternative; boundary="089e010d9e8a3cc7b90515ebafc2"
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 00:28:07 -0000

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

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