Subject: [secdir] Secdir review of draft-herzog-static-ecdh-05

From: Brian Weis <[email-masked]>
Date: Wed, 2 Mar 2011 22:39:28 -0800

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

This document defines how two CMS agents use static Diffie-Hellman values for Elliptic Curve Diffie-Hellman key agreement. It is well written. I have just a few comments.

1. The Abstract and Introduction use the term "static-static" Elliptic Curve Diffie-Hellman key-agreement, which is a term not in common use. I guessed correctly that it meant the case where both participants in the key agreement were using static DH values, but I think until the term is define (later on in the Introduction) it would be clearer to say something like "Elliptic Curve Diffie-Hellman key-agreement where both participants use static Diffie-Hellman values".

2. Reference [SEC1] is heavily referenced in this document, for both a definition of ECDH and specific methods for using ECDH. But it would be good to also mention RFC 6090, which is the best IETF document describing ECDH.

3. Generally, when two parties use static DH values over different exchanges they will use the same key for each exchange, which is generally not a good practice. I believe this is true for ECDH as well. Sections 2.2 and 2.3 mention "SharedInfo", which when used appropriately will permute the shared key such that the sessions are not keyed identically. But I believe the use of "SharedInfo" is optional, so I was expecting the Security Considerations to describe this scenario and at least say that "SharedInfo" SHOULD be used (or possibly MUST be used). It would be good to add this discussion to Security Considerations.

Brian

---

From: Brian Weis <[email-masked]>
Date: Mon, 7 Mar 2011 21:15:06 -0800

Hi Jonathan,

On Mar 6, 2011, at 1:43 PM, Herzog, Jonathan - 0668 - MITLL wrote:

> 
> On Mar 3, 2011, at 1:39 AM, Brian Weis wrote:
> 
>> I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. 
> 
> I plan to address these comments and submit a new draft in the next few days. Before I do, however, do you mind if I asked you a few questions?
> 
> Good catch. I have included your suggestion in both the abstract:
> 
>      "This document describes how to use 'static-static' Elliptic
>      Curve Diffie-Hellman key-agreement (i.e., Elliptic Curve
>      Diffie-Hellman where both participants use static Diffie-Hellman
>      values) with the Cryptographic Message Syntax."
> 
> and the introduction:
> 
>   "This document describes how to use the static-static Elliptic-Curve
>   Diffie-Hellman key agreement scheme (i.e., Elliptic Curve Diffie-
>   Hellman [SEC1] where both participants use static Diffie-Hellman
>   values) in the Cryptographic Message Syntax (CMS) [CMS]."
> 
> And the rest of the introduction remains the same. Do you think this will be enough to orient the reader correctly?

That'll do the trick nicely, I think.
> I was not previous aware of this RFC-- my bad. I have added it as an informative reference, but continued to refer to [Sec1] as the normative reference for the ECDH operation. Or do you think that RFC 6090 should be the normative reference?

I would suggesting using RFC 6090 for a normative reference to ECDH if you need such a reference. But I don't believe RFC 6090 discusses static-static consideration or issues at all, so for that [Sec1] seems to be the appropriate normative reference.

> I'm not sure what you mean, here. Do you mean the SharedInfo value, or the ukm value? According to RFC 3278, the SharedInfo value is the DER encoding of the ECC-CMS-SharedInfo value:
> 
> 
>      ECC-CMS-SharedInfo ::= SEQUENCE {
>         keyInfo AlgorithmIdentifier,
>         entityUInfo [0] EXPLICIT OCTET STRING OPTIONAL,
>         suppPubInfo [2] EXPLICIT OCTET STRING   }
> 
> Also according to that RFC:
> 
>      entityUInfo optionally contains additional keying material
>      supplied by the sending agent.  When used with ECDH and CMS, the
>      entityUInfo field contains the octet string ukm.

> 
> So, my read of the RFC is that ECDH in CMS will always use a SharedInfo value to derive keys, and this value will contain a per-message unique value if and only if the ukm field was used by the sender. Now, the ukm value *is* optional, according to RFC 5652, which is why our Draft says they SHOULD be used:
> 
> Section 2.1:
> 
>   o  ukm MAY be present or absent.  However, message originators SHOULD
>      include the ukm.  As specified in [CMS], implementations MUST
>      support ukm message recipient processing, so interoperability is
>      not a concern if the ukm is present or absent.  The use of a fresh
>      value for ukm will ensure that a different key is generated for
>      each message between the same sender and receiver. ukm, if
>      present, is placed in the entityUInfo field of the ECC-CMS-
>      SharedInfo structure [CMS-ECC] and therefore used as an input to
>      the key derivation function.
> 
> 
> Security Considerations:
> 
>   Extreme care must be used when using static-static Diffie-Hellman
>   (either standard or cofactor) without the use of some per-message
>   value in ukm.  If no message-specific information is used (such as a
>   counter value, or a fresh random string) then the resulting secret
>   key could be used in more than one message.  Under some
>   circumstances, this will open the sender to the 'small subgroup'
>   attack [MenezesUstaoglu] or other, yet-undiscovered attacks on re-
>   used Diffie-Hellman keys.  Applications that cannot tolerate the
>   inclusion of per-message information in ukm (due to bandwidth
>   requirements, for example) SHOULD NOT use static-static ECDH for a
>   recipient without ascertaining that the recipient knows the private
>   value associated with their certified Diffie-Hellman value.
> 
> 
> So I'm under the impression that our Draft requires a ukm value (with a SHOULD), and that RFC 3278 requires that this ukm value be included in a SharedInfor value which is used to derive keys. But did I misread RFC 3278?

I did notice the text regarding ukm in your I-D, but definitely missed linkage you quote from RFC 3278 above. So rather than misreading RFC 3278 you've clarified it for me. :-) Your explanation makes sense to me.

> Do I need to explicitly require that the SharedInfo value be used?

I think your requirements are fine. But because you discuss both ukm and SharedInfo, I would clarifying their linkage. For example, in your Security Considerations you could mention the role of SharedInfo to permute the session so that two sessions setup between the same entities will be keyed independently, point out that CMS specifies that ukm is to be the value used in SharedInfo, and how ukm is determined so that it will properly do its job. This is also rationale for the SHOULD in section 2.1.

BTW, the RFC Index search engine says that RFC 3278 has been obsoleted by RFC 5753. You should reference that one (which hopefully makes the same statements regarding ukm).

Hope that helps,
Brian

> 
> Thanks.
> 
> -- 
> Jonathan Herzog							voice:  (781) 981-2356
> Technical Staff							fax:    (781) 981-7687
> Cyber Systems and Technology Group		email:  [email-masked]
> MIT Lincoln Laboratory               			www:    http://www.ll.mit.edu/CST/
> 244 Wood Street    
> Lexington, MA 02420-9185
> 

-- 
Brian Weis
Security Standards and Technology, ARTG, Cisco Systems
Telephone: +1 408 526 4796
Email: [email-masked]

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Sun, 6 Mar 2011 16:42:47 -0500

and the introduction:

Section 2.1:

Security Considerations:

So I'm under the impression that our Draft requires a ukm value (with a SHOULD), and that RFC 3278 requires that this ukm value be included in a SharedInfor value which is used to derive keys. But did I misread RFC 3278? Do I need to explicitly require that the SharedInfo value be used?

Thanks.

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Sun, 6 Mar 2011 16:43:19 -0500

and the introduction:

Section 2.1:

Security Considerations:

Thanks.

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Tue, 8 Mar 2011 11:10:05 -0500

>> I plan to address these comments and submit a new draft in the next few days. Before I do, however, do you mind if I asked you a few questions?

[snip]

> That'll do the trick nicely, I think.

Excellent. Thanks.

> I would suggesting using RFC 6090 for a normative reference to ECDH if you need such a reference. But I don't believe RFC 6090 discusses static-static consideration or issues at all, so for that [S…

I'm a little uneasy with using RFC 6090 as a normative reference for ECDH, as my impression is that the rest of CMS uses SEC1 as the normative reference. (See RFC 5753.) This may be because RFC 6090 is so new, but I'm worried that switching to RFC 6090 as the normative reference for ECDH will introduce subtle incompatibilities.

Also, RFC 6090 doesn't seem to include the cofactor ECDH operation (I think), or the use of the SharedInfo/ukm value.

Given this, do you mind if I keep SEC1 as normative and use RFC 6090 as informative?

[snip]

> I did notice the text regarding ukm in your I-D, but definitely missed linkage you quote from RFC 3278 above. So rather than misreading RFC 3278 you've clarified it for me. :-) Your explanation mak…

Ah, good.

> I think your requirements are fine. But because you discuss both ukm and SharedInfo, I would clarifying their linkage. For example, in your Security Considerations you could mention the role of Sha…

Good point. What do you think of the following change?

WAS

IS NOW

   Extreme care must be used when using static-static Diffie-Hellman
   (either standard or cofactor) without the use of some per-message
   value in ukm.  As described in [RFC5753], the ukm value (if present)
   will be embedded in a ECC-CMS-SharedInfo structure and the DER-
   encoding of this structure will be used as the 'SharedInfo' input to
   the ECDH key-agreement operation in [SEC1], Section 6.1.3.  The
   purpose of this input is to add a message-unique value to the key-
   distribution function so that two different sessions of static-static
   ECDH between a given pair of agents result in independent keys.  If
   the ukm value is not used or is re-used, on the other hand, then the
   ECC-CMS-SharedInfo structure (and 'SharedInfo' input) will likely not
   vary from message to message.  In this case, the two agents will re-
   use the same keying material across multiple messages.  This is
   considered to be bad cryptographic practice and may open the sender
   to attacks on Diffie-Hellman (e.g., the 'small subgroup' attack
   [MenezesUstaoglu] or other, yet-undiscovered attacks).

   It is for these reasons that Section 2.1 states that message-senders
   SHOULD include the ukm and SHOULD ensure that the value of ukm is
   unique to the message being sent.  One way to ensure the uniqueness
   of ukm is for the message sender to choose a 'sufficiently long'
   random string for each message (where, as a rule of thumb, a
   'sufficiently long' string is one at least as long as the keys used
   by the key-wrap algorithm identified in the keyEncryptionAlgorithm
   field of the KeyAgreeRecipientInfo structure).  However, other
   methods (such as a counter) are possible.  Also, applications which
   cannot tolerate the inclusion of per-message information in ukm (due
   to bandwidth requirements, for example) SHOULD NOT use static-static
   ECDH for a recipient without ascertaining that the recipient knows
   the private value associated with their certified Diffie-Hellman
   value.

> BTW, the RFC Index search engine says that RFC 3278 has been obsoleted by RFC 5753. You should reference that one (which hopefully makes the same statements regarding ukm).

Whoops! Good catch. Fortunately, the draft already did reference RFC 5753. My brain, on the other hand, seem to be taking longer to catch up. ;-)

Thanks.

---

From: Brian Weis <[email-masked]>
Date: Tue, 8 Mar 2011 09:13:26 -0800

Hi Jonathan,

> Given this, do you mind if I keep SEC1 as normative and use RFC 6090 as informative?

Sure, that's fine.

[snip]

> Good point. What do you think of the following change?

Bingo! That explanation seems both complete and clear to me. With that inclusion, I think its ready to publish.

Thanks,
Brian

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Tue, 8 Mar 2011 12:15:04 -0500

[Snip]

> Bingo! That explanation seems both complete and clear to me. With that inclusion, I think its ready to publish.

Great. Thanks so much for your comments.

---

From: Brian Weis <[email-masked]>
Date: Wed, 9 Mar 2011 10:53:50 -0800

Hi Jonathan,

No objections.

Thanks,
Brian

On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote:

> 
> On Mar 8, 2011, at 12:13 PM, Brian Weis wrote:
> 
>>>>> 
> I've thought a little more about this, and change my proposal to:
> 
> * Reference RFC 6090 for ECDH in general, but
> * SEC1 for co-factor ECDH, the public-key validation primitives, and the key-derivation function (KDF).
> 
> Unfortunately, none of those algorithms in the second bullet are present in RFC 6090. (Though the security considerations of RFC 6090 discuss why one would want to validate public keys, it doesn't describe how to do so.)
> 
> 
> Any objections?
> 
> Thanks.
> --

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Wed, 9 Mar 2011 13:34:40 -0500

Any objections?

Thanks.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Mar 2011 20:31:42 +0000

Hi,

I've three concerns about this.

1) Now that we have 6090, if there's a way to do any ECC stuff
that can be built *only* on that, then that IMO gives a much
better basis on which implementers might have confidence in
their IPR situation. I think every reference to e.g. [SEC1]
included muddies those waters somewhat and hence may further
delay widespread adoption of ECC. Since the authors presumably
would like to see adoption, I wonder is there any way to
excise [SEC1] entirely and just use 6090 or other things with
perhaps clearer IPR? (If there are technical issues with how
to only use 6090 perhaps checking with cfrg and/or the authors
of 6090 would help.)

2) If [SEC1] remains as a reference, do we expect to get an
IPR declaration related to this? Have the authors asked anyone
from Certicom?

3) As far as I recall the only use-case specific to static-static
is that it allows employers to wiretap much more easily that
ephemeral-static. Am I right there? (Its been a while.) If not,
then I would suggest adding some use-case so that people might
know when to go for this setup and when to go for
ephemeral-static. If I am right above, then I think that warrants
some security consideration and even more guidance as to when
its appropriate to use static-static. (And I'd have to wonder
if its worthwhile as an RFC personally, but then I guess some
"customers" do like static-static for exactly this reason.)

Thanks,
Stephen.

---

From: David McGrew <[email-masked]>
Date: Wed, 9 Mar 2011 12:32:49 -0800

Hi Jonathan,

On Mar 9, 2011, at 10:34 AM, Herzog, Jonathan - 0668 - MITLL wrote:

>>>>>> 2. Reference [SEC1] is heavily referenced in this document, for  
>>>>>> both a definition of ECDH and specific methods for using ECDH.  
>>>>>> But it would be good to also mention RFC 6090, which is the  
>>>>>> best IETF document describing ECDH.
>>>>>
>>>>> I was not previous aware of this RFC-- my bad. I have added it  
>>>>> as an informative reference, but continued to refer to [Sec1] as  
>>>>> the normative reference for the ECDH operation. Or do you think  
>>>>> that RFC 6090 should be the normative reference?
>>>>
>>>> I would suggesting using RFC 6090 for a normative reference to  
>>>> ECDH if you need such a reference. But I don't believe RFC 6090  
>>>> discusses static-static consideration or issues at all, so for  
>>>> that [Sec1] seems to be the appropriate normative reference.
>>>
>>> I'm a little uneasy with using RFC 6090 as a normative reference  
>>> for ECDH, as my impression is that the rest of CMS uses SEC1 as  
>>> the normative reference. (See RFC 5753.) This may be because RFC  
>>> 6090 is so new, but I'm worried that switching to RFC 6090 as the  
>>> normative reference for ECDH will introduce subtle  
>>> incompatibilities.
>>>
>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH operation  
>>> (I think), or the use of the SharedInfo/ukm value.
>>>
> Unfortunately, none of those algorithms in the second bullet are  
> present in RFC 6090. (Though the security considerations of RFC 6090  
> discuss why one would want to validate public keys, it doesn't  
> describe how to do so.)

That's exactly right.  RFC6090 should be referenced for ECDH, but not  
cofactor-ECDH.

I would like to know: why does the draft reference [SEC1] instead of a  
NIST or IEEE standard?  I would strongly prefer to see explicit  
references to the appropriate NIST algorithms and KDFs in this  
document.  That would make it clear that the specification conformed  
to the NIST crypto guidelines, and that is apparently a goal for the  
document.  It mentions Suite B conformance as a motivator, and Suite B  
references the NIST guidelines.  I think the document describes  
something useful, and that it would be more valuable if it referenced  
the NIST specifications.   Probably the easiest way to do this would  
be to add an additional reference, rather than replace the references  
to [SEC1].

Here is some detail on how RFC6090 EDCH can be used to implement  
static-static ECDH as it is defined by NIST SP 800-56A.  RFC6090  
describes how the ECDH protocol it describes can interoperate with the  
ECSVDP-DH primitive.  NIST SP 800-56 defines static-static ECDH using  
a primitive which it calls the "unified cofactor method", the ECC CDH  
primitive in SP800-56 Section 5.7.1.2 (in conjunction with a NIST- 
defined KDF).   The "unified cofactor method" is equivalent to the  
RFC6090 ECDH when the cofactor h=1.  I'll outline the correspondence.   
The "unified cofactor method" is:

Input:
1. (q, FR, a, b{, SEED}, G, n, h): Domain parameters,
2. dA : One’s own private key, and
3. QB : The other party’s public key.
Process:
1. Compute the point P = hdAQB.
2. If P = O, output an error indicator.
3. Z = xP where xP is the x-coordinate of P.

And here is the table of correspondence between parameters:

SP-800-56A   RFC6090
  q             p
  a             a
  b             b
  G             g
  h             1

h is not used in RFC6090; is is the cofactor associated with the  
elliptic curve generator.  when h=1, ECC CDH is equivalent to ECDH

FR is not used in RFC6090; it is an indication of the field  
representation in ANSI X9.63

SEED is not used in RFC6090; it is an indication of how the ECC  
parameters were created

David

> _______________________________________________
> secdir mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/secdir

---

From: David McGrew <[email-masked]>
Date: Wed, 9 Mar 2011 12:56:43 -0800

Hi Stephen,

> to only use 6090 perhaps checking with cfrg and/or the authors

I think that RFC6090, combined with NIST SP800-56A, could be used as  
the sole normative reference for static-static ECDH (the vanilla  
flavored variant, not the cofactor variant).  I sketched some thoughts  
in that direction in a separate email.  Jonathan, what do you think?

Jonathan was correct that RFC6090 can't be used as a reference for the  
cofactor variant.

David

>>>>>>>> 2. Reference [SEC1] is heavily referenced in this document,  
>>>>>>>> for both a definition of ECDH and specific methods for using  
>>>>>>>> ECDH. But it would be good to also mention RFC 6090, which is  
>>>>>>>> the best IETF document describing ECDH.
>>>>>>>
>>>>>>> as an informative reference, but continued to refer to [Sec1]  
>>>>>>> as the normative reference for the ECDH operation. Or do you  
>>>>>>> think that RFC 6090 should be the normative reference?
>>>>>>
>>>>> 6090 is so new, but I'm worried that switching to RFC 6090 as  
>>>>> the normative reference for ECDH will introduce subtle  
>>>>> incompatibilities.
>>>>>
>>>>> Also, RFC 6090 doesn't seem to include the cofactor ECDH  
>>>>> operation (I think), or the use of the SharedInfo/ukm value.
>>>>>
>>> present in RFC 6090. (Though the security considerations of RFC  
>>> 6090 discuss why one would want to validate public keys, it  
>>> doesn't describe how to do so.)
>>>
>>>
>>> Any objections?
>>>
>>> Thanks.
>>> --

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Wed, 9 Mar 2011 16:09:04 -0500

> to only use 6090 perhaps checking with cfrg and/or the authors

We currently (in the -06 version, not yet submitted to the IETF) cite SEC1 for only the following:

1) Co-factor ECDH,
2) Validation of public-key parameters (both full and partial), and
3) A key-derivation function.

I am sure we can find another RFC to cite for (3). Unfortunately, however, neither (1) nor (2) seem to be in RFC 6090. (At least, I didn't see it there. I could be wrong.)

I just realized, however, that we can cite NIST SP 800-56A for both (1) and (2). Interestingly, that SP only permits/specifies static-static cofactor ECDH, not static-static standard ECDH. But that may not be relevant-- we can still cite RFC 6090 for standard ECDH.

So, I propose to replace SEC1 with SP 800-56A for (1) and (2), and some other RFC for (3). Would that address your concerns?

> IPR declaration related to this? Have the authors asked anyone

We have not asked anyone from Certicom, no.

But if we remove SEC1 entirely, does the issue become moot?

> ephemeral-static. Am I right there?

I'm not sure what you mean by this, but I'm fairly sure it's not our motivation. We propose this draft because we would like to use CMS in an environment where:

1) Participants must use Suite-B algorithms, and therefore cannot use ECMQV, and

2) Participants will have certified ECDH keys but not certified signature keys. (Yes, ECDH keys are mathematically identical to ECDSA keys, but our participants will be constrained by various policies and will be unable to use their ECDH keys for ECDSA signatures.)

Without this Draft, CMS supports only ECMQV (which we cannot use) and ephemeral-static ECDH. In our setting, then, there is no way for recipients to cryptographically ascertain the identity of a message's sender. Now (and as we explain in the Security Considerations) it is true that this Draft does not fully solve the problem of data authentication in the fully general case. But (1) it gets fairly close, at least in the case of a single recipient, and (2) we believe that the 'attack' described in the Security Considerations is better addressed by a separate Draft. 

> (Its been a while.) If not,

Given what I say above, would you rather see more explanation in the Security Considerations, or to the discussion of our motivations in the Introduction?

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Wed, 9 Mar 2011 16:47:45 -0500

On Mar 9, 2011, at 3:32 PM, David McGrew wrote:

> NIST or IEEE standard?

No particular reason. Obviously, this was a bad choice on my part.

>  I would strongly prefer to see explicit  
> RFC6090 ECDH when the cofactor h=1.  

[snip]

Right: standard ECDH is the same as cofactor ECDH when the cofactor h = 1. Granted, this is true for the two Suite B curved (P256 and P384) but not true for all the curved named in FIPS 186-3 / RFC 5480. (For the curves over binary fields, the co-factor can be h = 2 or h = 4.) So unless I'm missing something (which is more than likely) I don't think we can use RFC 6090 for both standard ECDH and cofactor ECDH for all curves in FIPS 186-3.

However, SP800-56A does define cofactor ECDH. So let me propose the following citation scheme:

* ECDH in general: RFC 6090
* Standard ECDH: RFC 6090
* Co-factor Diffie-Hellman: SP 800-56A, Section 5.7.1.2
* Full public-key validation: SP800-56A, Section 5.6.2.5
* Partial public-key validation: SP800-56A: Section 5.6.2.6
* Key-derivation function... still working on it.

Thoughts?

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 09 Mar 2011 22:49:53 +0000

Hi Jonathan,

> So, I propose to replace SEC1 with SP 800-56A for (1) and (2), and some other RFC for (3). Would that address your concerns?

To be honest, I don't know for sure. I'm not familiar with how
NIST do or don't handle IPR so I don't know if the outcome
here will or won't make it easier for implementers to decide
whether or no to adopt this. But I think you're definitely
working in the right direction in the thread with David so
that's good.

> But if we remove SEC1 entirely, does the issue become moot?

I wish;-) Not sure I've seen an RFC about ECC that didn't
come with an IPR declaration from them attached. (Though
the content of those declarations is improving.)

> I'm not sure what you mean by this, 

I'm thinking of schemes from some years ago where the
requirement was to be able to decrypt outbound mails at
the outbound MTA when sender private values had been
centrally generated. I don't really recall any other
specific benefit of static-static.

> but I'm fairly sure it's not our motivation.

Sure. I wasn't trying to say it was.

> We propose this draft because we would like to use CMS in an
environment where:
> Without this Draft, CMS supports only ECMQV (which we cannot use) and ephemeral-static ECDH. In our setting, then, there is no way for recipients to cryptographically ascertain the identity of a message's sender. 

I think that's useful context for the intro.

Now (and as we explain in the Security Considerations) it is true that
this Draft does not fully solve the problem of data authentication in
the fully general case. But (1) it gets fairly close, at least in the
case of a single recipient, and (2) we believe that the 'attack'
described in the Security Considerations is better addressed by a
separate Draft.

To be honest I'll have to read the draft again to answer
that, and its late here. Tomorrow.

Cheers,
S.

---

From: David McGrew <[email-masked]>
Date: Thu, 10 Mar 2011 10:12:05 -0800

Hi Jonathan,

> No particular reason. Obviously, this was a bad choice on my part.

"You are lost in a maze of public key cryptography standards, all  
nearly alike"   I've had that feeling before ;-)

> Right: standard ECDH is the same as cofactor ECDH when the cofactor  
> h = 1. Granted, this is true for the two Suite B curved (P256 and  
> P384) but not true for all the curved named in FIPS 186-3 / RFC  
> 5480. (For the curves over binary fields, the co-factor can be h = 2  
> or h = 4.) So unless I'm missing something (which is more than  
> likely) I don't think we can use RFC 6090 for both standard ECDH and  
> cofactor ECDH for all curves in FIPS 186-3.

That's right, you're not missing anything.

> * Key-derivation function... still working on it.

That looks good to me.  Let me know if I can help with the KDF.

David

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Thu, 10 Mar 2011 15:41:52 -0500

> That looks good to me.  Let me know if I can help with the KDF.

I'd appreciate it, thanks. One of the goals of this draft is to remain as compatible with RFC 5753 as possible, so as to impact implementations as little as possible. RFC 5753, for its part, specifies the KDF in SEC1. And the KDF in SEC1 is just the 'simple hash function construct described in ANSI X9.63'. So, do you think I can cite X9.63 as the normative reference? And if so, what are your thoughts on citing SEC1 as an informative reference for this KDF? SEC1 is, after all, freely available on the web.

(Note: I'm still chasing down the ANSI spec to ensure that it does, in fact, match the description in SEC1.)

Thanks.

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Thu, 10 Mar 2011 16:02:51 -0500

> working in the right direction in the thread with David so

[and]

> the content of those declarations is improving.)

Sean Turner has graciously agreed to step in and handle the IPR issues of this draft, so I'll let him address this.

> I think that's useful context for the intro.

Based on this, and some other comments from Rene Struik, I will try to make this clearer in the 'motivations' section of the Introduction.

Thanks.

---

From: David McGrew <[email-masked]>
Date: Fri, 11 Mar 2011 12:32:45 -0800

Hi Jonthan,

On Mar 10, 2011, at 12:41 PM, Herzog, Jonathan - 0668 - MITLL wrote:

> I'd appreciate it, thanks. One of the goals of this draft is to  
> remain as compatible with RFC 5753 as possible, so as to impact  
> implementations as little as possible. RFC 5753, for its part,  
> specifies the KDF in SEC1. And the KDF in SEC1 is just the 'simple  
> hash function construct described in ANSI X9.63'. So, do you think I  
> can cite X9.63 as the normative reference? And if so, what are your  
> thoughts on citing SEC1 as an informative reference for this KDF?  
> SEC1 is, after all, freely available on the web.

Good point.

I hope that the KDF from X9.63 that is referenced in SEC1 is the  
Concatenation Key Derivation Function (Section 5.8.1 of SP800-56A), or  
if not, the ASN.1 Key Derivation Function (Section 5.8.2).   The  
800-56A text on key agreement schemes says that they are based on  
X9.63 algorithms, though it doesn't explicitly mention the KDFs.

David

---

From: Sean Turner <[email-masked]>
Date: Mon, 14 Mar 2011 15:52:10 -0400

On 3/14/11 9:47 AM, Herzog, Jonathan - 0668 - MITLL wrote:
>
> On Mar 11, 2011, at 4:13 PM, Herzog, Jonathan - 0668 - MITLL wrote:
>> On Mar 11, 2011, at 3:32 PM, David McGrew wrote:
>>>
>>> if not, the ASN.1 Key Derivation Function (Section 5.8.2).
>>
>>
>> Mostly 'yes,' but just enough 'no' to be a real problem for us. Both the KDF in SEC1/X9.63 and the KDFs in 800-56A take the Diffie Hellman secret and some Other Stuff, and produce keying material as output.  But they are not the exact same KDF. From SP 800-56A, Appendix A ("Summary of Differences between this Recommendation and ANS X9 Standards"):
>>
>> [Begin quote]
>>
>> 8.	Regarding the key derivation function (KDF):
>>
>> a. This recommendation specifies two Approved KDFs, the concatenation KDF specified in Section 5.8.1 and the ASN.1 KDF specified in Section 5.8.2. Other key derivation methods may be temporarily allowed for backward compatibility. These other allowable methods and any restrictions on their use will be specified in FIPS 140-2 Annex D.
>>
>> b. ANS X9.42 provides a concatenation KDF and an ASN.1 KDF, while ANS X9.63 provides only the concatenation KDF. However, the Approved KDFs of this Recommendation require that the counter appears before the shared secret as input to the hash function, whereas the ANSI KDFs place the counter after the shared secret
>>
>> c. The Approved KDFs in this Recommendation require the input of the identifiers of the communicating parties; such information is not required in ANS X9.42 and X9.63.
>>
>> d. In this Recommendation, the shared secret is zeroized after a single call to a key derivation function, before the key agreement scheme releases any portion of the DerivedKeyingMaterial for use by relying applications.. The ANS X9.42 and X9.63 standards do not indicate when the shared secret needs to be zeroized. An implication of this Recommendation’s requirement concerning zeroization is that all of the keying material directly derived from the shared secret must be computed during one call to the KDF.
>>
>> [End quote]
>>
>> Point (d) is not an issue for this discussion, and point (a) is just informative. But points (b) and (c) are both show-stoppers. Point (b) says that SEC1/X9.63 and SP 800-56A disagree on how to turn the inputs into keying material. Point (c) says that they disagree on what the Other Stuff must contain. Specifically, SP 800-56A requires that the Other Stuff contain:
>>
>> * ID of the algorithm,
>> * ID of the sender,
>> * ID of the receiver,
>> * Sender randomness (optional), and
>> * Receiver randomness (optional).
>>
>> SEC1 places no restriction on the Other Stuff. But RFC 5753 says that the Other Stuff must be the DER encoding of an ECC-CMS-SharedInfo structure, which contains:
>>
>> * ID of the algorithm,
>> * Sender randomness (optional), and
>> * Length of output key (optional).
>>
>> So unless I'm wrong (again, more than likely) the SEC1/X9.63 and SP 800-56A KDFs are not compatible. And in fact, we can't switch to the SP 800-56A KDFs without introducing some tricky incompatibilities with RFC 5753. (Implementors would have to implement one KDF for ephemeral-static ECDH and a different one for static-static ECDH).
>>
>> Given this, what do people think of citing X9.63 for the KDF? And about citing SEC1 as an informative reference so that people can find the KDF without having to buy an ANSI standard?
>
> I was advised to submit an updated draft over the weekend, even if some issues were still up in the air. So, draft-herzog-static-ecdh-06.txt has been submitted and is awaiting manual posting. In the meantime, a copy is attached to this mail. As you can see, I went ahead and made the change I proposed above: citing X9.63 as the normative standard for the KDF in RFC 5753, wit SEC1 as an informative reference.
>
> Thoughts?

While I'd prefer a pointer to NIST specs, I think we have to maintain 
compatibility with RFC 5753 (i.e., doing the KDF one way for SS ECDH and 
another way for ES ECDH just seems like a bad idea).  I like the 
approach of pointing to ANSI normatively and SEC1 informatively.

spt

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Fri, 11 Mar 2011 16:13:40 -0500

[Begin quote]

[End quote]

* ID of the algorithm,
* ID of the sender,
* ID of the receiver,

* ID of the algorithm,

Thanks.

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Mon, 14 Mar 2011 09:47:14 -0400

Thoughts?

Cheers.

---

From: Uri Blumenthal <[email-masked]>
Date: Tue, 15 Mar 2011 16:27:24 -0400

Without diving into the details of various KDF and their cryptographic 
soundness
- I think the proposal to cite X9.63 as normative and SEC1 as informative is
good.

Thanks!
--
<Disclaimer>

Quoting "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>:
>> Mostly 'yes,' but just enough 'no' to be a real problem for us. Both 
>> the KDF in SEC1/X9.63 and the KDFs in 800-56A take the Diffie 
>> Hellman secret and some Other Stuff, and produce keying material as 
>> output.  But they are not the exact same KDF. From SP 800-56A, 
>> Appendix A ("Summary of Differences between this Recommendation and 
>> ANS X9 Standards"):
>>
>> [Begin quote]
>>
>> a. This recommendation specifies two Approved KDFs, the 
>> concatenation KDF specified in Section 5.8.1 and the ASN.1 KDF 
>> specified in Section 5.8.2. Other key derivation methods may be 
>> temporarily allowed for backward compatibility. These other 
>> allowable methods and any restrictions on their use will be 
>> specified in FIPS 140-2 Annex D.
>>
>> b. ANS X9.42 provides a concatenation KDF and an ASN.1 KDF, while 
>> ANS X9.63 provides only the concatenation KDF. However, the Approved 
>> KDFs of this Recommendation require that the counter appears before 
>> the shared secret as input to the hash function, whereas the ANSI 
>> KDFs place the counter after the shared secret
>>
>> c. The Approved KDFs in this Recommendation require the input of the 
>> identifiers of the communicating parties; such information is not 
>> required in ANS X9.42 and X9.63.
>>
>> d. In this Recommendation, the shared secret is zeroized after a 
>> single call to a key derivation function, before the key agreement 
>> scheme releases any portion of the DerivedKeyingMaterial for use by 
>> relying applications.. The ANS X9.42 and X9.63 standards do not 
>> indicate when the shared secret needs to be zeroized. An implication 
>> of this Recommendation?s requirement concerning zeroization is that 
>> all of the keying material directly derived from the shared secret 
>> must be computed during one call to the KDF.
>>
>> [End quote]
>>
>> Point (d) is not an issue for this discussion, and point (a) is just 
>> informative. But points (b) and (c) are both show-stoppers. Point 
>> (b) says that SEC1/X9.63 and SP 800-56A disagree on how to turn the 
>> inputs into keying material. Point (c) says that they disagree on 
>> what the Other Stuff must contain. Specifically, SP 800-56A requires 
>> that the Other Stuff contain:
>>
>> * ID of the algorithm,
>> * ID of the sender,
>> * ID of the receiver,
>> SEC1 places no restriction on the Other Stuff. But RFC 5753 says 
>> that the Other Stuff must be the DER encoding of an 
>> ECC-CMS-SharedInfo structure, which contains:
>>
>> * ID of the algorithm,
>> So unless I'm wrong (again, more than likely) the SEC1/X9.63 and SP 
>> 800-56A KDFs are not compatible. And in fact, we can't switch to the 
>> SP 800-56A KDFs without introducing some tricky incompatibilities 
>> with RFC 5753. (Implementors would have to implement one KDF for 
>> ephemeral-static ECDH and a different one for static-static ECDH).
>>
>> Given this, what do people think of citing X9.63 for the KDF? And 
>> about citing SEC1 as an informative reference so that people can 
>> find the KDF without having to buy an ANSI standard?
>
> I was advised to submit an updated draft over the weekend, even if 
> some issues were still up in the air. So, 
> draft-herzog-static-ecdh-06.txt has been submitted and is awaiting 
> manual posting. In the meantime, a copy is attached to this mail. As 
> you can see, I went ahead and made the change I proposed above: 
> citing X9.63 as the normative standard for the KDF in RFC 5753, wit 
> SEC1 as an informative reference.
>
> Thoughts?
>
> Cheers.
>
> --

---

From: Sean Turner <[email-masked]>
Date: Wed, 16 Mar 2011 19:58:03 -0400

> On Mar 9, 2011, at 5:49 PM, Stephen Farrell wrote:

..snip

> Sean Turner has graciously agreed to step in and handle the IPR issues of this draft, so I'll let him address this.

I submitted a 3rd party IPR statement at 6pm.  I should have done it but 
forgot.  It's the same ol' Certicom IPR.  I submitted the same 3rd party 
earlier on another draft that mentioned EC algs.

spt

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2011 00:36:04 +0000

I had a quick look at the -06 version.

It still doesn't call out what I think is the real functional
difference between static-static (s-s) and ephemeral-static (e-s)
which is that with centrally generated private values s-s allows
an outbound application layer gateway to decrypt and filter
traffic before it leaves the "key generating" domain. With e-s
and signing keys, which are the alternative, that is not possible.

Some people would like exactly that as a feature. Others would
consider it anathema. I think this ought be explicitly called out
in the text so that someone who cares doesn't pick the scheme
the don't like by accident.

S.

On 16/03/11 23:58, Sean Turner wrote:
>> Sean Turner has graciously agreed to step in and handle the IPR issues
>> of this draft, so I'll let him address this.
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 17 Mar 2011 02:37:41 +0000

On 17/03/11 01:23, Herzog, Jonathan - 0668 - MITLL wrote:
> 
> I apologize-- when you mentioned this before, I thought you were merely curious about our motivations. I didn't realize that you were suggesting/requesting additional discussion of the topic in the Draft. But your point about this feature of static-static ECDH is well-taken. If you think that it would serve the reader for the document to discuss this, then it should clearly be discussed. I'm not exactly sure what the protocol is for making changes this close to the scheduled discussion, but we would be happy to add a paragraph to the Security Considerations along the lines of:
> 
> 
> "When two parties are communicating using static-static ECDH as described in this document, and either party's asymmetric keys have been centrally generated, it is possible for that party's central infrastructure to decrypt the communication (for application-layer network monitoring or filtering, for example). By way of contrast: were ephemeral-static ECDH to be used instead, such decryption would not be possible by the sender's infrastructure (though it would remain possible for the infrastructure of any recipient.)"
> 
> 
> Thoughts?

Looks fine to me. With an addition like that I'd have no
problem with this.

Formally, I guess just wait and see what the IESG say about
the doc and then update as appropriate. Adding a paragraph
like the above shouldn't be an issue in any event I'd say.

Thanks,
S.

> 
> On Mar 16, 2011, at 8:36 PM, Stephen Farrell wrote:
> 
>>

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Tue, 15 Mar 2011 17:07:59 -0400

On Mar 10, 2011, at 3:41 PM, Herzog, Jonathan - 0668 - MITLL wrote:
> 
> From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
> Date: March 10, 2011 3:41:52 PM EST
> To: David McGrew <[email-masked]>
> Cc: Brian Weis <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
> Subject: Re: [secdir] Secdir review of draft-herzog-static-ecdh-05
> 
> 
> 

Just to follow up on this: I got the X9.63 spec and checked its KDF. It's the same as the one in SEC1. Some very very minor differences in the description, but it's the same KDF.

Thanks.

---

From: "Herzog, Jonathan - 0668 - MITLL" <[email-masked]>
Date: Wed, 16 Mar 2011 21:23:47 -0400

Thoughts?

---

From: Uri Blumenthal <[email-masked]>
Date: Mon, 21 Mar 2011 11:33:28 -0400

In that case - since X9.63 and SEC1 turned out to be the same - would it
make sense to reverse them in Normative/Informative status? My reasoning
is - SEC1 is freely available, and X9.63 seems to be available only for
a fee.

Either way is OK with me.

Thanks!

-- 
Regards,
Uri