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

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 12 May 2015 14:49 UTC

Return-Path: <nmav@redhat.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 4447B1B2E06 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 07:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Level:
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_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 9Ps8HoTo2wk0 for <tls@ietfa.amsl.com>; Tue, 12 May 2015 07:49:02 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B50C71B2E01 for <tls@ietf.org>; Tue, 12 May 2015 07:49:02 -0700 (PDT)
Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t4CEmxqF009108 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 12 May 2015 10:49:00 -0400
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t4CEmvwV002184 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 12 May 2015 10:48:58 -0400
Message-ID: <1431442136.16387.11.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: ryan-ietftls@sleevi.com
Date: Tue, 12 May 2015 16:48:56 +0200
In-Reply-To: <91953cbbfb330a83faad8f7115a20a5a.squirrel@webmail.dreamhost.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>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/vlAwkzK_if6ezZRVXucWLj5PN4g>
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: Tue, 12 May 2015 14:49:04 -0000

On Mon, 2015-05-11 at 11:41 -0700, Ryan Sleevi wrote:

> That's not true. I've explicitly stated it's a BAD requirement, and tried
> to give concrete examples.
> 
> I'll be explicit:
> 
> 1) I think clients, such as Martin's, that implement normative checking of
> ordering and are used for the Internet at large (e.g. between servers and
> clients that are not controlled by a single entity) are bad for Internet
> security.
> 2) I think clients, such as Martin's and Geoff's, that do not implement
> RFC 4158 path discovery are bad for Internet security.

That is of course if you define Internet as the web, and "security" as
the web PKI. What you are in fact describing is a failure of the web PKI
which RFC 4158 makes apparent. When you define trust as "anything my
browser trusts", then indeed you are going to have trust issues once you
switch to a browser from a different vendor. Nevertheless, RFC 4158 is
far from being a standard (just an informational RFC), 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?

regards,
Nikos

[0]. https://tools.ietf.org/html/rfc6066#section-6