Re: [TLS] Update spec to match current practices for certificate chain order
Dave Garrett <davemgarrett@gmail.com> Sat, 09 May 2015 04:49 UTC
Return-Path: <davemgarrett@gmail.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 10CD51A90E0 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 21:49:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] 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 c2eJkiErv-E9 for <tls@ietfa.amsl.com>; Fri, 8 May 2015 21:49:20 -0700 (PDT)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E4A591A90DF for <tls@ietf.org>; Fri, 8 May 2015 21:49:19 -0700 (PDT)
Received: by qgfi89 with SMTP id i89so45956639qgf.1 for <tls@ietf.org>; Fri, 08 May 2015 21:49:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; bh=K1fbqS/q9nmg2x4IcYpHZJz0pbyLq3KWe/nDTxgQIHM=; b=xh2/3jyx9fJ92xId6QKAfPt0Zjq94nc5U+0T8Zj3MtIYmwobdxGqsw3wURkGte3AVS LPrRrHPRI0b1S+KhUt7NkgTJcblYJkfcJatc+hcyajBsNeuvgGGnw7kse7GcX38CcEiM efiQicYi8P+7Nbhuv1C1zo9K1jyux1kgvAsJMBwajqY+YKAITkpd8qaHMv3FaS5FLoeD z5PQoyOtHVRQTzzVfg5RPcrC4zs2TlFo1/ZXZNB6LRpfgaCAv1xIDEv2Kxe9ShkjdH80 Zh0GGIrva1u+4Yd2OL1RCzXUyeS7cRvIBP68ZazVMI7dTBl4r4xbifMefEsMhKDLGBHo z8Hg==
X-Received: by 10.229.172.70 with SMTP id k6mr1632690qcz.10.1431146959063; Fri, 08 May 2015 21:49:19 -0700 (PDT)
Received: from dave-laptop.localnet (pool-96-245-254-195.phlapa.fios.verizon.net. [96.245.254.195]) by mx.google.com with ESMTPSA id l200sm5135582qhl.24.2015.05.08.21.49.18 (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 08 May 2015 21:49:18 -0700 (PDT)
From: Dave Garrett <davemgarrett@gmail.com>
To: mrex@sap.com
Date: Sat, 09 May 2015 00:49:16 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-73-generic-pae; KDE/4.4.5; i686; ; )
References: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp>
In-Reply-To: <20150509032036.072AD1B2E2@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201505090049.17456.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/01iUpO0J0DYhSQT0rgdKBvavRfw>
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
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: Sat, 09 May 2015 04:49:22 -0000
On Friday, May 08, 2015 11:20:35 pm Martin Rex wrote: > Dave Garrett wrote: > > A PR with language based on this discussion: > > https://github.com/tlswg/tls13-spec/pull/169/files > > > > The text is mostly the same or similar, with the second "MUST" changed > > to a "SHOULD", and the term "trust anchor" replacing references to root > > keys/CA. > > > > Is this changeset acceptable? > > I am violently opposed to this change. > > It creates new ambiguities, makes bogus, backwards-incompatible > and interoperability-impairing behaviour appear less objectionable, Yep, but it does convert interoperability-impairing behavior into interoperable behavior. > while providing _zero_ benefit. It's not zero. Advantages: improved interoperability / implementation parity (like it or not) allows multiple intermediates for transitional capabilities Disadvantages: minor validation complexity increase (that already seems common) it's Wrong™ > Clients that do not perform any fancy unsafe path discovery, on the Fancy, maybe; unsafe, no. We're debating whether or not paperwork should be accepted if page 3 was stapled between pages 1 and 2. In an ideal world, no, but in a world after two decades of SSL/TLS... I don't care. The on-the-wire ordering is a minor technicality and there are legitimate use-cases that need an update here, in addition to handling shoddy server implementations. (Some server implementations seem to act like this because they leave the specifics of ordering up to configuration by an admin that probably doesn't know the spec.) See also Ryan's reply that cites the transitional issue in detail: https://www.ietf.org/mail-archive/web/tls/current/msg16226.html TL;DR: sanely phasing out 1024-bit RSA keys is dependent on this Also, you've attached the adjective "unsafe" to the terminology here without providing a justification for doing so. Please explain a practical reason why this would be unsafe and we might agree with you. If you can actually show that this would be unsafe, and that mandating all clients to stop doing this and throw a fatal error is the best course of action, and can actually get a consensus to this effect on this list, then I'd probably concur. As I said in a prior email in this thread, I'm generally in favor of strict error enforcement when actually useful and properly coordinated. Arguing for keeping the text as-is, however, is just ignoring the problem. {In case of possible misunderstanding: I do not ask rhetorical questions. I'm not being sarcastic and am genuinely curious if there is sufficient justification to consider this practice to be unsafe. I could see how it might be risky for an already sloppy implementation to add support for, but I don't see how this feature itself makes this unsafe.} > other hand, may easily be non-interoperable with sloppy servers that > do not properly compose their Server Certificate handshake message, > and these Client are _not_ to blame for any resulting interop failure, > because it is clearly the server TLS implementation that goofed > when it produces a Server Certificate PDU that violates the MUSTs. Yes, very much so. *That is one of the primary reasons for this change.* Client implementers need to be given a heads-up that this is something they need to account for, as this is already current practice. The proposed spec change is merely a documentation of this. Dave
- [TLS] Update spec to match current practices for … Dave Garrett
- Re: [TLS] Update spec to match current practices … Yoav Nir
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Fabrice Gautier
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Geoffrey Keating
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Ben Laurie
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Kemp, David P.
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Kemp, David P.
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Geoff Keating
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Salz, Rich
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Dave Garrett
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Ben Laurie
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Peter Gutmann
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ilari Liusvaara
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Watson Ladd
- Re: [TLS] Update spec to match current practices … Viktor Dukhovni
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi
- Re: [TLS] Update spec to match current practices … Martin Rex
- Re: [TLS] Update spec to match current practices … Ryan Sleevi