Re: [TLS] Updated EdDSA in TLS drafts

[Simon Josefsson <[e-mail]>]

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.

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

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

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

>> 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 don't know if mixing curves used for key exchange and curves used
> for signing is a good idea. Signing is much more complicated than
> ECDH.

Agreed.  I've changed to use a separated NamedCurve registration.

> The point format used by EdDSA has very little to do with montgomery X
> (it does not have the same number of bits). The point format is little-
> endian encoding of 2^(b-1)*lsb(x)+y, b is 256 for Curve25519, and lsb(x)
> is x mod p mod 2. X and Y are edwards coordinates.

Right, this was just broken.  I've changed it to use a separate
ECPointFormat registration for EdDSA public keys.

> Also, notes about not seemingly fixing the hash, encoding of signature
> and TLS 1.2 client certs apply.

I've changed to use "sha512" instead of "none" in the latest update.

>> For more context, related to the above is a draft describing OIDs for
>> EdDSA for use in PKIX certificates as public keys and a signature
>> algorithm:
>> 
>> https://tools.ietf.org/html/draft-josefsson-pkix-eddsa-00
>
> Repeating the definitions sounds bit odd, one could presumably just
> state what to put in each field.

I find repeating this establish the terminology a bit better.  There are
so many structures in RFC 5280 that it is hard to find the right one.
Also, I mostly stole this text from some other RFC.

> Public key encoding? Edwards points have two coordinates. The usual
> EdDSA encoding (32 octets for Curve25519)?

I was hoping draft-josefsson-eddsa-ed25519 takes care of define a
canonical public key encoding.

> Hash algorithm? Note that public keys are not compatible across hash
> algoritmhs. Fixed to SHA-512?

Yes, I've changed my opinion and think that the HashAlgorithm should
probably be sha512 to indicate Ed25519-SHA-512.

> Signature encoding? Presumably the same as on TLS side.

Again, hoping to shift this burden on draft-josefsson-eddsa-ed25519.  I
agree there could be clearer text on this.

Cheers,
/Simon