Re: [TLS] Simplifying signature algorithm negotiation

Brian Smith <brian@briansmith.org> Sat, 16 January 2016 00:08 UTC

Return-Path: <brian@briansmith.org>
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 B3FB11B3422 for <tls@ietfa.amsl.com>; Fri, 15 Jan 2016 16:08:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 sUM194NJj5R3 for <tls@ietfa.amsl.com>; Fri, 15 Jan 2016 16:08:34 -0800 (PST)
Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) (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 D07611B3421 for <tls@ietf.org>; Fri, 15 Jan 2016 16:08:33 -0800 (PST)
Received: by mail-ob0-x233.google.com with SMTP id is5so123436525obc.0 for <tls@ietf.org>; Fri, 15 Jan 2016 16:08:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=G9Unnb/T64QfZOTpK5IJyImkeizpRyvx0lu0PcJHv4w=; b=FMCVTWb8PeWRpJfaxFAVw4gH/xDhtD0wv5mR3lYrBf+4dqOnL2k2VeYNlXKRUrIBlR 5t1Gk/p6ELotd1OiofEKyw1QNQDMdKF60uyOeTR1evTgqV4H68uvTPw6RG7jeLPRYcav uAZtsDW8QElXImxSq3mUFpRh6KKdO3VM82q/YVcr4N10JYa8f5ZaFMzMBfzFEAO/EKOb +CEyr3hSleZfKOaYAWFdwRAg6W/QopzTDX5aqnEDptmHHAUrmy9tdUUpEOBbbMFgyRZw 1ua6yauWItgjsccLboXZuDUO9VJA/6MeVSh1gDHtroR1nw3mOY9YI3e3qAyeaVD973si Tsrw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G9Unnb/T64QfZOTpK5IJyImkeizpRyvx0lu0PcJHv4w=; b=BqOh1iIFlcuAMIibzibSSG7N78NZFiB/bMi864TRKGbqGWbiweVi3/F90vBbAtrJJX OZgFMCrj3/wPup9qtiJHqAQd2XhGAUrjVTjh0agezX22Ru4ahLkr6Ig1bBcCILlxp2v2 +cGA84PXLrZ76KYCyUE/7JOYeK18oG3NpxpO2HBbqylscL8Ab0bUdxlL/xInLag8sKkX TmA9KHx/hvHtXxFCjHaZFcRDv582dXoisjF3NYw13ASm7Jea4FXO7YeFUboRMscH79rf 9tq+4fbzQdYkZwNrwCT62xqnCfwFSj/I/FWsGN7gwfahYFqxEK4KGm0mNpN2Lhl72Pxb mkJA==
X-Gm-Message-State: ALoCoQmjhJbCy+U7iOF/CDnPns+b1uGmXfvMzzRkczxzdKLMHLLgO/L1hshIH9/7zb3QLlbfAXu12yxkdBbRv8ru/qfQYkC/DA==
MIME-Version: 1.0
X-Received: by 10.60.177.67 with SMTP id co3mr11058065oec.62.1452902913253; Fri, 15 Jan 2016 16:08:33 -0800 (PST)
Received: by 10.76.170.225 with HTTP; Fri, 15 Jan 2016 16:08:33 -0800 (PST)
In-Reply-To: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com>
References: <CAF8qwaCpYqs7ELDcRzXveLLjpL+d-CmBczkxPweh6_RVE1aDeA@mail.gmail.com>
Date: Fri, 15 Jan 2016 14:08:33 -1000
Message-ID: <CAFewVt7f4pAbJ_Z3s0w_Qiwdi-cGM-39BnPV5-qF3PLOdpFw0A@mail.gmail.com>
From: Brian Smith <brian@briansmith.org>
To: David Benjamin <davidben@chromium.org>
Content-Type: multipart/alternative; boundary=047d7bd7646809bcf80529685248
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/W9gBhZ7U8kV3--qmTSfp5kf9Wa0>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Simplifying signature algorithm negotiation
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: <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: Sat, 16 Jan 2016 00:08:35 -0000

David Benjamin <davidben@chromium.org>; wrote:

> 4. Deprecate ecdsa_sha256, etc., in favor of new
> ecdsa_{p256,p384,p521}_{sha256,sha384,sha512} allocations. The old ecdsa_*
> values are for TLS 1.2 compatibility but ignored in TLS 1.3. Although this
> introduces new premultiplications, it’s only 9 values with the pruned TLS
> 1.3 lists. I think this is worth 9 values to keep NamedGroups separate.
>

Have you considered the possibility of using this mapping?:

TLS 1.2's { ecdsa, sha256 } is TLS 1.3's ecdsa_p256_sha256.
TLS 1.2's { ecdsa, sha384 } is TLS 1.3's ecdsa_p384_sha384.
TLS 1.2's { ecdsa, sha512 } is TLS 1.3's ecdsa_p521_sha521.

Then:
1. You don't have to define any new values.
2. The extension size would be smaller.
3. You get better interoperability with TLS 1.2's NSA Suite B profile [1].
(I don't have any particular affinity for that profile other than it seems
to have made choices that have historically been shown to be above average,
and it might be a good idea to avoid interop failure with other
implementations that might have a special affinity for it.)

5. Add new allocations for eddsa_ed25519, eddsa_ed448, and
> rsapss_{sha256,sha384,sha512}.
>

This seems like a good idea to me.


> [1] We’re stuck with RSA-PSS's generality, so that'll need some mapping to
> a subset of X.509's RSA-PSS.
>

I believe this is already largely taken care of in TLS 1.3 by fixing all
the parameters to be a function of the digest algorithm used for the
message.

- ecdsa_p256_sha384
> - ecdsa_p256_sha512
> - ecdsa_p384_sha256
> - ecdsa_p384_sha512
> - ecdsa_p521_sha256
> - ecdsa_p521_sha384
>

The subset of your proposed values I listed above do not seem helpful. For
example, a P-256 signature of a SHA-384 or SHA-512 hash is going to get
truncated to 256 bits.


> 0xfe00-0xffff - reserved for private use, compatible with existing
> HashAlgorithm reservation.
>
> [3] If a TLS 1.2 implementation sees 0x0701 and interprets it as {hash(7),
> RSA}, they should ignore it since hash 7 doesn't exist.
>

I think we should expect more pure ECC (no RSA) deployments soon. In that
case, it would be better if new ECC-based values used the value "ECDSA" (3)
instead of RSA (1) so that TLS 1.2 implementations do not misinterpret them
as support for RSA.

[1] https://tools.ietf.org/html/rfc6460

Cheers,
Brian
-- 
https://briansmith.org/