Subject: Re: Last Call: draft-green-secsh-ecc (Elliptic-Curve Algorithm Integration in the Secure Shell Transport Layer) to Informational RFC

From: Sean Turner <[email-masked]>
Date: Mon, 08 Jun 2009 21:25:12 -0400

The IESG wrote:
> The IESG has received a request from an individual submitter to consider
> the following document:
> 
> - 'Elliptic-Curve Algorithm Integration in the Secure Shell Transport 
>    Layer '
>    <draft-green-secsh-ecc-08.txt> as an Informational RFC
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-07-06. Exceptionally, 
> comments may be sent to [email-masked] instead. In either case, please 
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-green-secsh-ecc-08.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=15220&rfc_flag=0

A couple of comments:

Other ECC documents in the IETF (TLS, SMIME, PKIX) indicate that support 
for compressed keys are MAY while this draft says MUST NOT for ECDSA and 
ECDH keys and MAY for ECMQV.  What was the rationale for this?

Sec 3.1.1: Should the must be MUST in the following: The message hashing 
algorithm must be from the SHA2 family of hash functions [FIPS-180-3] 
and is chosen according to the curve size as specified in Section 6.2.1.

Sec 3.1.2: In TLS/SMIME/PKIX, the signature value (r&s) are integers but 
they are encoded together with the following syntax:
Ecdsa-Sig-Value ::= SEQUENCE {
   r       INTEGER,
   s       INTEGER
}
Any chance of reuse?

Sec 9.1: The TLS, SMIME, and PKIX use the secp* naming for the curves 
instead of nist*.  Any chance we could use the secp* names?

In 9.1: Should the should be SHOULD in the following: These curves 
should always be enabled unless specifically disabled by local security 
policy.

Does the Certicom IPR applies to this ID (it pretty much applies to all 
the other ECC RFCs/IDs)?

spt

---

From: Sean Turner <[email-masked]>
Date: Tue, 09 Jun 2009 09:05:50 -0400

Doug,

Thanks for the quick reply.

Douglas Stebila wrote:
> On 2009-Jun-9, at 11:25 AM, Sean Turner wrote:
> 
>> Other ECC documents in the IETF (TLS, SMIME, PKIX) indicate that 
>> support for compressed keys are MAY while this draft says MUST NOT for 
>> ECDSA and ECDH keys and MAY for ECMQV.  What was the rationale for this?
> 
> Simplicity.  In my opinion, compressed keys provide little benefit in 
> practice.  Certainly for ECDH there's no reason to use them.  I would be 
> willing to consider it as a MAY for ECDSA so that signing public keys 
> can be reused between standards.

I tend to agree.  I think most people are just going to do uncompressed 
and not bother with compressed.  My concern is that somebody is going to 
generate compressed keys use them for TLS sessions (because they are 
allowed) and then not be able to use them for SSH.  I'm not entirely 
sure that people will reuse keys for TLS for SSH, but it might happen. 
I guess I'm asking whether they should be MAY to match all the others 
for interoperability sake?

>> Sec 3.1.2: In TLS/SMIME/PKIX, the signature value (r&s) are integers 
>> but they are encoded together with the following syntax:
> No.  The signature above is encoded using DER encoding of an ASN.1 
> sequence.  There is almost no use of ASN.1 in the secure shell 
> standards, so many SSH implementations may not have code to support DER 
> encoding and decoding.  I prefer to stay with the basic syntax that the 
> secure shell standard provides.  For those that do desire conversion 
> between the two, it is easy to implement given a DER library.

Fair enough I thought I'd give it a shot.

>> Does the Certicom IPR applies to this ID (it pretty much applies to 
>> all the other ECC RFCs/IDs)?
> 
> According to
>     https://datatracker.ietf.org/ipr/1154/
> draft-green-secsh-ecc is included in the list of documents to which the 
> IPR disclosure applies.

You are right it is listed there.  I totally missed it.

spt

---

From: Douglas Stebila <[email-masked]>
Date: Tue, 9 Jun 2009 12:06:11 +1000

On 2009-Jun-9, at 11:25 AM, Sean Turner wrote:

> support for compressed keys are MAY while this draft says MUST NOT  
> for ECDSA and ECDH keys and MAY for ECMQV.  What was the rationale  
> for this?

Simplicity.  In my opinion, compressed keys provide little benefit in  
practice.  Certainly for ECDH there's no reason to use them.  I would  
be willing to consider it as a MAY for ECDSA so that signing public  
keys can be reused between standards.

> Sec 3.1.1: Should the must be MUST in the following: The message  
> hashing algorithm must be from the SHA2 family of hash functions  
> [FIPS-180-3] and is chosen according to the curve size as specified  
> in Section 6.2.1.

Yes, thanks.

No.  The signature above is encoded using DER encoding of an ASN.1  
sequence.  There is almost no use of ASN.1 in the secure shell  
standards, so many SSH implementations may not have code to support  
DER encoding and decoding.  I prefer to stay with the basic syntax  
that the secure shell standard provides.  For those that do desire  
conversion between the two, it is easy to implement given a DER library.

> Sec 9.1: The TLS, SMIME, and PKIX use the secp* naming for the  
> curves instead of nist*.  Any chance we could use the secp* names?

In TLS the curves are actually identified by integers in an enum, with  
the secp names as convenient human readable identifiers.  In PKIX the  
curves are actually identified by OIDs; there the main reason for  
using the secp names for human readable identifiers is that NIST never  
specified OIDs, so the SEC OIDs are the only (or at least, most  
prominent) OIDs for those curves.

In the case of secure shell, since it's semantically equivalent and  
really just an issue of presentation, I am choosing to stick with  
nist* naming.  I believe that the table that lists the equivalence  
between nist* and secp* curves should alleviate any confusion.

> should always be enabled unless specifically disabled by local  
> security policy.

Yes, thanks.

According to
	https://datatracker.ietf.org/ipr/1154/
draft-green-secsh-ecc is included in the list of documents to which  
the IPR disclosure applies.

Douglas

---

From: Russ Housley <[email-masked]>
Date: Thu, 18 Jun 2009 09:59:04 -0400

>keys can be reused between standards.

I understand the desire for simplicity, but if someone has a 
certificate where point compression was used, do we want to have it 
rejected?  It seems like alignment with the other specifications 
offers better interoperability, right?

Russ

---

From: Douglas Stebila <[email-masked]>
Date: Fri, 19 Jun 2009 08:56:07 +1000

> offers better interoperability, right?

Okay, that's reasonable, and it seems like there's enough demand for  
it.  I'll change it to a MAY for ECDH and ECDSA.

Douglas