On Mar 3, 2011, at 12:37 PM, Russ Housley wrote:
>
>
> Begin forwarded message:
>
>> From: Rene Struik <rstruik.ext@xxxxxxxxx>
>> Date: March 2, 2011 10:03:33 PM EST
>> To: ietf@xxxxxxxx
>> Subject: Re: Last Call: <draft-herzog-static-ecdh-04.txt> (Use of static-static Elliptic-Curve Diffie-Hellman key agreement in Cryptographic Message Syntax) to Informational RFC
>>
>> Dear colleagues:
>> Please find below my (modest) comments on draft-herzog-static-ecdh-05 (an update of the document that occurred since the moment
>> of issuing the LC).
Thanks for the comments. I've read through them, and plan to incorporate them into a -06 version in the next few days. Before I do, however, do you mind if I explain what I did and ask a few questions?
>> I. Editorial comments:
>>
>> (E-a) p. 1, Disclaimer, l. 3: "conclusions and" should read "conclusions, and".
I don't disagree, but the Disclaimer is a magic incantation we need to include verbatim in each of our documents. I cannot change it without invoking the wrath of our legal department, so I hope you'll kindly look the other way it if I leave it the way it is?
>> (E-b) p. 11, Clause 7, l. -2: "Consder" should read "Consider".
>> (E-c) p. 12, Clause 7, last para before two bullet points, l. 3: "reciever" should read "receiver".
Whoops. Thanks for catching these.
>> (E-d) p. 13, Clause 10.2, l. -3: The paper by Menezes and Ustaoglu has appeared in International Journal of Applied Cryptography,
>> Vol. 2, No. 2, pp. 154-158, 2010.
That's great news. Thanks for mentioning this. (Reference updated.)
>> (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?
>> II. Technical comments:
>>
>> (T-f) p. 5, Clause 1, forelast bullet: The term "data integrity" is more aptly called "data authenticity" (and would also align well with
>> AuthenticatedData CMS structure called out at the beginning of the same sentence).
We will change 'Data integrity' to 'data authenticity'.
>> NOTE - I am aware of the "attack in Clause 7, but this
>> attack seems to be more a flaw in the original CMS scheme, since effective irrespective of the key agreement method (i.e., not just static-
>> static-ECDH): A --> B: E_K(k) || Secured_k(m) allows any entity C who obtains the same key k to replace Secured_k(m) by another valid
>> string. This suggests that (1) one should call this out in the text; (2) one should fix the original problem with CMS (e.g., tieing k to K, the
>> originator, or recipient via, e.g., a one-way function.
I can call it out in the text, and will do so, but fixing the problem in CMS is a little beyond the scope of this Draft. We hope to address it a separate Draft (forthcoming).
>> (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.
The intention is that both sender and receiver must have certified public keys. From the abstract:
In this form of key-agreement, the Diffie-Hellman values of both
sender and receiver are long-term values contained in certificates.
Also, the fact that both sender and receiver must have certificates is implicit in Section 2.1:
o originator identifies the static EC public key of the sender. It
MUST be either issuerAndSerialNumber or subjectKeyIdentifier, and
point to one of the sending agent's certificates.
...
o recipientEncryptedKeys contains an identifier and an encrypted CEK
for each recipient. The RecipientEncryptedKey
KeyAgreeRecipientIdentifier MUST contain either the
issuerAndSerialNumber identifying the recipient's certificate or
the RecipientKeyIdentifier containing the subject key identifier
from the recipient's certificate.
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.
Do you think that these two changes would resolve the confusion?
>> (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).
(By the way, do you know if these validation checks exist in a RFC anywhere? I couldn't find them in RFC 6090...)
As for certificate validation: I'd prefer to remain silent on the issue. That is, I'd prefer to focus entirely on how to use the values found in the certificate. Issues regarding when, how often, and how to validate the certificate seem like much larger issues and out of scope. Thoughts?
But given the above, I've changed the language as follows:
Was:
When using static-static ECDH with EnvelopedData, the sending agent...
confirms that both
certificates contain public-key values with the same curve
parameters, and that both of these public-key values are marked as
appropriate for ECDH (that is, marked with algorithm-identifiers id-
ecPublicKey or id-ecDH [PKI-ECC]). The sender then determines:
o whether to use standard or cofactor Diffie-Hellman, and
o which hash algorithms to use for the key-derivation function...
IS NOW
When using static-static ECDH with EnvelopedData, the sending agent...
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]).
The sender then determines whether to use standard or cofactor
Diffie-Hellman. After doing so, the sender SHOULD validate the
receiver's public-key parameters at least once per public key:
o If standard Diffie-Hellman is to be used, the sender SHOULD use
the Elliptic Curve Public Key Validation Primitive found in
Section 3.2.2.1 of [SEC1].
o If cofactor Diffie-Hellman is to be used, the sender SHOULD use
the Elliptic Curve Public Key Validation Primitive found in
Section 3.2.2.1 of [SEC1]. If the sender chooses not to apply
this primitive (for performance reasons, perhaps) then it SHOULD
apply the Elliptic Curve Public Key Partial Validation Primitive
found in Section 3.2.3.1 of [SEC1].
The sender then determines which hash algorithms to use for the key-
derivation function...
>> (T-i) p. 7, Clause 2.3, l. 8 ff: same comment as T-h, but now for recipient's side.
WAS:
When using static-static ECDH with EnvelopedData, the receiving agent
retrieves keyEncryptionAlgorithm to determine the key-agreement
algorithm chosen by the sender, which will identify:
o the domain-parameters of the curve used,
o whether standard or cofactor Diffie-Hellman was used, and
o which hash-function was used for the KDF.
The receiver then retrieves the static EC public key identified in
the rid field. It confirms that both certificates contain public-key
values associated with the curve identified by the
keyEncryptionAlgorithm, and that both of these public-key values are
marked as appropriate for ECDH (that is, marked with algorithm-
identifiers id-ecPublicKey or id-ecDH [PKI-ECC]). The receiver then
determines a bit string "SharedInfo", which is the DER encoding of
ECC-CMS-SharedInfo (see Section 7.2 of [CMS-ECC]) and performs the
key agreement operation of the Elliptic Curve Diffie-Hellman Scheme
specified in [SEC1]; in either case, use the KDF defined in Section
3.6.1 of [SEC1]. As a result, the receiving agent obtains a shared
secret bit string "K", which it uses as the pairwise key-encryption
key to unwrap the CEK.
IS NOW:
When using static-static ECDH with EnvelopedData, the receiving agent
retrieves keyEncryptionAlgorithm to determine the key-agreement
algorithm chosen by the sender, which will identify:
o the domain-parameters of the curve used,
o whether standard or cofactor Diffie-Hellman was used, and
o which hash-function was used for the KDF.
The receiver then retrieves the sender's certificate identified in
the rid field. 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]).
The receiver then determines whether standard or cofactor Diffie-
Hellman was used. After doing so, the receiver SHOULD validate the
sender's public-key paramaters at least once per public key:
o If standard Diffie-Hellman is to be used: The receiver SHOULD use
the Elliptic Curve Public Key Validation Primitive found in
Section 3.2.2.1 of [SEC1].
o If cofactor Diffie-Hellman is to be used: The receiver SHOULD use
the Elliptic Curve Public Key Validation Primitive found in
Section 3.2.2.1 of [SEC1]. If the receiver chooses not to apply
this primitive (for performance reasons, perhaps) then it SHOULD
apply the Elliptic Curve Public Key Partial Validation Primitive
found in Section 3.2.3.1 of [SEC1].
The receiver then determines a bit string "SharedInfo", which is the
DER encoding of ECC-CMS-SharedInfo (see Section 7.2 of [RFC5753]) and
performs the key agreement operation of the Elliptic Curve Diffie-
Hellman Scheme specified in [SEC1]; in either case, use the KDF
defined in Section 3.6.1 of [SEC1]. As a result, the receiving agent
obtains a shared secret bit string "K", which it uses as the pairwise
key-encryption key to unwrap the CEK.
>> (T-j) p. 11, Clause 6, l. 4 (also l. 16): I was hoping that by now (2011), the unkeyed hash function SHA-1 would be moth-balled (rather than
>> reintroducing this option), more than 5 years after more serious SHA-1 attacks were presented in the academic community.
Fair enough. Shall I say that implementations SHOULD NOT support the SHA-1 schemes?
Along those same lines, I will also change the DES algorithms to SHOULD NOT.
>> (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?
(But your question did spur me to add AES in CCM and GCM as optional algorithms.)
>> (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).
That seems like an impressive speed-up, but is this really the right document for the SHALL you recommend? If I read your mail correctly (which I admit may not be the case) it sounds like your proposed SHALL is binding on the CA which issued either the sender's certificate or the receiver's certificate. If this is the case, I worry that it would be out of place in this draft, which (as written now) only becomes relevant after certificates are issued.
Or am I reading this incorrectly?
Thanks.
--
Jonathan Herzog voice: (781) 981-2356
Technical Staff fax: (781) 981-7687
Cyber Systems and Technology Group email: jherzog@xxxxxxxxxx
MIT Lincoln Laboratory www: http://www.ll.mit.edu/CST/
244 Wood Street
Lexington, MA 02420-9185
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf