Subject: [TLS] Adding a new signature scheme

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 7 Aug 2015 08:39:56 +0300

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).

-Ilari

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 12 Aug 2015 23:26:00 +0200

> This is about adding a new signature primitive (such as the

I believe these aspects were already discussed in the EdDSA threads.  It
would be useful to establish consensus around these topics.

> - Redefines existing semantics a bit.

The feedback I got on draft-josefsson-tls-eddsa from several people was
to reuse the ECDSA codepoints instead of defining new ciphersuites.  I
am currently (mildly) in favor of that, as it appears to imply less work
for everyone.  I have since published draft-josefsson-tls-eddsa2 that
adopts that approach.  I decided to fork the draft so both are available
and can be evaluated on its own.  They are available here:

https://tools.ietf.org/html/draft-josefsson-tls-eddsa
https://tools.ietf.org/html/draft-josefsson-tls-eddsa2

> TLS 1.2 RFC isn't specific enough.

I believe the document introducing a new signature primitive must be
clear about this.  I don't believe TLS 1.2 mandates any particular
interpretation here, so it is up to the new primitive to define
semantics.

I believe the choice is not particular interesting, as long as the
specification is clear about what is intended.  For example,
draft-josefsson-tls-eddsa uses "none", and draft-josefsson-tls-eddsa2
uses "sha512", and both are in their own way a bit redundant.

> SHA-512 for signature scheme #4).

I don't think we can come any closer to my discussion above until we
know what the CFRG outcome is.

/Simon