Simon:
(1) The specification only employs SHA-1. Should it be extended to include
to SHA-256 in anticipation of 128-bit AES keys?
Our goal was not to specify "new crypto" in this spec but rather leave that up
to the groups that focus on writing crypto specs. I don't know of any crypto
specs that have added SHA-2 support yet. So I'd propose to specify use of
SHA-1
until the crypto specs add SHA-2 ... at which point we can add SHA-2
support in
a new draft or a rev of this spec.
I have no problem with this. Can we add a paragraph to the Security
Considerations that warns implementors that a wider has MAY be specified
when stronger (symmetric algorithms with longer key sizes) are supported
(e.g., AES)?
(2) Does the 1-pass D-H scheme use co-factor multiplication? I understand
that it is possible to do it done with or without co-factor multiplication,
so I am really seeking clarification here. Are there IPR issues regarding
the choice?
All we do is reference X9.63 which allows either "regular" ECDH or "cofactor"
ECDH ... so yes the 1-pass ECDH scheme allows cofactor ECDH. There are IPR
issues with cofactor ECDH (as with other EC schemes) ... here's what I know
about Certicom's IPR in this area (usual disclaimers, etc, etc):
- Certicom's SMIME IPR statement ...
http://www.ietf.org/ietf/IPR/CERTICOM-SMIME-1
- Certicom's IEEE 1363 statement ...
http://grouper.ieee.org/groups/1363/P1363/patents.html
- As far as I know, the most relevant patent is 5,933,504.
Please add a Intellectual Property Rights section to the document. Please
take a look a section 9 of RFC 2459 for an example. Also, take a look at
the references made in the discussion of the RSA algorithm (the patent had
not expired when RFC 2459 was published). This provides a simple "heads up."
(3) Can you say something about the unknown key-share attack on MQV? I
understand that this vulnerability can be avoided by explicit key
authentication. A paragraph in the Security Considerations section should
be sufficient.
Sure we'll add a paragraph to Security considerations. Briefly, unknown
key-share is about fooling Bob into thinking a CEK he actually shares with
Alice
is in fact shared with Eve. If Eve can do this, then maybe she can fool
Bob into
believing a message from Alice is in fact from Eve. Unknown key-share is
therefore mainly concerned with authenticated and encrypted data ...
because for
example, Eve can always take a message that she sees Alice sign and send
to Bob,
and replace it with the same message, signed with Eve's key. When 1-pass
MQV is
used in CMS to authenticate then encrypt data, the unknown key-share issue
with
MQV doesn't arise because the ephemeral public key of Alice is included inside
authenticated-data, and therefore inside the encrypted content.
Thanks. I look forward to the updated security considerations.
(4) Section 3.2.2. "Parity bits adjusted according to the keywrap
algorithm" is rather vague. Please extract the appropriate text from RFC
2630.
To be as clear as possible, we propose to replace the quoted text with a
simple
reference to 2630.
Fine. Please reference a particular section in RFC 2630.
Russ