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

[John Mattsson <[e-mail]>]

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