[TLS] Adding a new signature scheme

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Fri, 07 August 2015 05:40 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CED721B363E for <tls@ietfa.amsl.com>; Thu, 6 Aug 2015 22:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 0QfxOgPy3ySy for <tls@ietfa.amsl.com>; Thu, 6 Aug 2015 22:40:00 -0700 (PDT)
Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi []) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51541B363B for <tls@ietf.org>; Thu, 6 Aug 2015 22:39:59 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi []) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id DA1A4699C2 for <tls@ietf.org>; Fri, 7 Aug 2015 08:39:56 +0300 (EEST)
Date: Fri, 7 Aug 2015 08:39:56 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: tls@ietf.org
Message-ID: <20150807053956.GA5394@LK-Perkele-VII>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ZikDSZdh3pEi3ISWgXT-OzNoBRc>
Subject: [TLS] Adding a new signature scheme
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: Fri, 07 Aug 2015 05:40:03 -0000

This is about adding a new signature primitive (such as the
(eventual) CFRG scheme).

There are basically two issues:

1) Do we allocate new ciphersuite codepoints or not? So far
each certificate algorithm in ciphersuite has corresponded
to only one signature algorithm.

Implications of new codepoints:
- More ciphersuites (about 11).
- Needs TLS 1.2+ anyway, because the ciphers are presumably
  AEAD mode and those need TLS 1.2+.
- Keep existing semantics.

Implication of reusing ECDSA codepoints.
- No new ciphersuites
- Needs TLS 1.2+
- Redefines existing semantics a bit.

2) What does the SignatureAndHashAlgorithm.hash mean exactly? The
TLS 1.2 RFC isn't specific enough.

I see two choices:
a) The field sets hash (prehash) to perform before passing the
   hash to be signed (the description of "none" and description of
   Certificate Verify message hints at this interpretation).
b) The field parameterizes the signature scheme in some scheme-
   specific way (but what would "none" mean in context of this,
   the scheme having no hash parameters?).

All the existing schemes are compatible with interpratation a).

But for proposals for CFRG scheme: All proposed schemes have a
hash parameter (the only one or one of two) that is incompatible
with interpretation a):

1) Only one hash that does not prehash the message.
2) Two hash functions, one prehash (can be identity) and
   one internal hash. Prehash can be chosen per-signature.
3) Two hash functions, one prehash (can be identity) and
   one internal hash. Prehash is not indicated, so one
   has to be careful changing it.

So if interpretation a) is the correct one, one presumably has to
fix the internal hash in signature scheme codepoint (E.g. to
SHA-512 for signature scheme #4).