Subject: SSH in ECC Internet Draft

From: Jon Green <[email-masked]>
Date: Thu, 05 Oct 2006 14:54:45 -0400

In the interest of supporting the US government's Suite B cryptographic
algorithms, we have updated an ECC in SSH draft written by D. Stabila
(draft-stebila-secsh-ecdh-01) and have added Suite B algorithms,
specifically MQV to the draft.

This draft has been submitted to the IETF as an internet draft and I'm
posting it on this list to solicit some review and to try to generate
some interest. Any comments on the draft at all would be appreciated. 

Thanks
--
Jon Green
Research Intern
Certicom Corp.

---

From: der Mouse <[email-masked]>
Date: Thu, 5 Oct 2006 17:56:13 -0400 (EDT)

Most of my comments will be copy-edit remarks, because I do not know
enough about elliptic-curve crypto to say anything intelligent about
that.  (I hope to someday dig up the info, but the references you give
are mostly things I don't currently know how to find.)

This document specifies many packet fields as having type "ASN/DER".
I'd prefer to see it spelled out more precisely what this means.  Does
it mean that the DER-produced octet string is exaclty what appears in
the packet at that point?  Does it mean that the packet contains a
"string" which contains the DER-produced octet string?  Something else?

>        +-----------+-----------------------------+-------+---------+
>        | Symmetric |  Discreet Log (eg. DSA, DH) |  RSA  |   ECC   |
>        +-----------+-----------------------------+-------+---------+

ITYPM "Discrete".

This table is also meaningless unless accompanied by a way of comparing
the amount of computation demanded by, say, a 240-bit elliptic curve
key with the computation demanded by a 2048-bit RSA key.

>    Protocol fields and possible values to fill them in are defined in
>    this set of documents.  As an example SSH_MSG_KEX_ECDH_INIT is
>    defined as follows.
> 
>       byte       SSH_MSG_NUMBER
>       string     pK, public key octet string.

s/MSG_NUMBER/MSG_KEX_ECDH_INIT/ surely?

>    as the public key algorithm through key exchange negotiations the
>    servers long term ECC key pair (host keys) are used for
>    identification and verification.

s/servers/server's/ and s/are/is/ ("key pair" is singular).

>    the SSH implementation details, specification of the algorithm is

s/,/;/

>    public keys.  Using its own key pair and the other's public key both
>    the client and the server derive the same shared secret key using
>    ECDH.

s/key both/key, both/

>    3.  S MAY validate 'cPK' using for example algorithm A.16.10 of [12].

s/ for example/,&,/

>    The size of the selected curve SHOULD be greater than 160 bits, and
>    preferably at least 224 bits.  The size of the curve used SHOULD be

Either s/,// or s/ and// here.

>    Specification of the message numbers SSH_MSG_KEX_ECDH_REQUEST,
>    SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY are found in
>    Section 7.

s/are/is/ (or s/Specification/&s/).

>    another entity.  Both entities roles are analogous in the algorithm.
>    Using their own key pairs and the other entities public keys, both

s/entities/&'/ on each line.

>    The following is an informal discussion of ECMQV key exchange and
>    verification for a formal description see Section 5.2.

s/ for /;&/

>    is not in the clients name-list then both sides MUST disconnect.

s/clients/client's/

>    The server's host keys are used in shared key generation, therefore

s/, therefore/; therefore,/

>    key is generated with sufficient strength to ensure that the ECMQV

s/generated with sufficient strength to ensure/sufficiently strong/

> 6.1.  ssh-ecc
> 
>    The "ssh-ecc" method specifies Elliptic Curve digital signature
>    algorithm (ECDSA) for use in signing communications with ECC host
>    keys.  When used with ECMQV "ssh-ecc" provides ecmqv with a host key.
>    This method is discussed in Section 3.

This makes it sound as though ssh-ecc host keys and ecmqv key exchange
are not independent - that it is not possile to use one without the
other.  If true, I think this is a bad idea, if only because the
negotiation framework does not support this kind of tied negotiation.

>    When lists of curves need to be sent to negotiate mutually supported
>    curves they are sent as a sequence of unique ASN.1 OIDS.  The ASN.1

Why is there a hard limit on the size of a list of curves, especially a
limit that's a magic number like 12?  Surely it would be better to
leave this extensible?

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       [email-masked]
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B

---

From: Ben Harris <[email-masked]>
Date: Thu, 05 Oct 2006 23:51:34 +0100

>negotiation framework does not support this kind of tied negotiation.

Actually, in this case, we already have that kind of tied negotiation.  
SSH already supports the notions of signature-capable and 
encryption-capable host keys, and the choice of public-key algorithm 
depends on the selected public-key algorithm.  This effectively adds an 
third key type to that algorithm.  It might be a good idea for this to 
be done more explicitly (perhaps allowing for the possibility of other 
ECC key formats), but I don't see that there's anything inherently wrong 
with it.

-- 
Ben Harris

---

From: Ben Harris <[email-masked]>
Date: Fri, 06 Oct 2006 00:47:14 +0100

Like der Mouse I currently know little about ECC, but I've got a few 
comments nonetheless.

In article <[email-masked]> you write:
>3.1.  Key/Signature Encoding
>
>   The ECC public key and signature are sent in the standard encoding
>   for ECC keys and signatures.  This requires ASN.1 DER encoding which
>   is specified in [7] and [8].

Using ASN.1 worries me a little, given the rate at which security holes 
are found in ASN.1 decoders.

>   The ecc public key has the following encoding:
>
>      string     "ssh-ecc"
>      ASN/DER    SubjectPublicKeyInfo
>
>   Here 'SubjectPublicKeyInfo' is defined as it is in Section C3 of SEC1
>   [4].

Conventionally, key format names beginning "ssh-" have been used for key 
formats invented specifically for SSH, while other names have been used 
for key formats imported from elsewhere.  Thus I'd suggest using a name 
not starting with "ssh-" here, say "sec1-ecc".

>4.2.  Implementation

>                    +----------------+----------------+
>                    |   Curve Size   | Hash Algorithm |
>                    +----------------+----------------+
>                    |    b <= 256    |     SHA-256    |
>                    |                |                |
>                    | 256 < b <= 384 |     SHA-384    |
>                    |                |                |
>                    |     384 < b    |     SHA-512    |
>                    +----------------+----------------+

You should cite [9] here as a reference for SHA-256 etc.

>   The hash H is computed as the HASH of the concatenation of the
>   following.

You haven't defined HASH here.

>5.1.  Description

>   2.  C OPTIONALLY verifies that the 'curve' has an acceptable level of
>       security compared to the bulk encryption algorithm chosen during
>       algorithm negotiation, a good reference for key strength
>       comparison can be found in [11].  If C accepts 'curve' then it
>       uses the associated domain parameters to generate an ephemeral
>       ECC public/private key pair.

What does it do if it doesn't accept 'curve'?

>5.2.  Implementation

>                    +----------------+----------------+
>                    |   Curve Size   | Hash Algorithm |
>                    +----------------+----------------+
>                    |    b <= 256    |     SHA-256    |
>                    |                |                |
>                    | 256 < b <= 384 |     SHA-384    |
>                    |                |                |
>                    |     384 < b    |     SHA-512    |
>                    +----------------+----------------+

Again, cite [9]...

>   The hash H is formed by applying the algorithm HASH on a
>   concatenation of the following:

And define HASH (or just refer to "the exchange hash algorithm").

>9.  Acknowledgements
>
>   The author would like to thank Douglas Stebila who wrote
>   draft-stebila-secsh-ecdh-01, the ECDH portion of this draft is
>   largely an updated version of his document.

Douglas Stebila is one of the authors -- it seems odd for him to be 
thanking himself.

>   [4]   Standards for Efficient Cryptography Group, "Elliptic Curve
>         Cryptography", SEC 1, September 2000.
>
>   [5]   Standards for Efficient Cryptography Group, "Recommended
>         Elliptic Curve Domain Parameters", SEC 2, September 2000.

SECG standards seem to have version numbers -- it might be worth quoting 
them here.

>   [6]   Bradner, S., "Key Words for Use in RFCs to Indicate Requirement
>         Levels", RFC 2119, March 1997.

RFCs are usually listed before other references.

>   [7]   Internation Telecommunication Union, "Abstract Syntax Notation
>         One (ASN.1): Specification of basic notation", X. 680,
>         July 2002.
>
>   [8]   Internation Telecommunication Union, "ASN.1 encoding rules",
>         X. 690, July 2002.

That's "International", "X.680" (no space), "X.690", and "ASN.1 encoding
rules: Specification of Basic Encoding Rules (BER), Canonical Encoding
Rules (CER) and Distinguished Encoding Rules (DER)", according to the 
ITU Web site.

>   [10]  National Institute of Standards and Technology, "Keyed-Hash
>         Message Authentication Code", FIPS 198, March 2002.

Is there any good reason not to reference RFC 2104 instead of FIPS 198?

-- 
Ben Harris

---

From: Jon Green <[email-masked]>
Date: Fri, 06 Oct 2006 17:24:49 -0400

> key with the computation demanded by a 2048-bit RSA key.

Computation to do what? (Create the key, crack the key) I'm not really
sure what your suggesting I do here. The reference I provide goes into
great detail about how their key comparisons are done. 

> limit that's a magic number like 12?  Surely it would be better to

This was a bit of a cop out because I was unable to find a way to
specify in ASN.1 syntax how to not put an upper limit on a sequence. 

I've updated the specification to be: 
   curves::= SEQUENCE SIZE (1 ... MAX) OF { curve }

Other RFC's seem to specify unbounded sequences like this, without ever
defining MAX, but I don't like leaving MAX undefined, since it doesn't
seem to be part of the ASN specification. Can anyone tell me if this is
correct?

> are found in ASN.1 decoders.

I understand your concerns, and I do share them, but as far as I know
the SSL ASN code is being rewritten. Honestly I don't like using ASN.1
at all, but I feel its a necessary evil to stay compliant with ECC
standards, which I think is more important then software that will be
rewritten.

> not starting with "ssh-" here, say "sec1-ecc".

Are you suggesting changing the name of the public key algorithm to
sec1-ecc, or just the string sent before the key itself? All the current
RFCs (as far as I know) send the same string with the key as the public
key algorithm it will be used with.  Is it going to be a problem to send
a different string with the key? Should the string sent before the
signature be changed as well?

> Is there any good reason not to reference RFC 2104 instead of FIPS

I didn't realize there was a RFC, I also found a RFC for the SHA series
of hash functions, so I changed that reference to a RFC. 

Thanks for all the comments, keep them coming! Anything I didn't mention
here got changed. I've attached a updated version to this email.

Cheers
--
Jon Green
Research Intern
Certicom Corp.

---

From: der Mouse <[email-masked]>
Date: Sat, 7 Oct 2006 02:48:52 -0400 (EDT)

[The message to which I am replying responded to messages from two
different people, pulling them together.  I didn't write all the
two-level quotes here.]

>> This table is also meaningless unless accompanied by a way of
>> comparing the amount of computation demanded by, say, a 240-bit
>> elliptic curve key with the computation demanded by a 2048-bit RSA
>> key.
> Computation to do what?  (Create the key, crack the key)

Use the keys.  Giving them as "equivalent security" means that the
computation to crack the key is (thought to be) about equal

You cite smaller key sizes in a context that makes it read (at least to
me) like a reason to use elliptic curve algorithms - but smaller key
size, in itself, borders on meaningless; the number of bits involved is
one of the least important attribtues of keys - at least until you get
into many tens of thousands of bits.

> I'm not really sure what [you're] suggesting I do here.

Either reword it so this reads less like an advertisement for elliptic
curve crypto or provide data indicating why (for example) an elliptic
curve key of 240 bits is to be preferred over an RSA key of 2048 bits.

>>>    When lists of curves need to be sent [...]
>> Why is there a hard limit on the size of a list of curves,
>> especially a limit that's a magic number like 12?  Surely it would
>> be better to leave this extensible?

This seems to me like a fairly clear message that ASN.1 is the wrong
tool to use here (quite aside from other problems with it - vide
infra).

>>>   for ECC keys and signatures.  This requires ASN.1 DER encoding
>> Using ASN.1 worries me a little, given the rate at which security
>> holes are found in ASN.1 decoders.
> the SSL ASN code is being rewritten.

And this is relevant...why?  Are you under some kind of impression that
the result (a) will somehow supplant all other ASN.1 implementations
used by SSH implementations and (b) will itself be free from further
bugs?  I find each part of that...dubious, at best.

> Honestly I don't like using ASN.1 at all, but I feel its a necessary
> evil to stay compliant with ECC standards, which I think is more
> important then software that will be rewritten.

Standards should help, hot hinder.  Standards that hinder rather than
helping should be ignored.

Or at least that's my view of them.

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Ben Harris <[email-masked]>
Date: Sat, 07 Oct 2006 12:10:38 +0100

In article <[email-masked]> you write:
>> Conventionally, key format names beginning "ssh-" have been used for
>> key formats invented specifically for SSH, while other names have
>> been used for key formats imported from elsewhere.  Thus I'd suggest
>> using a name not starting with "ssh-" here, say "sec1-ecc".
>
>sec1-ecc, or just the string sent before the key itself?

Both.  Basically s/ssh-ecc/sec1-ecc/g (or whatever new name you think is
appropriate) over the document.

-- 
Ben Harris

---

From: der Mouse <[email-masked]>
Date: Sun, 8 Oct 2006 22:30:18 -0400 (EDT)

>>> [...]
>> This makes it sound as though ssh-ecc host keys and ecmqv key
>> exchange are not independent - that it is not possile to use one
>> without the other.  If true, I think this is a bad idea, if only
>> because the negotiation framework does not support this kind of tied
>> negotiation.
> Actually, in this case, we already have that kind of tied
> negotiation.  SSH already supports the notions of signature-capable
> and encryption-capable host keys, and the choice of public-key
> algorithm depends on the selected public-key algorithm.  This
> effectively adds an third key type to that algorithm.

Hmm.  Yes, that's a logically coherent point of view.

I don't like it, though, if only because it takes a special case for
one particular algorithm (or, if you prefer, family of algorithms
currently represented by a single element) and elevates it to being
coëval with generic concepts like signatures and encryption.  It feels
like a level confusion.

If this does stay, I'd prefer to see it spelled out much more
explicitly.

Not that what I think carries any particular authority, mind you....

/~\ The ASCII				der Mouse
\ / Ribbon Campaign

---

From: Nicolas Williams <[email-masked]>
Date: Sun, 8 Oct 2006 23:57:19 -0500

>    curves::= SEQUENCE SIZE (1 ... MAX) OF { curve }

Why do you need to specify a limit at all?

> seem to be part of the ASN specification. Can anyone tell me if this is

That's not good -- nowadays the IESG insists on whole ASN.1 modules and
that they compile with various available tools.

Nico
--

---

From: Nicolas Williams <[email-masked]>
Date: Mon, 9 Oct 2006 00:01:58 -0500

> tool to use here (quite aside from other problems with it - vide

Jon says that the relevant parameters are identified by OIDs.  If there
is an existing namespace/registry of the such then it seems quite
appropriate to use OIDs here.

A list of OIDs need not be specified as an ASN.1 SEQUENCE though, and
SSHv2 already has a way to encode lists of things, re-using here.  That
way there's no need to use ASN.1 or any of its encodings just to send
these OIDs (since OIDs are DER encoded and so, when used as registered
names, just simple octet string constants).

Nico
--

---

From: Markus Friedl <[email-masked]>
Date: Mon, 9 Oct 2006 11:32:48 +0200

On Thu, Oct 05, 2006 at 02:54:45PM -0400, Jon Green wrote:
>    The data types boolean, uint32, uint64, string, and mpint are to be
>    interpreted in this document as described in RFC 4251 [1].
> 
>    This document uses Abstract Syntax Notation (ASN.1) define some
>    communication.  This is in keeping with current ECC standards.  All
>    ASN.1 variables are DER encoded before being sent.  Information about
>    the ASN.1 and DER can be found in ITU-T recommendation X.680 [7] and
>    ITU-T recommendation X.690 [8].

is it really necessary to use ASN.1 encoding?  this is rather scary
and does not fit well into the data type scheme defined in RFC 4251.

---

From: Damien Miller <[email-masked]>
Date: Tue, 10 Oct 2006 03:46:38 +1000 (EST)

> some interest. Any comments on the draft at all would be appreciated. 

[1] does not list any IPR disclosure filed for this draft, despite it
containing something (MQV) that is known to be patented by Certicom.
Many points of the draft (e.g. the checks recommended and required in
4.1) seem to point to other methods over which Certicom happens to hold
patents.

This working group has so far eschewed patent-encumbered technology, and
I really hope that this position does not change.

-d

[1] https://datatracker.ietf.org/public/ipr_search.cgi?option=document_search&document_search=draft-green-secsh-ecc-00.txt

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Oct 2006 15:29:43 -0400

>>>>> "Damien" == Damien Miller <[email-masked]> writes:

    Damien> On Thu, 5 Oct 2006, Jon Green wrote:
    >> In the interest of supporting the US government's Suite B
    >> cryptographic algorithms, we have updated an ECC in SSH draft
    >> written by D. Stabila (draft-stebila-secsh-ecdh-01) and have
    >> added Suite B algorithms, specifically MQV to the draft.
    >> 
    >> This draft has been submitted to the IETF as an internet draft
    >> and I'm posting it on this list to solicit some review and to
    >> try to generate some interest. Any comments on the draft at all
    >> would be appreciated.

    Damien> [1] does not list any IPR disclosure filed for this draft,
    Damien> despite it containing something (MQV) that is known to be
    Damien> patented by Certicom.  Many points of the draft (e.g. the
    Damien> checks recommended and required in 4.1) seem to point to
    Damien> other methods over which Certicom happens to hold patents.

I'm sure the draft authors are well aware, but by submitting an IETf
contribution such as an internet draft or a message to this list, they
are bound by IETF IPR rules and subject to constraints outlined in the
appropriate BCPs must file disclosures.  If anyone has any questions
about IETF IPR policy I would be happy to answer those questions or
get you in touch with someone who can answer.

    Damien> This working group has so far eschewed patent-encumbered
    Damien> technology, and I really hope that this position does not
    Damien> change.

This working group is closed.  If these drafts are considered for
publication it will be as an individual submission.  However IETF
consensus would be required for publication and the views of the ssh
community would be a strong factor in that consensus.

---

From: Sam Hartman <[email-masked]>
Date: Mon, 09 Oct 2006 15:31:49 -0400

>>>>> "Markus" == Markus Friedl <[email-masked]> writes:

    Markus> On Thu, Oct 05, 2006 at 02:54:45PM -0400, Jon Green wrote:
    >> The data types boolean, uint32, uint64, string, and mpint are
    >> to be interpreted in this document as described in RFC 4251
    >> [1].
    >> 
    >> communication.  This is in keeping with current ECC standards.
    >> All ASN.1 variables are DER encoded before being sent.
    >> Information about the ASN.1 and DER can be found in ITU-T
    >> recommendation X.680 [7] and ITU-T recommendation X.690 [8].

    Markus> is it really necessary to use ASN.1 encoding?  this is
    Markus> rather scary and does not fit well into the data type
    Markus> scheme defined in RFC 4251.

I think you should look at how this will likely work in common
implementations.  If your ECC library is likely to want to take ASN.1
parameters as input, then that's probably how you want to transport
them.

Certainly there are a lot of IETF protocols that use ASN.1; ASN.1 is
complex but sometimes that complexity is necessary.

--Sam

---

From: Damien Miller <[email-masked]>
Date: Wed, 11 Oct 2006 01:52:24 +1000 (EST)

> complex but sometimes that complexity is necessary.

I agree with Markus; the use of ASN.1 adds a lot of complexity and
attack surface to an implementation. In this case, this additional
complexity must be in the critical pre-authentication code.

IMO that (some) ECC libraries happen to use ASN.1 is not a good reason
to use it as protocol element.

-d

---

From: [email-masked] (Niels Möller)
Date: 10 Oct 2006 18:13:30 +0200

> parameters as input, then that's probably how you want to transport

I don't buy that argument. By the same argument, the only reason not
to replace the "ssh-rsa" keys by the asn.1 based pkcs#x stuff formats
is backwards compatibility.

The way I see it, when you specify asn.1 as the wireformat for
anything, that forces every implementation (or the libraries it
depends upon) to take asn.1 to its core.

I see the ssh RSA and DSA key formats as a good example on how to do
things. It allows ssh implementatiions to use very simple and
minimalistic libraries. Whenever compatibility with other formats is
needed, that conversion can easily be done *off-line*, and without
automatically making bugs in the conversion code into remote root
exploits.

Converting between asn.1 formats and simpler native formats used for
the actual computation, is maybe no big deal in principle, but that's
no good reason to *force* that conversion code into each and every
implementation of the ssh protocol. You don't want code bloat in ssh
implementations.

Regards,
/Niels

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Oct 2006 11:17:23 -0500

> to use it as protocol element.

The draft defines one ASN.1 type ('curves', a SEQUENCE of OIDs) where
existing SSHv2 constructs could be used instead.  The draft's other uses
of ASN.1/DER do not require an implementation of SSHv2 to implement
ASN.1/DER outside ECC libraries, but this one type does.

So I agree, remove that type.

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Oct 2006 12:06:19 -0500

On Tue, Oct 10, 2006 at 01:01:51PM -0400, Jon Green wrote:
> On Tue, 2006-10-10 at 11:17 -0500, Nicolas Williams wrote:
> I don't think that we can just remove curves and send a name-list of
> OIDs.

Sure you can.

>       Encoding and parsing a ASN.1 sequence is easier then encoding and
> parsing a ssh namelist full of octet strings. 

Nonsense.

If you're implementing this I-D then you are already implementing SSHv2
and you already have code for encoding/decoding SSHv2-style
lists/arrays.

But the reverse is not true!

If you're using ECC libraries off-the-shelf and adding this to an SSHv2
implementation then it's not the case that you necessarily have the code
to encode/decode ASN.1/DER SEQUENCEs.

> So everyone is familiar with what an asn.1 sequence looks like:

I am, but you cannot assume that SSHv2 implementors in general are.

> The first problem with putting OIDs in name-lists is that the one of the
> octets in the OID octet string may be 0x2C (ascii comma) which delimits
> the list, so the OIDs will have to be encoded somehow before being put
> into a standard namelist, or there has to be a new type of list
> defined. 

You mistunderstand SSHv2 list/array encoding.

Nico
--

---

From: Jon Green <[email-masked]>
Date: Tue, 10 Oct 2006 13:01:51 -0400

I don't think that we can just remove curves and send a name-list of
OIDs. Encoding and parsing a ASN.1 sequence is easier then encoding and
parsing a ssh namelist full of octet strings. 

So everyone is familiar with what an asn.1 sequence looks like:
[ identifier | length | oid | oid | oid | oid | ...
where each oid contains
[ identifier | length | oid data ]

Any list constructs I came up with seemed to be very similar to the
ASN.1 sequence of construct, so i decided to use it. Would including
some psudocode in the draft to encode and parse 'curves' maybe be a good
idea?

I like using the OIDs to identify curves since there is an already
existing IANA registry and we don't have to reinvent the wheel this
way. 

Cheers,
Jon Green

---

From: Nicolas Williams <[email-masked]>
Date: Tue, 10 Oct 2006 12:01:41 -0500

On Tue, Oct 10, 2006 at 12:51:27PM -0400, Bill Sommerfeld wrote:
> actually, it looks to me like there may be a deeper problem: the same
> "two level negotiation" issue which affected the gssapi key exchange.

Yeah, that was pointed out elsewhere.  Do we have consensus on how best
to deal with extensions that tie KEX/host key algs so intimately?

---

From: Sam Hartman <[email-masked]>
Date: Tue, 10 Oct 2006 13:31:34 -0400

>>>>> "Niels" == Niels Möller <[email-masked]> writes:

    Niels> Sam Hartman <[email-masked]> writes:
    >> implementations.  If your ECC library is likely to want to take
    >> ASN.1 parameters as input, then that's probably how you want to
    >> transport them.

    Niels> I don't buy that argument. By the same argument, the only
    Niels> reason not to replace the "ssh-rsa" keys by the asn.1 based
Niels> pkcs#x stuff formats is backwards compatibility.

Well, let's put it this way, I think using ASN.1 in that instance
would have been an entirely reasonable design tradeoff.

    Niels> The way I see it, when you specify asn.1 as the wireformat
    Niels> for anything, that forces every implementation (or the
    Niels> libraries it depends upon) to take asn.1 to its core.

So, my advice to the authors of the ECC draft is to listen to the
comments here about ASN.1, to the extent that you agree with them make
changes, but to have the debate about whether you are using too much
ASN.1 in the ietf-wide context not on this list.  I think that there
is a lot of anti-ASN.1 FUD here and you will get a much more balanced
viewpoint on the ietf list.  But if you are going to use ASN.1 at all,
USE IT CORRECTLY.  Arbitrary limits because you can't find out how to
write your constraints and lack of a module that compiles will be a
problem.

    Niels> I see the ssh RSA and DSA key formats as a good example on
    Niels> how to do things. It allows ssh implementatiions to use
    Niels> very simple and minimalistic libraries. Whenever
    Niels> compatibility with other formats is needed, that conversion
    Niels> can easily be done *off-line*, and without automatically
    Niels> making bugs in the conversion code into remote root
    Niels> exploits.

This is one valid approach.  If you are only going to have ssh, then
it is a clear savings in complexity and as you point out complexity is
tied to security.  However if I'm going to have a bunch of protocols
each of which does things lightly differently I eventually get to a
point where chasing down all the problems in all the implementations
of similar concepts actually provides worse security.  Like everything
else it is a balance between local complexity and global complexity.
Please do not confuse the tradeoff you have chosen with the right
answer: it is simply *a* right answer.

---

From: Jon Green <[email-masked]>
Date: Tue, 10 Oct 2006 13:52:03 -0400

> You mistunderstand SSHv2 list/array encoding.

I'm sorry if I misunderstand, could you please elaborate on your plans
to encode OIDs within SSHv2 namelists? I am more then happy to throw out
the 'curves' construct if its redundant and a name-list can be used.

I feel as if ASN.1 has to have some part in this design, but if there is
a SSH specific way of sending lists that can be used, then i fully
support using that in order reduce the amount of ASN.1 that has to be
used.

I just re-read RFC4251 and I don't see how OIDs that can contain 0x2C
can be allowed to be put into a name-list.

>From RFC4251:
>    name-list
> 
>       A string containing a comma-separated list of names.  A name-list
>       is represented as a uint32 containing its length (number of bytes
>       that follow) followed by a comma-separated list of zero or more
>       names.  A name MUST have a non-zero length, and it MUST NOT
>       contain a comma (",").  As this is a list of names, all of the
>       elements contained are names and MUST be in US-ASCII.  Context may
>       impose additional restrictions on the names.  For example, the
>       names in a name-list may have to be a list of valid algorithm
>       identifiers (see Section 6 below), or a list of [RFC 3066] language
>       tags.  The order of the names in a name-list may or may not be
>       significant.  Again, this depends on the context in which the list
>       is used.  Terminating null characters MUST NOT be used, neither
>       for the individual names, nor for the list as a whole.
> 
>        Examples:
> 
>        value                      representation (hex)
>        -----                      --------------------
>        (), the empty name-list    00 00 00 00
>        ("zlib")                   00 00 00 04 7a 6c 69 62
>        ("zlib,none")              00 00 00 09 7a 6c 69 62 2c 6e 6f 6e 65
> 

The definition of a namelist itself states that an entity in the
namelist cannot contain 0x2C or 0x00. All of the SEC curve OIDs do
contain a 0x00, and it is possible other OIDs contain 0x2C. 

Cheers,
Jon Green

---

From: Bill Sommerfeld <[email-masked]>
Date: Tue, 10 Oct 2006 12:51:27 -0400

I think you need to define a family of ssh key exchanges, one per
defined "curve", so that two implementations which support
noninteresecting sets of ECC curves but also support other KEX
mechanisms can find other common mechanisms.

							- Bill

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 10 Oct 2006 11:59:15 -0600

> into a standard namelist, or there has to be a new type of list

If, as it appears, we only need a list of oids, I can think of
two ways to do this 'the ssh way.'

1. Encode each oid in the numeric dotted ascii format,
   i.e., "1.2.840.113554.1.2.2"; comma seperate them,
   and send as a single string.

2. Encode as
   uint32 uCount
   string oid-octet-strings[uCount]

   or

   string curves
       string oid
       string oid
       string oid
       ...

> existing IANA registry and we don't have to reinvent the wheel this

Oh... definitely keep the oids... I don't think anyone is arguing
against using oids.

Thanks,

Joseph

---

From: Ben Harris <[email-masked]>
Date: Tue, 10 Oct 2006 19:07:02 +0100

>mechanisms can find other common mechanisms.

Um, implementations aren't allowed to support non-intersecting sets of 
curves, since Appendix A.1 requires all implementations to support four 
standard curves.

-- 
Ben Harris

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 10 Oct 2006 12:16:58 -0600

> curves, since Appendix A.1 requires all implementations to support four 

While the implementation must support them, the site policy
may disable them.

Thanks,

Joseph

---

From: Joseph Galbraith <[email-masked]>
Date: Tue, 10 Oct 2006 12:19:09 -0600

> mechanisms can find other common mechanisms.

You could take the route that gssapi did and base64 encode
the curve oid and make it part of the name:

"ssh-ecc-<base64 encoded curve oid>,ssh-ecc-<a-different-oid>"

Thanks,

Joseph