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

"Ryan Sleevi" <ryan-ietftls@sleevi.com> Fri, 08 May 2015 21:53 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 55F0A1A1A66 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 14:53:36 -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_20=-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 3DnxzUYjqF-o for <tls@ietfa.amsl.com>; Fri, 8 May 2015 14:53:35 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A49741A1A57 for <tls@ietf.org>; Fri, 8 May 2015 14:53:35 -0700 (PDT)
Received: from homiemail-a49.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTP id 7ED38200D9F9D; Fri, 8 May 2015 14:53:35 -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=5FRY0ESmwpucRSPm8+yy/hq1ylE=; b=GsNx48R4KEi6i9h6M u2OdDVsmclUQ+t8QgeQRpiE2DpqEW72t+fTt9BnxS3YA8Utzpxv5dwpfQwmfTX/a wlYA2Hja/QSyZyVvhs0BV9rVkv4k1pXGHFAvipjNTFVNmkFlFx8Oinn6IGyHs661 OL9Zu/60yQa1/etLyaLg/xPrXw=
Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a49.g.dreamhost.com (Postfix) with ESMTPA id 76F2D200D9F8D; Fri, 8 May 2015 14:53:34 -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:53:34 -0700
Message-ID: <7dd89312e9234c911e27edd81b2686d0.squirrel@webmail.dreamhost.com>
In-Reply-To: <201505081734.47783.davemgarrett@gmail.com>
References: <20150508141926.1C16A1B2DE@ld9781.wdf.sap.corp> <201505081129.57194.davemgarrett@gmail.com> <20ca33d85bfab861c8e8f4dd60a607ee.squirrel@webmail.dreamhost.com> <201505081734.47783.davemgarrett@gmail.com>
Date: Fri, 8 May 2015 14:53:34 -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/_Ur1Jw7NkfoqNaN4cI2ybl3zj1g>
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:53:36 -0000

On Fri, May 8, 2015 2:34 pm, Dave Garrett wrote:
>  This is a two decade old set of security standards. If you want any strict
>  separation of layers, you're going to need to start from scratch. (which
>  we're
>  hopefully doing soon with something QUIC based) Anything other than
>  acknowledging this current situation as a mess and doing what you can
>  where you can (e.g. HPKP) is not really practical.
>
>  Wise as it may be to try to keep things decoupled, it's not the current
>  reality.

I think you've misunderstood me. Hopefully a re-read of the original
message will provide clarity.

The "problem" caused is precisely *because* the layers are decoupled. To
satisfy Martin's requirement (e.g. at a browser), you would necessarily
*need* to couple the layers. And while it's true that browser's internal
implementations have begun to blur the layers such that a tight coupling
may not be entirely unreasonable, they are *not* coupled to the degree
necessary to satisfy the second MUST, which is why we're in the present
state.

So by accepting the status quo and having the spec updated to reflect
that, we agree that the decoupling/loose coupling is good.

By changing clients to enforce the second MUST, we promote more coupling
at the clients. That's not good in my view.