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

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 May 2014 09:53:50 +0100

Hi SM, all,

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;-)

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

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?

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

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

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.

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's just in the acks, so I'm fine with it. But you could add
a ref.

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?

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

Thanks,
S.

---

From: S Moonesamy <[email-masked]>
Date: Thu, 01 May 2014 07:25:45 -0700

Hi Stephen,
>this was answered before;-)

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

>hashed is only defined in the SSH code. Is that the case?

Yes.

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

>even to a draft (though not sure there's a stable one

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.

>that are hashed as well and this does not.

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

>answer regardless of whether or not that means changes

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

>      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

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.

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

>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

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 01 May 2014 15:43:50 +0100

Hiya,

I'm ok with moving ahead on the codepoint, but just one
follow-up: if we do have 2 interoperable implementations
could one of those maybe provide example public keys as
they've hashed them (and a matching hash example of course).

If that's easy then I think it'd be good to do even if
there's no current good spec on the format. (I do expect
we'll end up with one later, but could be a while all
right.)

I'll start the IETF LC now though and note this in that
so's we're clear that we're clear if nobody comments on
this during IETF LC (the IESG will defo. spot this:-)

S.

On 01/05/14 15:25, S Moonesamy wrote:
> Feel free to ask questions about the draft even if they have been asked
> previously.
> 
> 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.
> 
> format.  There is a possibility that another code point might be needed
> if someone goes and implement the thing differently.
> 
> intended as Informational.  It's better than having an undocumented code
> point in use.
> 
> I would like other implementers (and anyone else) to comment about this
> even if it can end up being a problem for me.
> 
> 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)
> I am okay with moving it to an informative reference or not having the
> reference.
> 
> 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 
> 
>

---

From: S Moonesamy <[email-masked]>
Date: Thu, 01 May 2014 08:07:27 -0700

Hi Stephen,
>they've hashed them (and a matching hash example of course).

I'll look into that and get back to you before the end of the Last Call.

>we'll end up with one later, but could be a while all

I'll get the information and you get to make the call. :-)

>this during IETF LC (the IESG will defo. spot this:-)

Thanks.  Let's see what the IESG says. :-)

Regards,
S. Moonesamy