Re: [TLS] Updated EdDSA in TLS drafts

[Simon Josefsson <[e-mail]>]

Ilari Liusvaara <[e-mail]> writes:

>> Yeah.  I think this is actually a larger question: will EdDSA be defined
>> with other curves than Ed25519?  If no, the only interesting algorithm
>> to specify is Ed25519.  If yes, the parameter choices needs to be
>> encoded somehow.  The hash isn't the only parameter to EdDSA.
>
> The requirements of EdDSA are so bizarre that I don't think there are
> realistic curves to use with that besides Edwards form of Curve25519.

Okay.  If that is really the case, we should specify Ed25519 directly
and don't bother with EdDSA.  But if there is a chance that we'll see
other curves used with EdDSA, then it would be better to specify EdDSA
and instantiate it for Ed25519 with some parameter choice.

I believe this is an important question, but I lack knowledge to make a
decision.

> (Edwards form of M-379 might come the closest, but the needed 760-bit(!)
> hash function is pretty much unobtabnium).

Can't you build one with a keyed PRF?

>> > More ciphersuites. Eew.
>> 
>> Yeah.  I offer this approach in the rare case that it might actually
>> prove less complex to implement, and that some might find it useful.  I
>> suspect it might get shot down during further discussions.
>
> I checked the TLS 1.2 spec:
> - If advertised ciphersuites and signature_algorithms conflict, latter
>   takes precedence.
> - If selected ciphersuite and signature algorithm in struct
>   DigitallySigned conflict, latter takes percedence.
>
> This means TLS_DHE_RSA_* key exchange can end up being signed with ECDSA,
> if client told it supports ECDSA.

While a bit ugly, language could be added to the TLS-Ed25519 document
saying what to do in each case.  I don't propose to do this, though,
just saying that the problem above could be solved if it was really
important.

>> > Also, in TLS 1.2 Client CertificateVerify (does not apply to server
>> > certificate, nor either certificate in TLS 1.3) signs the entiere
>> > handshake so far. That could be many kilobytes in size, spread over
>> > multiple message.
>> 
>> Some implementations buffer the entire handshake to deal with this
>> problem.  I'm not sure what to recommend generally, or if this document
>> has to care about this.
>
> I was thinking maybe PRF-hash, since one has that running anyway (for
> session_hash and finished) and it better be secure enough.

Ah.  Would you then sign the PRF-hash with SHA-512 for Ed25519?

> Or maybe buffering doesn't really matter.

I think not.  Let's see.

>> >> The other feedback I have received is to reuse the existing ECDSA
>> >> ciphersuites.  I think this is a good idea, and believe it would likely
>> >> work, but it is a fundamentally different approach.  I created another
>> >> draft to describe that approach, now published as:
>> >> 
>> >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-00
>> >
>> > TLS 1.0 and 1.1 lack algorithm specification for signature, which is
>> > very useful for merging ciphersuites like this. In theory, one could
>> > infer the algorithm from certificate, but I don't think that kind
>> > of tricks are very often pulled off.
>> 
>> RFC 4492 defines SignatureAlgorithm for TLS 1.0 and 1.1, or am I
>> misunderstanding what you are saying?
>
> I mean the explicit signature algorithm in struct DigitallySigned. That
> was new in TLS 1.2.
>
> Without that, one is left guessing the algorithm from the certificate,
> which is quite unclean.

Ah, right.  Maybe there should be words to that effect: If TLS 1.0 or
1.1 then look at the certificate to find out the algorithm to use.

Thanks again,
/Simon