Subject: RE: opsdir review of draft-green-secsh-ecc-08

From: "David Harrington" <[email-masked]>
Date: Thu, 11 Jun 2009 10:03:56 -0400

Hi Douglas,

For the most part, I really like the new security considerations
section in 09. I found it far more enlightening (and even
interesting). Thanks.

I usually look for security considerations in a form that points out
the threats and how they are mitigated (or can be mitigated by
configuration decisions). I do not insist on this form; but I think it
makes it easier for people to understand. For the most part, your new
section does this well.

You may be more detailed than is necessary in the security
considerations. I am not quite sure who the target audience is for
this draft - SSH operators/users or crypto developers implementing
support for this cipher suite. probably both. Your discussion is
probably way more detailed than needed for most operators and users
and programmers, but possibly right for crypto implementers.

Paragraph 3 in the security considerations discusses prime, and
characteristic 2, and composite. I don't know what these mean, except
the prime (which I assume is the mathematical prime). I can live with
not understanding these terms, but I am not sure of the implications
of the last sentence. "All of the RECOMMENDED curves of characteristic
2 in section 10 have prime m." As I read this paragraph, am I correct
in believing that the next to last sentence states the threat
(susceptible to attack by the Weil descent), and the last sentence
says the prime m mitigates that attack?  If so, it would help to
append to the last sentence ", which helps to protect against such
attack." or something similar. 

For operators deploying this in today's networks, I am pretty sure the
discussion of quantum computers is not really relevant, but it is
interesting ;-) No complaint; just an observation.

In paragraph 6, I think the "As such," is unnecessary (and I found it
slightly distracting that it was there, because unnecessary
introductory phrases are a pet peeve for me).

I found paragraph 10 hard to understand. "strong security at the
security levels indicated" seems a bit convoluted. Is there a better
way to express what you mean? When you say "in this section", are you
referring to the security considerations section?

--
Manageability

We are actively working to decide what should be said in documents
about manageability. Adrian's draft was a good place to start. The
opsawg has a draft on operations and management (by me) that might
have some additional guidelines that hopefully would be helpful.

For the most part, I am happy with the new management considerations,
and think they are sufficient to satisfy my review comments. I have
some additional questions that you might consider discussing, and a
few minor edits.

section 8 looks good.

In section 8.1, I think this would be better expressed as
"Implementers should allow administrators to disable some curves,
including some REQUIRED or RECOMMENDED curves, to meet local security
policy."

The initial setup and installation presumably will be done using
normal SSH config methods. Are there any ECC-specific parameters that
must be configured? Are there specific parameters that should not be
disclosed in a config file? Are there defaults that would be useful to
help ensure interoperability (or have you already discussed all the
necessary defaults when you discuss specific ciphers?

For administartively-configurable parameters, are there any that must
be preserved across reboots? others that do not?

section 8.2 looks good. 
Is ECC computationally expensive? Could that impact SSH performance,
for example?

Are there any fault or threshold conditions for ECC processing? If
they occur, is this something the operator should be informed of, e.g.
via syslog, or are all ECC fault and threshold conditions already
dealt with within the SSH fault and threshold handling mechanisms?

ECC is susceptible to certain types of attacks. Can an implementation
detect such attacks (without significant computational impact)? Are
there anomalous patterns that can be discerned? If so, would it be
useful to have a counter in the system's management interface to count
specific anomalies, so an operator or an IDS could monitor the
counter(s) and raise an alarm if the system might be under attack? 

Good job,
Thanks.

> -----Original Message-----
> From: Douglas Stebila [mailto:[email-masked]] 
> Sent: Thursday, June 11, 2009 7:57 AM
> To: [email-masked]
> Subject: Re: opsdir review of draft-green-secsh-ecc-08
> 
> Hi David,
> 
> Thanks for the extensive review.  I am attaching a proposed revision

> of the draft to address your concerns about the manageability  
> considerations and security considerations sections.  The security  
> considerations section has been substantially rewritten to, I hope,

> provide a more self-contained analysis of the security issues 
> at play  
> when using elliptic curve cryptography.  I was unable to find many  
> examples of manageability considerations sections (I worked off of  
> draft-ietf-pce-manageability-requirements-06) and do not really know

> what else should be in this section, so if you have any more 
> concrete  
> advice that would be helpful.
> 
> Douglas
> 
>

---

From: Douglas Stebila <[email-masked]>
Date: Mon, 15 Jun 2009 20:12:17 +1000

Thanks for the feedback, David.  Comments inline below.

> section in 09. I found it far more enlightening (and even

And even interesting?  Wow!  :)

> attack." or something similar.

I have tried to make this paragraph a little more applied, avoiding  
some of those details.  Is this any better?

The difficulty of breaking the ECDLP depends on the size and quality  
of the elliptic curve parameters.  Certain types of curves can be more  
susceptible to known attacks than others.  For example, curves over  
finite fields GF(2^m), where m is composite, may be susceptible to an  
attack based on the Weil descent.  All of the RECOMMENDED curves in  
<xref target="params" /> do not have this problem.  System  
administrators should be cautious when enabling curves other than the  
ones specified in <xref target="params" /> and should make a more  
detailed investigation into the security of the curve in question.

> interesting ;-) No complaint; just an observation.

My former PhD supervisor works in quantum computing, so on the odd  
chance he ever reads this draft, he'll expect me to have written a  
line about quantum computers.  Old habits die hard.

> referring to the security considerations section?

Is this any clearer?

The REQUIRED and RECOMMENDED curves in this document are at present  
believed to offer security at the levels indicated in this section and  
as specified with the table in <xref target="intro" />.

Thanks.

> necessary defaults when you discuss specific ciphers?

None that I can think of.  Once ECC private keys are generated and  
installed, these should work just as any other secure shell public key  
algorithm or key exchange method and require no further configuration.

> be preserved across reboots? others that do not?

None beyond the local security policy disabling or enable certain  
curves.

> Is ECC computationally expensive? Could that impact SSH performance,

I've added the following paragraph to section 8.2 to address this:

The use of elliptic curve cryptography should not place a significant  
computational burden on an implementing server.  In fact, due to its  
smaller key sizes, elliptic curve cryptography can be implemented more  
efficiently for the same security level than RSA, finite field Diffie- 
Hellman, or DSA.

> counter(s) and raise an alarm if the system might be under attack?

I can think of no logging or analysis that should be done for ECC- 
based SSH that is different from what should be done for RSA, finite  
field Diffie-Hellman, or DSA.

Douglas