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:douglas(_at_)stebila(_dot_)ca]
Sent: Thursday, June 11, 2009 7:57 AM
To: ietfdbh(_at_)comcast(_dot_)net
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
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf