[TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

Watson Ladd <watson@cloudflare.com> Wed, 16 January 2019 01:13 UTC

Return-Path: <watson@cloudflare.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A8D12130F80 for <tls@ietfa.amsl.com>; Tue, 15 Jan 2019 17:13:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.554
X-Spam-Status: No, score=-6.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nfm6DrqoXP5K for <tls@ietfa.amsl.com>; Tue, 15 Jan 2019 17:13:29 -0800 (PST)
Received: from mail-qt1-x835.google.com (mail-qt1-x835.google.com [IPv6:2607:f8b0:4864:20::835]) (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 4B62912D4EA for <tls@ietf.org>; Tue, 15 Jan 2019 17:13:29 -0800 (PST)
Received: by mail-qt1-x835.google.com with SMTP id r14so5365985qtp.1 for <tls@ietf.org>; Tue, 15 Jan 2019 17:13:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=gxTv/MUepLGTzEy02QqzNb1dWPG36N0fVN1/pzegk5I=; b=UtKuB4fdPwhHD8TXThmTJRGYWAEmgTnGGuYOBzcZmAGIJ+R99X5jGTawMCirjt97n7 THmLgwdDCI4MXjFkRrMQZQPC5phJgmVvHAc8YIRbMTcDsz3aVWVpv7+O878ECqFX0H1l OFCQrQQl5VES4+XNqPojv1vAtZocwdO7I8qbU=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=gxTv/MUepLGTzEy02QqzNb1dWPG36N0fVN1/pzegk5I=; b=IxOK+tZafs3MIARIqh+8ZqQc+Uz+255ydPBYixN07B74NIi4FkSsHwtSFdYKSBo4+v 5Mj8DHPUERbSzbjxLUGmBZyHbAKLrAPpBpCUf1WKTHLCD34Nqw+arhMe4QdQ+7a0zh7T puaYpJQl/LchfIQYvFXTBFhZZ9jxdLdIdSMCsqXwBv1NQt7i1N4pZg79TVMpuYDkNKFq a8uUimx/Pd4HfjSWFTrCgbVeqC68gIPJybhp0O0qZ/7Nykn1VgMPzxffDCnNJkGxvXGV 6ipuAdGe5ll8x5d7rg+2Pq2enBLi18ozYz7bxDC9YDvXgtiZ2b2Q5fkVosdGpvGBhZjp YF4w==
X-Gm-Message-State: AJcUukciyz8RXDM6cEXXiAZNFIKQ+OmpPOikULAcRH17iTyNOPvR8Dj0 ctXUHtDaLWcQHMeBsTrrdJgUbWbH/Vm4kmWpCl0k11rx4ng=
X-Google-Smtp-Source: ALg8bN7YhLMJgNJBwj22vF9rHE1RNicrmLHMZquCq7I28RPD6V38glScp4FNuYI/IWYVKdm3oFjqIcPzuV/EkMH9HdE=
X-Received: by 2002:a0c:8936:: with SMTP id 51mr5212621qvp.220.1547601208262; Tue, 15 Jan 2019 17:13:28 -0800 (PST)
MIME-Version: 1.0
From: Watson Ladd <watson@cloudflare.com>
Date: Tue, 15 Jan 2019 17:13:17 -0800
Message-ID: <CAN2QdAGyvhDG=PjqUjQ4OdjKvTtN_zGxdNf3iKGdN+tHeDRAkw@mail.gmail.com>
To: tls@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/h6DiWQvw7Cc0TXUtc7fNfB0fFNg>
Subject: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 16 Jan 2019 01:13:31 -0000

Dear TLS WG,

While we were implementing delegated credentials we came up with the
following two problems. I thank David Benjamin for communicating the
first to me.

The first is that a delegated credential is pinned to a particular
version of TLS. Unfortunately this means that the rollout of a new
version of TLS (which libraries consider that they can do on their
own) makes an existing set of delegated credentials unusable, and the
signer of delegated credentials needs to accept a new version of TLS
as valid before the extension can be used with a new version. This is
similar to the issues prompting
draft-wood-tls-external-psk-importer-00 where PSKs depend on
negotiated parameters, and thus are difficult to use in practice.

The second is that the DelegatedCredential indicates the algorithm
that was used to sign it. Someone who is a bit careless when
implementing might take that literally with the result that they
verify a DelegatedCredential with RSA algorithm and the certificate is
really an ECDSA certificate. I'll submit a PR with text for security
considerations/rewording the verification steps.