[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
- [TLS] signature algorithm ID re-use Nikos Mavrogiannopoulos
- Re: [TLS] signature algorithm ID re-use Martin Thomson
- Re: [TLS] signature algorithm ID re-use Nikos Mavrogiannopoulos