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

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Tue, 12 May 2015 17:13 UTC

Return-Path: <ryan-ietftls@sleevi.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 299BD1ACD59 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 10:13:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 PrZ_m3g6mdc1 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 10:13:27 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 2CCC31ACD58 for <tls@ietf.org>; Tue, 12 May 2015 10:13:27 -0700 (PDT)
Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id 9BADD2004F323; Tue, 12 May 2015 10:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=s39T4xEm9Sz3ZZ4PrkvSrsAkhOs=; b=KglT8F0/hYRpCF+c2 3jHRgXH3AStWdPzqKsV5LJQ7C0racMLeugfGN5iPgDEpKhSJEmpanPFyPV5j6Sna K5HxZtpRtp3LEu3V0jos34Ve0JZYW8AhX4XcVcis/bMszamVE61YLWMFPyVEf06b jRilBn6Yq45oCGwtz8N2S8vEw0=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id B35CE2004F328; Tue, 12 May 2015 10:13:22 -0700 (PDT)
Received: from 173.8.157.162 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Tue, 12 May 2015 10:13:26 -0700
Message-ID: <e7afe21aa3093b64348a12e77fc287f4.squirrel@webmail.dreamhost.com>
In-Reply-To: <1431442136.16387.11.camel@redhat.com>
References: <tlswg/tls13-spec/pull/169@github.com> <tlswg/tls13-spec/pull/169/c101001652@github.com> <8425a2f40ddc46ac91aca136a955fc53@ustx2ex-dag1mb4.msg.corp.akamai.com> <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.com> <1431442136.16387.11.camel@redhat.com>
Date: Tue, 12 May 2015 10:13:26 -0700
From: Ryan Sleevi <ryan-ietftls@sleevi.com>
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/0phSi4ryA4iUACtvFzCWQ51aQRQ>
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
Reply-To: ryan-ietftls@sleevi.com
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 17:13:28 -0000

On Tue, May 12, 2015 7:48 am, Nikos Mavrogiannopoulos wrote:
>  Nevertheless, RFC 4158 is
>  far from being a standard (just an informational RFC),

I don't think I presented it as a standard - just what the major PKI
clients that most users interact with on a daily basis do.

I didn't suggest it was the whole Internet. But for the PKI that people
rely on for their daily interactions online (aka the Web PKI), which is
used far beyond *just* web browsers (as
https://access.redhat.com/articles/1413643 reminds us), the security here
is relevant, and perhaps essentially so.

>  and there are
>  standard's track extensions which can address the issue [0] and can
>  allow the server to decide which path to send. Does your good for
>  Internet implementation utilize it?
>  [0]. https://tools.ietf.org/html/rfc6066#section-6

There are no plans at present to implement, and it's unlikely we would.
Without wanting to get into a separate discussion, the privacy and
performance implications of such an extension are extremely undesirable.

Just because there's a Standards Track I-D doesn't mean it is wise or
desirable ( http://tools.ietf.org/html/rfc6961 is another example), and
just because it's an Informational Draft doesn't mean it's not widely
supported (CryptoAPI, Java, and NSS, for example, all follow the logic of
4158)

If I phrased your concern more objectively, would ubiquitous support
"tomorrow" for RFC 6066 cause me to remove support for relaxing the
language? No, because we still have the world we live in today. And having
spec language reflect an idealized, unrealistic future instead of the
reality we live in just does more harm than good. Much like references to
the X.500 Global Directory.