Re: [TLS] Updated EdDSA in TLS drafts

[Ilari Liusvaara <[e-mail]>]

On Tue, Jun 09, 2015 at 10:33:33AM +0200, Simon Josefsson wrote:
> Again, many thanks for feedback Ilari!
> 
> Ilari Liusvaara <[e-mail]> writes:
> 
> > On Mon, Jun 08, 2015 at 11:52:23AM +0200, Simon Josefsson wrote:
> >> Hello.
> >> 
> >> I've updated my EdDSA-in-TLS draft to clarify the choice of
> >> HashAlgorithm that goes together with the EdDSA SignatureAlgorithm,
> >> please see:
> >> 
> >> https://tools.ietf.org/html/draft-josefsson-tls-eddsa-01
> >
> > What hash algorithm is internally used? EdDSA does not fix that
> > (Ed25519 does fix it to SHA-512).
> 
> 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.

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

> > Does more need to be said about how R and S are packed into single
> > blob for signature (concatenate)?
> 
> I'm hoping draft-josefsson-eddsa-ed25519 already covers that.

Oh yeah.

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

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

Or maybe buffering doesn't really matter.

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


-Ilari