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

[Stephen Farrell <[e-mail]>]

Hiya,

On 18/12/2019 14:20, John Mattsson wrote:
> 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. 

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.

>> 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.

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:-)

> 
>> 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.

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 <[e-mail]> on
> behalf of Stephen Farrell <[e-mail]> Date:
> Wednesday, 18 December 2019 at 14:40 To: John Mattsson
> <john.mattsson=[e-mail]>, "[e-mail]"
> <[e-mail]> Cc: "[e-mail]" <[e-mail]> Subject: Re: [Cfrg]
> Review of draft-irtf-cfrg-hpke-02
> 
> 
> 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://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
>
> 
> 
>