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

[Stephen Farrell <stephen.farrell%cs.tcd.ie@localhost>]

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