IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Wed, 13 May 2015 06:23 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 AE7B41A0A6A for <tls@ietfa.amsl.com>; Tue, 12 May 2015 23:23:30 -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 vwxjYQ1K9OPh for <tls@ietfa.amsl.com>; Tue, 12 May 2015 23:23:29 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 612461A06FD for <tls@ietf.org>; Tue, 12 May 2015 23:23:29 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 296C8283032; Wed, 13 May 2015 06:23:28 +0000 (UTC)
Date: Wed, 13 May 2015 06:23:28 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: tls@ietf.org
Message-ID: <20150513062327.GS17272@mournblade.imrryr.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <A052A1F5-C178-4187-ADC9-11D2AE0E69A0@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/Y-yQupKvfnhaITUSOLEXNB49iBU>
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
Reply-To: tls@ietf.org
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 06:23:30 -0000

On Wed, May 13, 2015 at 08:58:54AM +0300, Yoav Nir wrote:

> 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".

It can be at least onerous.  Clients speaking a given protocol may
not be at liberty to connect to anything other than their peer,
and may not posess an HTTP stack with which to make out-of-band
requests.

The SSL/TLS library cannot transparently attempt such additional
connections with consent and mediation for connection establishment
and event loop integration from the application layer to engage in
the additional communications.

So in-band is definitely simpler, and leaks less data to third
parties.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email