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@xxxxxxxxxx] > Sent: Thursday, June 11, 2009 7:57 AM > To: ietfdbh@xxxxxxxxxxx > 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf