Re: AD review of draft-moonesamy-sshfp-ed25519-01

[S Moonesamy <sm+ietf%elandsys.com@localhost>]

Hi Stephen,
At 01:53 01-05-2014, Stephen Farrell wrote:
> I've agreed to AD sponsor this and so have done my AD review
> and have one question before I start IETF LC. Apologies if
> this was answered before;-)

Feel free to ask questions about the draft even if they have been 
asked previously.

> I'm still concerned if the format of the thing that is
> hashed is only defined in the SSH code. Is that the case?

Yes.

> If so, what happens when someone else implements and does
> it differently and/or when we do have an ED25519 public
> key format in an RFC that's not the same as in the current
> code? Do we need another code point then?

There is a Dropbear implementation (see 
https://matt.ucc.asn.au/dropbear/CHANGES ).  There seems to be 
support in TTSSH ( 
http://sourceforge.jp/ticket/browse.php?group_id=1412&tid=33263 
)   Currently, there are two implementations doing the same 
thing.  That's good enough to consider assigning a code point.

Ideally, there would be an ED25519 public key format documented in a 
RFC.  There doesn't seem to be interest in standardizing a public key 
format.  There is a possibility that another code point might be 
needed if someone goes and implement the thing differently.

> I'd be just fine if you wanted to add the public key
> format being used by SSH here and we add a new codepoint
> later if one is needed because we standardise a different
> format. Or, I'd be fine if you want to add a reference
> to some other specification (not necessarily an RFC) or
> even to a draft (though not sure there's a stable one
> there today).

There isn't an adequate specification.  I doubt that there would be 
agreement on standardizing on a format.  That's why the draft is 
intended as Informational.  It's better than having an undocumented 
code point in use.

I could add some text under Security Considerations:

  The public key fingerprint used for ED25519 in the SSHFP Resource 
Record relies
  on an undocumented OpenSSH public key format.

> I note that RFC6594 contains examples of public key values
> that are hashed as well and this does not.

Yes.  If I recall correctly I did not provide an example because of the above.

> I don't believe there's a shortage of codepoints here
> so adding another later isn't a problem from that POV
> but not sure what the implementers would want to do.
>
> But this question will be asked so I'd like to know the
> answer regardless of whether or not that means changes
> to this draft.

I would like other implementers (and anyone else) to comment about 
this even if it can end up being a problem for me.

> The rest are nits that can be fixed now or later, but good
> to get done before IESG eval.
>
> 1) ID nits has two things:
>
> 1.1)
>   == Unused Reference: 'RFC6594' is defined on line 109, but no explicit
>      reference was found in the

That is because I added a credit for the author of that RFC.

> That's just in the acks, so I'm fine with it. But you could add
> a ref.

I'll drop the RFC number from the text as I prefer to provide 
references which a reader might find useful to understand the document.

> 1.2)
>   == Unused Reference: 'FIPS180-4' is defined on line 113, but no
>      explicit reference was found in the text
>
> What's up there? How can a normative ref not be referred to?

The reference was dropped when I removed a paragraph.

I'll have:

  The SSHFP Resource Record for the ED25519 public key with SHA-256
  fingerprint [FIPS180-4] would, for example, be:

I am okay with moving it to an informative reference or not having 
the reference.

> 2) The Reference for ed25519 isn't great. Isn't there anything better
> than that web site to add as well? (Keep the URL though.)

I spent some time trying to find the most appropriate reference for 
ed25519 as I expected questions about that.  Most of the web pages I 
read reference the original paper ( 
http://ed25519.cr.yp.to/ed25519-20110926.pdf ).  I'll encourage 
people to review that and raise objections, if they consider it 
important, as it might help other people who are looking for an 
appropriate reference for ed25519.

Regards,
S. Moonesamy