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