[TLS] signature algorithm ID re-use

Nikos Mavrogiannopoulos <nmav@redhat.com> Tue, 04 July 2017 14:43 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 835F1131453 for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 07:43:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.421
X-Spam-Level:
X-Spam-Status: No, score=-1.421 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=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 3fvQNwWmuGPT for <tls@ietfa.amsl.com>; Tue, 4 Jul 2017 07:43:32 -0700 (PDT)
Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (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 A07AA131635 for <tls@ietf.org>; Tue, 4 Jul 2017 07:43:31 -0700 (PDT)
Received: by mail-wm0-f44.google.com with SMTP id i127so140731742wma.0 for <tls@ietf.org>; Tue, 04 Jul 2017 07:43:31 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:mime-version :content-transfer-encoding; bh=EN5SX2nYuPlOY6/WW5BjfsKZ/uhrcr0LIq1/2ZGbId8=; b=ZWJtMw3G8k1DAcOOoxPkzwgj1e84ymP3kOf1h4EMgiOxf/fiA/y4yEgjDULmYedhW3 qdYxB1M2eF94wmas7DEutJkjWImlim/0im+IAt3W+P8RSdFoPmDW++aA8tOlmCXwYTyH Q8O0ASC4D8R1fWUp9Qc43yam2C2UuuMsvv00coIOj957jjQKKUjhvFNfj9JY+0SoXhBR t2LFK++zkz36V4KKcJQIgqlLhn3ZALhXNnPUrZArlHOPfNPlY0ItfYFhcaXR3SZiZtWU KgA8M/qUeKCP7CTeVSlbQep0E3BvYIkgCZkazbhukC7/QXLVcd24SlFaMcNCWUu2aiym kW+w==
X-Gm-Message-State: AKS2vOxPo2SJT2xM5NA9qhE2nZOGEhA+gsr8nU/+vyheBUNmKWyyofXK 3ivpnX1HVYsrDu0yCPjI4A==
X-Received: by 10.28.167.207 with SMTP id q198mr19784586wme.36.1499179409906; Tue, 04 Jul 2017 07:43:29 -0700 (PDT)
Received: from dhcp-10-40-1-102.brq.redhat.com (nat-pool-brq-t.redhat.com. [213.175.37.10]) by smtp.gmail.com with ESMTPSA id m188sm26363170wmg.34.2017.07.04.07.43.29 for <tls@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 04 Jul 2017 07:43:29 -0700 (PDT)
Message-ID: <1499179408.2892.13.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: tls@ietf.org
Date: Tue, 04 Jul 2017 16:43:28 +0200
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25)
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/PTCNmUvLmjbPhoss1Epl6gn4EIg>
Subject: [TLS] signature algorithm ID re-use
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 04 Jul 2017 14:43:33 -0000

Hi,
 The latest TLS 1.3 draft re-uses the sha256(4), sha384(5), sha512(6)
with ecdsa(3) signature algorithms IDs for the following signature
algorithms:
    /* ECDSA algorithms */
    ecdsa_secp256r1_sha256(0x0403),
    ecdsa_secp384r1_sha384(0x0503),
    ecdsa_secp521r1_sha512(0x0603),

These are similar but have different semantics; as indicated by their
name they can be used with a single curve. That makes the handshake
conversation something like:

Client: Use ecdsa_secp256r1_sha256 under TLS 1.3 or ecdsa with
whichever curve and sha256 if under TLS 1.2.

That apart from being confusing, means that a client which is willing
to fallback to TLS 1.2 cannot restrict its options to
ecdsa_secp256r1_sha256 (i.e., require the secp256r1 curve for
signatures).

One could work-around it, by utilizing the elliptic curves extension,
but that has also different semantics under TLS 1.3.

So my question is why not go for the simpler approach and create new
identifiers for the new signature algorithms? (similarly to RSA-PSS).
Is there an advantage of re-using the ECDSA signature algorithm
identifiers to mean something different in TLS 1.3? Was there some
discussion on the topic on the list?


[0]. https://github.com/tlswg/tls13-spec/issues/1035