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

WFM

On Fri, Oct 4, 2013 at 11:11 AM, Richard Barnes <rlb@ipv.sx> wrote:

> 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 <
> bcampbell@pingidentity.com> 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 <Michael.Jones@microsoft.com>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: jose-bounces@ietf.org [mailto:jose-bounces@ietf.org] On Behalf Of
>>> Brian Campbell
>>> Sent: Thursday, September 05, 2013 5:21 PM
>>> To: Mike Jones
>>> Cc: Richard Barnes; jose issue tracker; <
>>> draft-ietf-jose-json-web-algorithms@tools.ietf.org>; jose@ietf.org
>>> 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 <Michael.Jones@microsoft.com>
>>> 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:bcampbell@pingidentity.com<bcampbell@pingidentity.com>
>>> ]****
>>>
>>> > Sent: Thursday, September 05, 2013 2:20 PM****
>>>
>>> > To: Mike Jones****
>>>
>>> > Cc: Richard Barnes; jose issue tracker; jose@ietf.org; ** **
>>>
>>> > <draft-ietf-jose-json-web-algorithms@tools.ietf.org>****
>>>
>>> > 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 <
>>> Michael.Jones@microsoft.com> 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:rlb@ipv.sx <rlb@ipv.sx>]****
>>>
>>> >> Sent: Thursday, September 05, 2013 8:23 AM****
>>>
>>> >> To: jose issue tracker****
>>>
>>> >> Cc: <draft-ietf-jose-json-web-algorithms@tools.ietf.org>;****
>>>
>>> >> jose@ietf.org****
>>>
>>> >> 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 ** **
>>>
>>> >> <trac+jose@trac.tools.ietf.org> 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:  rlb@ipv.sx   |      Owner:  draft-ietf-jose-json-web-****
>>>
>>> >>      Type:  defect       |  algorithms@tools.ietf.org****
>>>
>>> >>  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****
>>>
>>> >> jose@ietf.org****
>>>
>>> >> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>> >>** **
>>>
>>> _______________________________________________****
>>>
>>> jose mailing list****
>>>
>>> jose@ietf.org****
>>>
>>> https://www.ietf.org/mailman/listinfo/jose****
>>>
>>
>>
>