Subject: Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02

From: John Mattsson <[email-masked]>
Date: Wed, 18 Dec 2019 13:24:37 +0000

Hi Richard,

The PR looks good. Some responses below.

Cheers,
John

On Sat, Nov 27, 2019 Richard Barnes <[email-masked]> wrote:

 >> - I am missing a Security considerations. I think there are several things
>> that could be mentioned:
>>
>>   -- How does an application supporting several algorithms protect against
>> downgrade?
>>
>>   -- Should the receiver do replay protection?
>>
>>   -- Shortly mention that the construction in the draft protects against
>> attack on earlier ECIES standards such as the Benign malleability and the
>> XOR malleability.
>>
>
>Sorry, I'm not familiar with these notions.  Maybe you could propose some
>text?

Sure, I’ll make a pull request with a suggestion.

>>   -- Stating that the protocol does not provide PFS and give some
>> consideration on when that would be ok instead of setting up a TLS
>> connection.
>>
>>   -- privacy considerations
>>
>
>We discuss some privacy considerations in the "Metadata Protection"
>section. Did you have others in mind?

This was more security considerations than privacy. I’ll can try to make a pull request with a suggestion.

>> - “For the NIST curves P-256 and P-521, the Marshal function of the DH
>>    scheme produces the normal (non-compressed) representation of the
>>    public key, according to [SECG].”
>>
>>    Why suddenly referring to SECG?
>>
>
>I understood that was the normal reference for point formats.  Do you have
>another preference?

Maybe I just misread something the first time, the reference seems fine.

But why force everybody to use the non-compressed representation? In many wireless use cases (even 5G) you would not want to waste bytes to send the y-coordinate. In HPKE, my understanding is that not even the sign bit is needed as the x-coordinate of DH(skR, pkE) does not depend on the y-coordinate of pkE.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Dec 2019 13:39:56 +0000

Hiya,

On 18/12/2019 13:24, John Mattsson wrote:
> The PR looks good. 

Assuming you mean [1]...

Since I didn't get a substantive response on the list,
I'll repeat:

"Urgh. Why do we always need to define every possible
option even though there's no real demand? There are
already far too many combinations of modes and suites
in hpke."

Having more or less finished my implementation now, I
feel more strongly that additional combinatoric mess
is a bad plan. Removing options/simplifying would be
far better.

We (CFRG) could punt on this by using existing IETF
IANA registries instead of creating new ones. There is
an almost fine match between what we need and some
existing registries (if one squints just a little;-)
that'd remove all this wrangling from our plate and
that could result in the hpke RFC having only one MUST
implement kem, kdf and aead. Additional options could
then be haggled over in the IETF each time someone
claims a need before subsequently being ignored by
almost all implementers and an even higher proportion
of deployments;-)

Cheers,
S.

[1] https://github.com/cfrg/draft-irtf-cfrg-hpke/pull/23/

---

From: John Mattsson <[email-masked]>
Date: Wed, 18 Dec 2019 14:20:59 +0000

Hi,

Stephen Farrell wrote:

>"Urgh. Why do we always need to define every possible option even though there's no real demand?

While TLS 1.2 definitely have too many cipher suites, I think some recent specifications like RFC 8032 have hardcoded too much. Having an IANA registry with specification required  and some well-chosen initial values is a good approach.

>We (CFRG) could punt on this by using existing IETF IANA registries instead of creating new ones. 

I also like the idea to reuse IANA registries more. I made a similar comment regarding draft-ietf-emu-aka-pfs a month ago. There are for example many IANA registries for groups/curves. I really like the new TLS IANA registry with specification requires and a Recommended column that requires Standards Action.

>result in the hpke RFC having only one MUST implement kem, kdf and aead.

Does HPKE currently have any MUST implement kem, kdf and aead? And should it have? My picture of the future HPKE RFC is that is a framework where nothing is mandatory to implement and where the IETF protocol using HPKE defines a mode and algorithms that are mandatory-to-implement. A RECOMMENDED mode and set of algorithms would however be good, and maybe text stating that implementations are not expected to support them all.

Cheers,
John

-----Original Message-----
From: Cfrg <[email-masked]> on behalf of Stephen Farrell <[email-masked]>
Date: Wednesday, 18 December 2019 at 14:40
To: John Mattsson <john.mattsson=[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Cfrg] Review of draft-irtf-cfrg-hpke-02

    Hiya,

    Assuming you mean [1]...

    

    Cheers,
    S.
    
    [1] https://protect2.fireeye.com/v1/url?k=2314e233-7f86ef6f-2314a2a8-0cc47ad93d46-945b5a8e9e504e6c&q=1&e=9ab353d6-767e-4b85-b0e9-ae1735c5d076&u=https%3A%2F%2Fgithub.com%2Fcfrg%2Fdraft-irtf-cfrg-hpke%2Fpull%2F23%2F

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 18 Dec 2019 17:50:03 +0200

> is a bad plan. Removing options/simplifying would be

I do not see combinatoric mess. In fact, trying to "simplify" by
eliminating combinations could very well _increase_ complexity due
to some actual combinatorial mess. 

What can not be done is taking various axes, multiplying the
number of points and taking the resulting product as some kind of
metric of "complexity". In many cases, the sum is better metric than
the product.

Remember the SSL 3.0/TLS 1.0-1.2 ciphersuite mess? That was result
of trying to enumerate combinations. If you think it looks bad, it
is even worse to implement... Even restricted only to recommended
ones.

That said, I would drop NIST P-521 (as seems pretty much everybody
is using NIST P-384 instead).

Then SHA-512 is on-the-fence: SHA-384 is likely more than strong
enough, but SHA-384 is not strength-matched with Curve448 (assume
P-521 gets dropped), while SHA-512 is. And having SHA-256, SHA-384
and SHA-512 is very little additional complexity on top of SHA-256
and SHA-384.

If one wanted combined curve/hash pairs, I would have:

NIST P-256 with SHA-256
NIST P-384 with SHA-384
X25519 with SHA-256
X448 with SHA-512

However, this may be bad idea from complexity standpoint (it
does not reduce complexity very much if at all).

Combining groups with ciphers is definitely a bad idea from
complexity standpoint.

> almost all implementers and an even higher proportion

What registeries?

For groups there is the TLS groups, which actually has only four
recommended entries (P256/384 and X25519/448). Unfortunately it
has variety of less-than-cute stuff (not all of that banned in TLS
1.3) marked not recommended. Bonus points for having 3 entries that
are duplicates except one is banned in TLS 1.3 and one is not.

Then for ciphers, there is TLS ciphersuite registry for TLS 1.3
ciphers. That one combines hashes, sometimes in bit cryptographically
"interesting" ways. It also recommends AES-128-CCM, which is not great
(as it is associated with IoT stuff), plus has already got some less-
than-cute stuff (including NULL ciphers and 64-bit tags) marked not
recommended (with more less-than-cute stuff pending).

And both of these registeries are expert review, so they tend
to accumulate variety of stuff.

And future problem point is if someone lobs in some post-quantum key
exchange stuff. Which will work somewhere between poorly and not at
all. And post NISTPQC, that can very well have Recommended set.

-Ilari

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Dec 2019 15:54:54 +0000

Hiya,

On 18/12/2019 14:20, John Mattsson wrote:
> While TLS 1.2 definitely have too many cipher suites, I think some
> recent specifications like RFC 8032 have hardcoded too much. 

Disagree. RFC8032 lead to pointless debate in IETF WGs
about pure vs. hash. I think 8032 is another example of
providing too many options.

> Having
> an IANA registry with specification required  and some well-chosen
> initial values is a good approach.

Sure.

> I also like the idea to reuse IANA registries more. I made a similar
> comment regarding draft-ietf-emu-aka-pfs a month ago. There are for
> example many IANA registries for groups/curves. I really like the new
> TLS IANA registry with specification requires and a Recommended
> column that requires Standards Action.

I had a look and there are IANA registries that'd do just
what we need. (16 bit values, specification required, and
with existing experts in place).

Doing that however does mean that some folks will dislike
it, as the semantics for use of the same code-point in
different protocols could potentially differ.

E.g. for the current interesting KDFs we could use any registry of hash
functions as we only really care about
HKDF-<hash>. In principle, some new KDF might not be
HKDF-based, which is a teeny bit naff - HPKE would need
to say something like "For HKDF based KDFs, use values
from <this> IANA registry to specify KDF. If a non HKDF
KDF is needed in future, a new registry may be needed
that is guaranteed to not overlap with <this>." That
does require holding one's nose a bit but also does
work:-)

> Does HPKE currently have any MUST implement kem, kdf and aead? And
> should it have? My picture of the future HPKE RFC is that is a
> framework where nothing is mandatory to implement and where the IETF
> protocol using HPKE defines a mode and algorithms that are
> mandatory-to-implement. A RECOMMENDED mode and set of algorithms
> would however be good, and maybe text stating that implementations
> are not expected to support them all.

I'd be fine with exactly one RECOMMENDED set of things to
implement or a MUST-implement. What I'd most like to avoid
is IETF WGs each debating which things to pick from HPKE.
As to MUST vs. RECOMMENDED, HPKE is a spec that could be
implemented as a standalone library (which is kinda what
I've done;-) and adopted by people outside the IETF so
having a MUST-implement seems like a good plan for this
one.

S.

> 
> Cheers, John
> 
> -----Original Message----- From: Cfrg <[email-masked]> on
> behalf of Stephen Farrell <[email-masked]> Date:
> Wednesday, 18 December 2019 at 14:40 To: John Mattsson
> <john.mattsson=[email-masked]>, "[email-masked]"
> <[email-masked]> Cc: "[email-masked]" <[email-masked]> Subject: Re: [Cfrg]
> Review of draft-irtf-cfrg-hpke-02
> 
> 
> Hiya,
> 
> Since I didn't get a substantive response on the list, I'll repeat:
> 
> "Urgh. Why do we always need to define every possible option even
> though there's no real demand? There are already far too many
> combinations of modes and suites in hpke."
> 
> Having more or less finished my implementation now, I feel more
> strongly that additional combinatoric mess is a bad plan. Removing
> options/simplifying would be far better.
> 
> We (CFRG) could punt on this by using existing IETF IANA registries
> instead of creating new ones. There is an almost fine match between
> what we need and some existing registries (if one squints just a
> little;-) that'd remove all this wrangling from our plate and that
> could result in the hpke RFC having only one MUST implement kem, kdf
> and aead. Additional options could then be haggled over in the IETF
> each time someone claims a need before subsequently being ignored by 
> almost all implementers and an even higher proportion of
> deployments;-)
> 
> Cheers, S.
> 
> [1]
> https://protect2.fireeye.com/v1/url?k=2314e233-7f86ef6f-2314a2a8-0cc47ad93d46-945b5a8e9e504e6c&q=1&e=9ab353d6-767e-4b85-b0e9-ae1735c5d076&u=https%3A%2F%2Fgithub.com%2Fcfrg%2Fdraft-irtf-cfrg-hpke%2Fpull%2F23%2F
>
> 
> 
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 18 Dec 2019 16:11:03 +0000

Hiya,

> to some actual combinatorial mess.

I'm fine with the encoding of the suites/modes in the
HPKE context, so I'm not arguing for a single 16-bit
ciphersuite number.

But for implementation/test the cobminatorics still
kick in - with the current spec there are 96 combinations
of mode/kem/kdf/aead. The test vectors have one for
each (with one messed up I think and with confusion
as to compressed/uncompressed encoding for the NIST
curves in others).

96 options is approx 95 (or maybe 94) too many.

>> almost all implementers and an even higher proportion

Ok, from here on, you'll probably want to hold your
noses;-)

HPKE currently wants to create IANA registries for the
KEM, KDF and AEAD.

I think in two of those cases we could fairly easily reuse
TLS registries for HPKE - the TLS supported groups [1] is
a nice match for the KEM, and the TLS hash algorithms [2]
would be fine for the HKDF variant.

I'm not sure if it'd be a good or bad idea to use the TLS
ciphersuites registry [3] for the AEAD - while one can
easily map those I guess the ambiguity could cause interop
issues, so maybe that'd be a bad plan. But maybe the
AEAD parameters registry [4] would be fine.

Or there may also be other IANA registries that could
be re-used for HPKE.

Cheers,
S.

[1]
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
[2]
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-18
[3]
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4
[4] https://www.iana.org/assignments/aead-parameters/aead-parameters.xhtml