Subject: [saag] Using ED25519 in SSHFP Resource Records - draft-moonesamy-sshfp-ed25519-00

From: S Moonesamy <[email-masked]>
Date: Tue, 04 Feb 2014 11:20:40 -0800

Hello,

As a FYI:

    The Ed25519 signature algorithm has recently been implemented in
    OpenSSH.  This document updates the IANA "SSHFP RR Types for public
    key algorithms" registry by adding an algorithm number for Ed25519.

http://tools.ietf.org/html/draft-moonesamy-sshfp-ed25519-00

Regards,
S. Moonesamy

---

From: Yoav Nir <[email-masked]>
Date: Sun, 23 Feb 2014 11:52:56 +0000

Hi, SM

The draft looks fine, but I have to ask, why do you define both ED25519-with-SHA256 and ED25519-with-SHA1 ?

I can't think of somebody writing an implementation today that would have ED25519 but not have SHA256, so I think you might as well require SHA256 unless this is something you can't do per RFC 4255.

Yoav

On Feb 4, 2014, at 9:20 PM, S Moonesamy <[email-masked]> wrote:

> _______________________________________________
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag
> 
> Email secured by Check Point

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 23 Feb 2014 19:03:20 +0000

Thanks for reviewing this Yoav.

SM's been (quite properly) hassling me to figure out what
to do with his draft and I've been slow because I don't
want to do something that turns out to be in conflict with
whatever is done in TLS in particular.

I'd be interested in opinions as to whether that is a real
problem or not.

Thanks,
S.

---

From: Paul Wouters <[email-masked]>
Date: Sun, 23 Feb 2014 22:09:57 -0500

> I'd be interested in opinions as to whether that is a real

I agree with Yoav that we really should not write new documents that specify SHA1.

Other small items regarding the draft:

	RFC 4255 [RFC4255] defines a new DNS resource record, "SSHFP",

I would remove the word "new". It just defines it. And I would argue that 2006 is not "new".

I would not mention client behaviour in section 2 introduction, but instead just define the new IANA entry and refer to RFC 4255 Section 2 for the usage policy.

I would also remove the introduction paragraph of section 3 and just refer back to 4255 using those last two lines.

Can this document also add an SSHFP Algorithm Number for ECDSA?

Can this document be changed to add the SHA2-256 fingerprint type in general for all algorithms? That way, the RSA and DSS defined Algorithm Numbers can also
switch from SHA1 to SHA2-256.

Paul

---

From: S Moonesamy <[email-masked]>
Date: Mon, 24 Feb 2014 10:41:32 -0800

Hi Yoav,

Thanks for the feedback.

At 03:52 23-02-2014, Yoav Nir wrote:
>The draft looks fine, but I have to ask, why do you define both 
>ED25519-with-SHA256 and ED25519-with-SHA1 ?

The OpenSSH ssh-keygen generates the SSHFP RRs.  In the case of 
ED25519 it will generate  SHA1 and SHA256 fingerprints.

>I can't think of somebody writing an implementation today that would 
>have ED25519 but not have SHA256, so I think you might as well 
>require SHA256 unless this is something you can't do per RFC 4255.

My initial focus was the SHA256 fingerprint.  I could not find a 
valid argument for not including SHA1 in the codepoint assignment 
request.  There isn't any constraint in RFC 4225.  I'll have to 
discuss the matter with a few people before saying "yes" to "require SHA256".

Regards,
S. Moonesamy

---

From: S Moonesamy <[email-masked]>
Date: Mon, 24 Feb 2014 19:41:12 -0800

Hi Paul,

Thanks for the feedback.

>I agree with Yoav that we really should not write new documents that 

Ok, I'll remove SHA1.

>I would remove the word "new". It just defines it. And I would argue 

Agreed.

>I would not mention client behaviour in section 2 introduction, but 
>instead just define the new IANA entry and refer to RFC 4255 Section 
>2 for the usage policy.

That works for me.

>I would also remove the introduction paragraph of section 3 and just 
>refer back to 4255 using those last two lines.

I preferred to have some short text and then "Please refer to RFC 
4255 [RFC4255]" to encourage the reader to at least give some thought 
to Security Considerations.  I'll go with the above suggestion unless 
there are comments to the contrary.

>Can this document be changed to add the SHA2-256 fingerprint type in 
>general for all algorithms? That way, the RSA and DSS defined 
>Algorithm Numbers can also

That would take more time as it might have to be done in a Standards 
Track document.  I would like to keep the code point assignment and 
the above separate.  I'll go through the relevant RFCs again and see 
what needs to be done.  I'll write some text and figure out the path 
afterwards.

Regards,
S. Moonesamy