Just to keep everyone informed: Dr. Struik and I spoke by phone earlier today
about his comments. My recollection of the conversation is that he accepted
most of the comments as resolved, modulo the following additional details:
(And Dr. Struik! One of our agreements has been overtaken by events! Please see
below.)
On Mar 7, 2011, at 1:51 PM, Herzog, Jonathan - 0668 - MITLL wrote:
On Mar 3, 2011, at 12:37 PM, Russ Housley wrote:
(E-e) p. 4, l. -5: The motivation for specifying ECDH seems to be not so
much that ECMQV is around (but having problems, as you stated),
but that static-static-ECDH is *not*
around. Thus, specifying static-static-ECDH adds more options to the
solution space.
I'm not sure how to interpret this. Is this just a general comment, or are
you suggesting some change to the draft? if the later, can you say a little
more about the change you would like to see?
This comment got folded into another comment about our motivation. The new
version dispenses with motivations (1) and (3), focusing on the fact that ECMQV
is no longer in Suite B. Therefore, some participants will not be able to use
ECMQV for policy reasons, and may also be unable to sign their messages for
lack of a certified signature key. This Draft presents static-static ECDH as an
alternative mechanism for achieving source authentication if they should happen
to have a certified ECDH key.
(T-g) p. 6, Clause 2.2, l. -5: At first, it is suggested that the sending
agent obtains the recipient's public key somehow (e.g., from its
certificate), thus suggesting that certificates are not the only option by
which the public key may be obtained. However, later on it is stated
that "it confirms that both certificates [...]", thus suggesting that each
of the parties involved in this message flow have public keys that
are certified and that only those can be used. This is confusing.
But you are right: the use of 'e.g.' is a bit confusing. To resolve this
confusion, I propose to change Section 2.2 from
When using static-static ECDH with EnvelopedData, the sending agent
first obtains the recipient's EC public key and domain parameters
(e.g. from the recipient's certificate).
to
When using static-static ECDH with EnvelopedData, the
sending agent first obtains the EC public key(s) and domain
parameters contained in the recipient's certificate.
and Section 2.3 from
The receiver then retrieves the static EC public key identified in
the rid field.
to
The receiver then retrieves the sender's certificate
identified in the rid field.
This last sentence now reads:
The receiver then retrieves the sender's certificate identified in
the rid field, and extracts the EC public key(s) and domain
parameters contained therein.
(T-h) p. 6, Clause 2.2, l. -6 ff: Given the lack of shall/should/may
language, it is unclear whether one stipulates that one
checks that public keys in the certificate are on a specific curve (i.e.,
one does public key validation) or something more relaxed (such as checking
that the claimed elliptic curve domain parameters are the same, without
checking the public keys themselves. The para would benefit from some
firmed-up language here. This should also clarify whether one, in fact,
checks the validity of the certificate that included the public key
Good points. The language of this draft was based on that in Section 3.1.2 of
RFC 3278, but it could be firmed up.
With regard to parameter validation, SEC1 (Section 3.2.2) lists a few methods
by which a public-key can be checked for valid parameters:
* Full check,
* Partial check, and
* Trust the CA.
(I'm paraphrasing a bit.) Since RFC 5480 doesn't provide any way for the CA
to mark the parameters as 'checked' or 'not checked', I'll have our Draft say
that the sender and receiver:
* SHOULD do a full parameter check for standard ECDH, and
* SHOULD do a full check for co-factor ECDH, or failing that, SHOULD do a
partial check (as seems to be permitted in SEC1, Section 3.2.3).
***** Dr. Struik! This has been overtaken by events! ************
Due to IPR concerns, I have removed these checks from the draft. The relevant
sections now read:
Section 2.2:
When using static-static ECDH with EnvelopedData, the sending agent
first obtains the EC public key(s) and domain parameters contained in
the recipient's certificate. It MUST confirm the following at least
once per recipient-certificate:
o That both certificates (the recipient's certificate and its own)
contain public-key values with the same curve parameters, and
o That both of these public-key values are marked as appropriate for
ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or
id-ecDH [RFC5480]).
Section 2.3:
The receiver then retrieves the sender's certificate identified in
the rid field, and extracts the EC public key(s) and domain
parameters contained therein. It MUST confirm the following at least
once per sender-certificate:
o That both certificates (the sender's certificate and its own)
contain public-key values with the same curve parameters, and
o That both of these public-key values are marked as appropriate for
ECDH (that is, marked with algorithm-identifiers id-ecPublicKey or
id-ecDH [RFC5480]).
(T-k) p. 11, Clause 6, l. 3 (also l. 15): Why not introduce the CTR
encryption mode as an option, at least when authenticity is provided?
After all, CTR mode allows implementation of block-ciphers with just the
forward encryption mode and offers parallelization and precomputation
prospects.
I left it out because I have serious reservations about the security of
counter mode. But in looking in to your question, I see there's an even-more
serious problem: I can't find an RFC for AES-in-counter-mode for CMS.
Perhaps, though, my Google-foo is insufficient. Do you have a pointer to an
appropriate RFC?
Neither Dr. Struik nor I could find OIDs for AES in counter mode, and so they
remain absent from the Draft.
(T-l) General: When static-static ECDH, as specified here, stipulates
checking of the certificate including the public key and that certificate is
an ECDSA certificate, significant speed-ups of the computations are
possible by combining the key computation step and ECDSA signature
verification
-- cf.
http://www.ietf.org/proceedings/78/slides/saag-7.pdf.
or the SAC 2010 paper referenced in that IETF-78 presentation. These
results also apply here
(and can obviously be ignored or embraced depending upon implementation). I
would suggest adding a one-line statement that if ECDSA is used, one shall
use the "friendly ECDSA" scheme as in the IETF-78 presentation (which has
the same format as the ordinary one).
I told Dr. Struik that I preferred to leave this out of the draft, and he (I
believe) agreed.
Thanks all.
--
Jonathan Herzog voice: (781)
981-2356
Technical Staff fax: (781)
981-7687
Cyber Systems and Technology Group email:
jherzog(_at_)ll(_dot_)mit(_dot_)edu
MIT Lincoln Laboratory www:
http://www.ll.mit.edu/CST/
244 Wood Street
Lexington, MA 02420-9185
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf