Re: [TLS] Update spec to match current practices for certificate chain order

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Fri, 08 May 2015 21:10 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 2E5811A0052 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 14:10:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.233
X-Spam-Level:
X-Spam-Status: No, score=0.233 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 kvxjwtLuz5dG for <tls@ietfa.amsl.com>; Fri, 8 May 2015 14:10:22 -0700 (PDT)
Received: from homiemail-a88.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1F8951A002A for <tls@ietf.org>; Fri, 8 May 2015 14:10:21 -0700 (PDT)
Received: from homiemail-a88.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTP id E308726408B; Fri, 8 May 2015 14:10:20 -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=wkIPUusqAjj3N8jJ2B7Clr8WPVU=; b=USDtR+3ygI+RfbCdv rfWG+jWZVoa2Kf+i+i92GzSe/toM0ho7JXwxkKqT1NUhYy3j8qMgqFTcyi/3yEro +Kz1+Uyi9auJ8E9wRCBm+xYd5WtSOeoOeGi8PvwTX2xaeJYGxX6c06iQpU3Q8CpL ma7cekEEV+mJ0GfzCW1kDztjD0=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a88.g.dreamhost.com (Postfix) with ESMTPA id DFA1E2640B4; Fri, 8 May 2015 14:10:18 -0700 (PDT)
Received: from 216.239.45.71 (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Fri, 8 May 2015 14:10:19 -0700
Message-ID: <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com>
In-Reply-To: <201505081129.57194.davemgarrett@gmail.com>
References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081129.57194.davemgarrett@gmail.com>
Date: Fri, 8 May 2015 14:10:19 -0700
From: "Ryan Sleevi" <ryan-ietftls@sleevi.com>
To: "Dave Garrett" <davemgarrett@gmail.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/3EBTxTeND6dbhkoEQ5SW0qjgzzY>
Cc: tls@ietf.org
Subject: Re: [TLS] Update spec to match current practices for certificate chain order
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: Fri, 08 May 2015 21:10:29 -0000

On Fri, May 8, 2015 8:29 am, Dave Garrett wrote:
>  Let me be clear: I don't fundamentally disagree with you.

While I have great respect for Martin, I do disagree and think he's
fundamentally wrong here, for the reasons I already explained in my first
message as to why what he's asking is not only *wrong*, but *unwise* and
an unnecessary coupling of two intentionally-independent layers.

> Do you
>  think we could compel every browser vendor to apply this (effectively) new
>  standard uniformly, and make the changes all at the same time?

As I said elsewhere, requiring ordering might be something browsers do in
the future, but it's fundamentally coupling two things which are
explicitly decoupled (and better off so)

>  I don't,
>  especially not from the TLS spec. Vendors can't even drop critically
>  insecure protocols in unison. I don't even have confidence that everyone
>  could coordinate a token change of coloring in the UI for this one narrow
>  case.

And of course, coloring is the unquestionably wrong answer here from a
usability study. It's not so much a bikeshed discussion as demonstrably
bad for users and homeopathic cybersecurity :)

> > I believe that one of the causes why the problem exists at all
> > is a lack of sensible PKI credential management on the server side.
>
>  Likely true, but outside of the current scope of action.

The only way in which this protocol could have worked as described is in
an X.500 world that no one should reasonably/sanely want. Outside of that,
we're talking about tradeoffs and compromise, and those are both sensible
and necessary, so I agree wholeheartedly here :)