Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs

From: Richard Barnes <[email-masked]>
Date: Fri, 4 Oct 2013 14:11:29 -0400

I'm fine removing the MUST (this doesn't really seem like a 2119 thing).
 How about this?

"""
Each application should specify how senders populate the "apu" and "apv"
parameters in the context of that application.  Applications wishing to
conform to [NIST.800-56A] need to provide values that meet the requirements
of that document, e.g., by using values that identify the sender and
recipient.  Alternatively, applications MAY conduct key derivation in a
manner similar to [RFC2631]: In that case, the "apu" field MAY either be
omitted or represent a random 512-bit value (analogous to PartyAInfo in
Ephemeral-Static mode in [RFC2631]) and the "apv" field should not be
present.
"""

On Wed, Sep 11, 2013 at 2:55 PM, Brian Campbell
<[email-masked]>wrote:

> Much improved, thanks.
>
> I'm still not crazy about the first sentence though. Really the sender
> specifies the "apu" and "apv" values simply by sending them or omitting
> them (James made a similar point last week). I think that as far as JOSE
> should go with it normatively. Applications may specify additional
> constraints on the use and values for "apu" and "apv", if appropriate for
> their context. Can it say something more like that? Or at least drop that
> first MUST?
>
>
>
> On Thu, Sep 5, 2013 at 6:31 PM, Mike Jones <[email-masked]>wrote:
>
>>  Thanks for doing this research, Brian.  We only support
>> ephemeral-static mode, so your findings are quite pertinent.  I therefore
>> propose that we further revise the text as follows:****
>>
>> ** **
>>
>> Applications MUST specify what values should be used in the "apu" and
>> "apv" parameters.  Applications wishing to conform to [NIST.800-56A] need
>> to provide values that meet the requirements of that document, e.g., by
>> using values that identify the sender and recipient.  Alternatively,
>> applications MAY conduct key derivation in a manner similar to [RFC2631]:
>> In that case, the "apu" field MAY either be omitted or represent a
>> random 512-bit value (analogous to PartyAInfo in Ephemeral-Static modein [RFC2631]) and the "apv" field should not be present.
>> ****
>>
>> ** **
>>
>>                                                                 -- Mike**
>> **
>>
>> ** **
>>
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Brian Campbell
>> Sent: Thursday, September 05, 2013 5:21 PM
>> To: Mike Jones
>> Cc: Richard Barnes; jose issue tracker; <
>> [email-masked]>; [email-masked]
>> Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs
>>
>> ** **
>>
>> RFC 2631 requires the 512 bits of partyAInfo only for Static-Static mode
>> while using it for Ephemeral-Static is just a 'MAY'.****
>>
>> ** **
>>
>> I guess that's what the proposed JOSE text says too. But the MAY followed
>> by the conditional SHOULD reads kind of funny. And as someone who's asked
>> for some more clarity and guidance on the use of "apu" and "apv" that text
>> didn't leave me felling sure of what to do with them but made me feel like
>> I probably needed to put 512 bits of stuff in there.****
>>
>> ** **
>>
>> On Thu, Sep 5, 2013 at 2:25 PM, Mike Jones <[email-masked]>
>> wrote:****
>>
>> > I also stated on the call that the 512 additional bits of entropy don't
>> any value to the randomness already present in the ephemeral key.****
>>
>> >** **
>>
>> > I perceive the 512 bit text as being there to make people who are
>> enamored of RFC 2631 key agreement happy, by telling them how they could do
>> the same thing in this case.  I personally believe we're better off if
>> applications just say what they expect to be in "apu" and "apv" (if
>> anything) and ignore the 2631 backup plan.****
>>
>> >** **
>>
>> >                                 -- Mike****
>>
>> >** **
>>
>> > -----Original Message-----****
>>
>> > From: Brian Campbell [mailto:[email-masked]<[email-masked]>
>> ]****
>>
>> > Sent: Thursday, September 05, 2013 2:20 PM****
>>
>> > To: Mike Jones****
>>
>> > Cc: Richard Barnes; jose issue tracker; [email-masked]; ** **
>>
>> > <[email-masked]>****
>>
>> > Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs****
>>
>> >** **
>>
>> > Is there anyone who can explain where the 512 bits comes from and what
>> value it adds for JOSE's use of ECDH-ES case?****
>>
>> >** **
>>
>> > My sense from the call yesterday was that I wasn't the only one that
>> didn't grok what value these additional inputs into the KDF really provide.
>> ****
>>
>> >** **
>>
>> > For the compact serialization, if possible/reasonable, I'd like to
>> avoid the overhead of adding 512 more bits that will be base64url encoded
>> twice.****
>>
>> >** **
>>
>> >** **
>>
>> >** **
>>
>> >** **
>>
>> >** **
>>
>> >** **
>>
>> >** **
>>
>> >** **
>>
>> >** **
>>
>> > On Thu, Sep 5, 2013 at 12:28 PM, Mike Jones <
>> [email-masked]> wrote:****
>>
>> >> Thanks for the new text, Richard.  Slight consistency edits proposed *
>> ***
>>
>> >> below...****
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >> Applications MUST specify what values should be used in the "apu" and
>> "apv"****
>>
>> >> parameters.  Applications wishing to conform to [NIST.800-56A] need **
>> **
>>
>> >> to provide values that meet the requirements of that document, e.g., *
>> ***
>>
>> >> by choosing values that identify the sender and recipient.****
>>
>> >> Alternatively, applications MAY conduct key derivation in a manner ***
>> *
>>
>> >> similar to [RFC2631]: In that case, the "apu" field SHOULD represent *
>> ***
>>
>> >> a random 512-bit value (analogous to PartyAInfo in [RFC2631]) and the
>> ****
>>
>> >> "apv" field should not be present.****
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >>                                                             -- Mike***
>> *
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >> From: Richard Barnes [mailto:[email-masked] <[email-masked]>]****
>>
>> >> Sent: Thursday, September 05, 2013 8:23 AM****
>>
>> >> To: jose issue tracker****
>>
>> >> Cc: <[email-masked]>;****
>>
>> >> [email-masked]****
>>
>> >> Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs****
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >> As promised on the call yesterday, here's some proposed revision to **
>> **
>>
>> >> Section****
>>
>> >> 4.7.2:****
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >> OLD:****
>>
>> >>** **
>>
>> >> """****
>>
>> >>** **
>>
>> >>    Note: The Diffie-Hellman Key Agreement Method [RFC2631] uses a key*
>> ***
>>
>> >>** **
>>
>> >>    derivation function similar to the Concat KDF, but with fewer****
>>
>> >>** **
>>
>> >>    parameters.  Rather than having separate PartyUInfo and PartyVInfo*
>> ***
>>
>> >>** **
>>
>> >>    parameters, it uses a single PartyAInfo parameter, which is a ****
>>
>> >> random****
>>
>> >>** **
>>
>> >>    string provided by the sender, that contains 512 bits of ****
>>
>> >> information,****
>>
>> >>** **
>>
>> >>    when provided.  It has no SuppPrivInfo parameter.  Should it be****
>>
>> >>** **
>>
>> >>    appropriate for the application, key agreement can be performed in
>> ****
>>
>> >> a****
>>
>> >>** **
>>
>> >>    manner akin to RFC 2631 by using the PartyAInfo value as the "apu"*
>> ***
>>
>> >>** **
>>
>> >>    (Agreement PartyUInfo) header parameter value, when provided, and *
>> ***
>>
>> >> by****
>>
>> >>** **
>>
>> >>    using no "apv" (Agreement PartyVInfo) header parameter.****
>>
>> >>** **
>>
>> >> """****
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >> NEW:****
>>
>> >>** **
>>
>> >> """****
>>
>> >>** **
>>
>> >> Applications must specify what values should be populated in the "apu"
>> ****
>>
>> >> and "apv" parameters.  Applications wishing to conform to ****
>>
>> >> [NIST.800-56A] need to provide values that meet the requirements of **
>> **
>>
>> >> that document, e.g., by choosing values that identify the sender and *
>> ***
>>
>> >> recipient.  Otherwise, it is RECOMMENDED that applications conduct ***
>> *
>>
>> >> key derivation in a manner similar to****
>>
>> >> [RFC2631]: The "apu" field should be set to a random 512-bit value ***
>> *
>>
>> >> (analogous to PartyAInfo in [RFC2631]) and the "apv" field should be *
>> ***
>>
>> >> left empty.****
>>
>> >>** **
>>
>> >> """****
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >> On Sun, Aug 11, 2013 at 6:56 PM, jose issue tracker ** **
>>
>> >> <[email-masked]> wrote:****
>>
>> >>** **
>>
>> >> #55: Mandatory entropy in ECC KDF inputs****
>>
>> >>** **
>>
>> >>  At the interim, there was agreement to require at least 512 bits of *
>> ***
>>
>> >> entropy in the "apu" field, in order to ensure sufficient entropy in *
>> ***
>>
>> >> the  resulting key.  That requirement has been lost in a subsequent
>> revision.****
>>
>> >>** **
>>
>> >> --****
>>
>> >> -------------------------+-------------------------------------------*
>> ***
>>
>> >> -------------------------+-****
>>
>> >> -------------------------+-----****
>>
>> >>  Reporter:  [email-masked]   |      Owner:  draft-ietf-jose-json-web-****
>>
>> >>      Type:  defect       |  [email-masked]****
>>
>> >>  Priority:  major        |     Status:  new****
>>
>> >> Component:  json-web-    |  Milestone:****
>>
>> >>   algorithms             |    Version:****
>>
>> >>  Severity:  -            |   Keywords:****
>>
>> >> -------------------------+-------------------------------------------*
>> ***
>>
>> >> -------------------------+-****
>>
>> >> -------------------------+-----****
>>
>> >>** **
>>
>> >> Ticket URL: <http://trac.tools.ietf.org/wg/jose/trac/ticket/55>****
>>
>> >> jose <http://tools.ietf.org/jose/>****
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >>** **
>>
>> >> _______________________________________________****
>>
>> >> jose mailing list****
>>
>> >> [email-masked]****
>>
>> >> https://www.ietf.org/mailman/listinfo/jose****
>>
>> >>** **
>>
>> _______________________________________________****
>>
>> jose mailing list****
>>
>> [email-masked]****
>>
>> https://www.ietf.org/mailman/listinfo/jose****
>>
>
>

---

From: Brian Campbell <[email-masked]>
Date: Sat, 5 Oct 2013 07:41:10 -0700

WFM

On Fri, Oct 4, 2013 at 11:11 AM, Richard Barnes <[email-masked]> wrote:

> On Wed, Sep 11, 2013 at 2:55 PM, Brian Campbell <
> [email-masked]> wrote:
>
>> Much improved, thanks.
>>
>>>                                                                 -- Mike*
>>> I guess that's what the proposed JOSE text says too. But the MAY
>>> followed by the conditional SHOULD reads kind of funny. And as someone
>>> who's asked for some more clarity and guidance on the use of "apu" and
>>> "apv" that text didn't leave me felling sure of what to do with them but
>>> made me feel like I probably needed to put 512 bits of stuff in there.**
>>> **
>>>
>>> ** **
>>>
>>> > I also stated on the call that the 512 additional bits of entropy
>>> don't any value to the randomness already present in the ephemeral key.*
>>> ***
>>>
>>> >** **
>>>
>>> >> Thanks for the new text, Richard.  Slight consistency edits proposed
>>> ****
>>>
>>> >> below...****
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >> parameters.  Applications wishing to conform to [NIST.800-56A] need *
>>> ***
>>>
>>> >> to provide values that meet the requirements of that document, e.g.,
>>> ****
>>>
>>> >> Alternatively, applications MAY conduct key derivation in a manner **
>>> **
>>>
>>> >> similar to [RFC2631]: In that case, the "apu" field SHOULD represent
>>> ****
>>>
>>> >> As promised on the call yesterday, here's some proposed revision to *
>>> ***
>>>
>>> >> Section****
>>>
>>> >> 4.7.2:****
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >> OLD:****
>>>
>>> >>** **
>>>
>>> >> """****
>>>
>>> >>** **
>>>
>>> >>    Note: The Diffie-Hellman Key Agreement Method [RFC2631] uses a key
>>> ****
>>>
>>> >>** **
>>>
>>> >>    parameters.  Rather than having separate PartyUInfo and PartyVInfo
>>> ****
>>>
>>> >>** **
>>>
>>> >>    manner akin to RFC 2631 by using the PartyAInfo value as the "apu"
>>> ****
>>>
>>> >>** **
>>>
>>> >>    (Agreement PartyUInfo) header parameter value, when provided, and
>>> ****
>>>
>>> >> by****
>>>
>>> >>** **
>>>
>>> >> [NIST.800-56A] need to provide values that meet the requirements of *
>>> ***
>>>
>>> >> that document, e.g., by choosing values that identify the sender and
>>> ****
>>>
>>> >> recipient.  Otherwise, it is RECOMMENDED that applications conduct **
>>> **
>>>
>>> >> [RFC2631]: The "apu" field should be set to a random 512-bit value **
>>> **
>>>
>>> >> (analogous to PartyAInfo in [RFC2631]) and the "apv" field should be
>>> ****
>>>
>>> >> left empty.****
>>>
>>> >>** **
>>>
>>> >> """****
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >>** **
>>>
>>> >>  At the interim, there was agreement to require at least 512 bits of
>>> ****
>>>
>>> >> entropy in the "apu" field, in order to ensure sufficient entropy in
>>> ****
>>>
>>> >> -------------------------+-------------------------------------------
>>> ****
>>>
>>> >> -------------------------+-------------------------------------------
>>> ****
>>>