Thanks for the feedback, David. Comments inline below.
On 2009-Jun-12, at 12:03 AM, David Harrington wrote:
For the most part, I really like the new security considerations
section in 09. I found it far more enlightening (and even
interesting). Thanks.
And even interesting? Wow! :)
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.
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.
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.
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.
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?
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" />.
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."
Thanks.
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?
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.
For administartively-configurable parameters, are there any that must
be preserved across reboots? others that do not?
None beyond the local security policy disabling or enable certain
curves.
section 8.2 looks good.
Is ECC computationally expensive? Could that impact SSH performance,
for example?
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.
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?
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
_______________________________________________
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf