Re: [Cfrg] Second RGLC on draft-irtf-cfrg-hpke

[Richard Barnes <[e-mail]>]

Hi Chris,

Couple responses inline.

On Mon, Aug 31, 2020 at 1:27 PM Christopher Patton <cpatton=
[e-mail]> wrote:

>
> In various places, e.g., 'KeySchedule()' in Section 5.1, value "" is used
> as the
> salt for KDF extraction. I'm wondering if implementations might
> misinterpret
> this. I read "" as 'the empty string', but the correct interpretation
> might be
> 'nil', i.e., 'None' in Python or 'NULL' in C. The HKDF spec defines the
> salt as
> follows: 'optional salt value (a non-secret random value); if not
> provided, it
> is set to a string of HashLen zeros.' I think the intention is to
> interpret ""
> as 'nil', i.e., no salt, but the empty string is certainly a valid salt for
> HKDF, since the extraction function is well-defined on this input. A
> 0-length
> salt might not be safe choice in terms of security, however.
>

I've been writing C++ lately, so I'll contribute the following:

auto salt = std::optional<std::vector<uint8_t>>(std::nullopt); // or...
auto salt = std::vector<uint8_t>{};

If you look at the HKDF and HMAC specs, and it turns out that it doesn't
matter.  HKDF replaces a nullopt salt with exactly the same thing that HMAC
expands a zero-length key to, namely "0" * block_size (in Python
notation).  In fact, any all-zero salt of a length up to the block size
would have the same result.

I would actually prefer to keep this as "zero-length octet string" and
*not* "not provided".  In the short run, it doesn't matter, as noted
above.  In the longer run, for some hypothetical future KDF, it means that
the new KDF doesn't need to have std::optional<T> semantics, it just needs
to operate byte strings.

So I think the spec is correct as it is.  If there are places where it is
implied that a salt is not provided, we should clarify that one is, and
that it is the zero-length octet string.



>
> Section 5.2
>
> I think the HPKE uses the term "nonce" incorrectly, since it's not a
> "Number
> that's used ONCE". In fact, it's used every time the "Seal()" or "Open()"
> operation is run. What's called a "nonce" here is usually called the
> "initialization vector" elsewhere: in TLS 1.3 for example, the "nonce" is
> the
> initialization vector XORed with a sequence number.
>

Agreed.  I assume something like "base_nonce" would work?

--Richard





>
> On Mon, Aug 31, 2020 at 9:14 AM Joseph Salowey <[e-mail]> wrote:
>
>>
>>
>> On Sun, Aug 16, 2020 at 1:51 AM Stanislav V. Smyshlyaev <
>> [e-mail]> wrote:
>>
>>> Dear CFRG participants,
>>>
>>> This message starts a second 2-week RGLC on "Hybrid Public Key
>>> Encryption" (draft-irtf-cfrg-hpke-05), that will end on August 31st.
>>> See https://datatracker.ietf.org/doc/draft-irtf-cfrg-hpke/ for the
>>> latest version of the draft.
>>>
>>> We are having the second RGLC because we didn't have much feedback
>>> during the first RGLC and because we have obtained two new Crypto Panel
>>> reviews:
>>>
>>> https://mailarchive.ietf.org/arch/msg/crypto-panel/Ol1Mm8JUpmgapgq8ppnBQQSlEkE/
>>> https://mailarchive.ietf.org/arch/msg/cfrg/7zhOHPFkCyZC00xLZnsEBT3o6ZU/
>>>
>>> Please send your comments, as well as expression of support to publish
>>> as an RFC (or possible reasons for not doing so) in reply to this message
>>> or directly to CFRG chairs.
>>>
>>>
>> [Joe] I have reviewed this draft and I believe it is ready for
>> publication.
>>
>>
>>
>>> Regards,
>>> Stanislav, Nick and Alexey
>>> _______________________________________________
>>> Cfrg mailing list
>>> [e-mail]
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail]
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
> _______________________________________________
> Cfrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg
>