Re: [TLS] Early code point assignments for 25519/448 curves

[Ilari Liusvaara <[e-mail]>]

On Mon, Nov 23, 2015 at 01:16:35PM -0800, Martin Thomson wrote:
> On 23 November 2015 at 12:56, Yoav Nir <[e-mail]> wrote:
> > It’s been suggested that as long as the CFRG signature curves
> > document is not finalized, we should wait with the eddsa_* ones.
> > I don’t believe so. Anything in any draft is subject to change up
> > to the time it’s published [...]
> 
> In your opinion, do you see the semantics of the codepoints changing
> in any meaningful way?  It's one thing to say "accept the risks", but
> if anyone thinks that there are necessary changes forthcoming, that
> would give me pause.  If everyone says that it's highly unlikely, I'm
> supportive of the notion that we get a codepoint.

My personal view is (I haven't asked Simon about this) is that:
- Ed25519 is currently technically stable. There seems to be consensus
  not change it in any way that would break verification.
- Ed448 is unimplementable right now due to two missing functions.
- Once those two are missing (there is call for proposals this
  week) functions are decided, Ed448 should become technically
  stable.

> Are we happy that we will only be needing the PureEdDSA variants and
> that no-one will be asking for the HashEdDSA versions?  I ask because
> I've heard it suggested (I think Karthik mentioned this) that we might
> want to sign the transcript directly in TLS 1.3 rather than rely on
> collision-resistance of the selected hash function.  That would be
> harder without access to HashEdDSA.

I would say that using HashEdDSA is a bad idea in that case. HashEdDSA
has fixed "prehash" function and if that hash breaks, the HashEdDSA
scheme breaks (the same is not true w.r.t. hash function for PureEdDSA).

Also, the prehashes might not be the same for Ed25519ph and Ed448ph,
plus I consider interfaces that let one use this dangerous (IUF
signing is dangerous!).

If one wants to have the entiere transcript signed in reasonable way,
one would have to implement hash firewalling at TLS level and require
PureEdDSA.

If doing that, might also be good idea to throw a prefix that screws 
many formats ('1E 80 00 00' might be one, it should screw at least ASN.1,
JSON and CBOR).


Also, the absence of indication of PRF hash in the signed data[1] bugs
me, since I need to assume CCR (CR of both hashes does not imply CCR)
in order to show security.




[1] Heck, that indication was in my original proposal (I didn't
quite understand its significance back then).




-Ilari