As discussed on the call, the 512 bit entropy is redundant with the entropy
already provided by the ephemeral key, and so is unnecessary. The RFC 2631
text making it optional confirms this. (It's only there for the Static-Static
case, which this isn't.) Given that it's unnecessary and extra size, I can't
support a "SHOULD" for it. The last sentence in your proposed text is
redundant, since this in in the context of the Ephemeral-Static case.
The whole thing about RFC 2631 is an aside, not really a recommendation in the
first place.
Therefore, I believe we should stay with the text I proposed on Thursday.
-- Mike
From: Richard Barnes [mailto:[email protected]]
Sent: Monday, September 09, 2013 10:13 AM
To: Mike Jones
Cc: Brian Campbell; [email protected]
Subject: Re: [jose] #55: Mandatory entropy in ECC KDF inputs
This is good, I think we're converging. As that text is written, it seems a
little confusing as to whether an app should use blank or 512bits. I would
propose that we set a nonce as default, and say you MAY omit "apu" if you're
doing the right thing. There's no harm in the nonce (besides size), so it's a
safe default for a developer that may not understand "ephemeral-static".
Proposed text, with my changes in [[brackets]]:
"""
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. [[ 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. Applications MAY omit the
"apu" and "apv" fields only if operating in Ephemeral-Static mode, with a
separate ephemeral key generated for each recipient. ]]
"""
On Thu, Sep 5, 2013 at 8:31 PM, Mike Jones
<[email protected]<mailto:[email protected]>> 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 mode in [RFC2631]) and the "apv" field should not be
present.
-- Mike
-----Original Message-----
From: [email protected]<mailto:[email protected]>
[mailto:[email protected]<mailto:[email protected]>] On Behalf Of Brian
Campbell
Sent: Thursday, September 05, 2013 5:21 PM
To: Mike Jones
Cc: Richard Barnes; jose issue tracker;
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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 protected]<mailto:[email protected]>> 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 protected]]
> Sent: Thursday, September 05, 2013 2:20 PM
> To: Mike Jones
> Cc: Richard Barnes; jose issue tracker; [email protected]<mailto:[email protected]>;
> <[email protected]<mailto:[email protected]>>
> 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 protected]<mailto:[email protected]>> 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 protected]]
>> Sent: Thursday, September 05, 2013 8:23 AM
>> To: jose issue tracker
>> Cc:
>> <[email protected]<mailto:[email protected]>>;
>> [email protected]<mailto:[email protected]>
>> 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 protected]<mailto:[email protected]>> 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 protected]<mailto:[email protected]> | Owner:
>> draft-ietf-jose-json-web-
>> Type: defect |
>> [email protected]<mailto:[email protected]>
>> 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 protected]<mailto:[email protected]>
>> https://www.ietf.org/mailman/listinfo/jose
>>
_______________________________________________
jose mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/jose
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
