Re: [TLS] New curves work and TLS

Dave Garrett <davemgarrett@gmail.com> Thu, 15 October 2015 19:17 UTC

From: Dave Garrett <davemgarrett@gmail.com>
To: tls@ietf.org, Ilari Liusvaara <ilariliusvaara@welho.com>
Date: Thu, 15 Oct 2015 15:17:51 -0400
User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; )
References: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20151015130939.GA19330@LK-Perkele-V2.elisa-laajakaista.fi>
MIME-Version: 1.0
Content-Type: Text/Plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-Id: <201510151517.52101.davemgarrett@gmail.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/uof54b17UZOFyq6dr2k24j-JOyE>
Subject: Re: [TLS] New curves work and TLS
Precedence: list

On Thursday, October 15, 2015 09:09:39 am Ilari Liusvaara wrote:
> So, there are four primitives: Ed25519, Ed25519ph, Ed448 and
> Ed448ph. And keys MUST NOT be mixed between those.
> 
> I propose the following:
> - EdDSA uses one SignatureAlgorithm value (5?[1]).
> - There will be new curves for EdDSA, one for Ed25519/Ed25519ph and
>   another for Ed448/Ed448ph
> - If there is ever EdDSA instantiation with Edwards448 curve (the same
>   one Ed448 uses) with another KDF, it gets a new curve distinct from
>   Ed448/Ed448ph.
> - The HashAlgorithm is always 0, or the HashAlgorithm is always 0 or
>   value matching the prehash (but the prehash is always done once[2]).
>   [TBD: resolve this]

I've been thinking about the issue of how to handle SignatureAndHashAlgorithm values better. I think this time, I'd like to propose going the opposite way we'd normally want to move: let's consider enumerating all combinations of HashAlgorithm+SignatureAlgorithm instead of having independent values. We're moving to signature algorithms that don't have arbitrary hashes, so the current system isn't really ideal anymore.

Current draft:
https://tools.ietf.org/html/draft-ietf-tls-tls13-09#section-6.3.2.1  (text)
https://tools.ietf.org/html/draft-ietf-tls-tls13-09#page-88  (full registry)
----------------------------------------
enum {
    none(0),
    md5_RESERVED(1),
    sha1(2),
    sha224_RESERVED(3),
    sha256(4), sha384(5), sha512(6),
    (255)
} HashAlgorithm;

enum {
    anonymous_RESERVED(0),
    rsa(1),
    dsa(2),
    ecdsa(3),
    rsapss(4),
    (255)
} SignatureAlgorithm;

struct {
    HashAlgorithm hash;
    SignatureAlgorithm signature;
} SignatureAndHashAlgorithm;
----------------------------------------

Proposed replacement backwards-compatible registry:
----------------------------------------
struct {
    anonymous_RESERVED(0x0000),
    rsa_nohash(0x0001),
    dsa_nohash(0x0002),
    ecdsa_nohash(0x0003),
    rsapss_nohash(0x0004),
    md5_RESERVED (0x0100..0x01FF),
    rsa_sha1(0x0201),
    dsa_sha1(0x0202),
    ecdsa_sha1(0x0203),
    rsapss_sha1(0x0204),
    sha224_RESERVED (0x0300..0x03FF),
    rsa_sha256(0x0401),
    dsa_sha256(0x0402),
    ecdsa_sha256(0x0403),
    rsapss_sha256(0x0404),
    rsa_sha384(0x0501),
    dsa_sha384(0x0502),
    ecdsa_sha384(0x0503),
    rsapss_sha384(0x0504),
    rsa_sha512(0x0601),
    dsa_sha512(0x0602),
    ecdsa_sha512(0x0603),
    rsapss_sha512(0x0604),
    (0xFFFF)
} SignatureAndHashAlgorithm;
----------------------------------------

New values could be assigned specific combinations as needed. This would also let hashes & signatures be deprecated independently easily, e.g. allow rsa_sha1 but prohibit rsapss_sha1 (it's new, so it probably should be from the start).


Dave

[TLS] New curves work and TLS Ilari Liusvaara
Re: [TLS] New curves work and TLS Dave Garrett
Re: [TLS] New curves work and TLS Eric Rescorla
Re: [TLS] New curves work and TLS Ilari Liusvaara
Re: [TLS] New curves work and TLS Sean Turner
Re: [TLS] New curves work and TLS Ilari Liusvaara