Re: [TLS] WGLC for draft-ietf-tls-hybrid-design

[David Benjamin <[e-mail]>]

I don't think the upgrade path needs any mention or changes. It's no
different from what we always do: allocate a new code point.

Now that we've removed all the in-protocol combinator schemes from the
early versions, what remains is simply *a* method for defining a NameGroup
out of a pile of KEMs. It makes no commitment but the tautological one:
NamedGroups defined using this method will use this method.

The method doesn't preclude us from defining NameGroups via other
methods---after all, the existing NameGroups are defined differently
<https://datatracker.ietf.org/doc/html/rfc8446#section-7.4>. Should someone
wish to define a hybrid NamedGroup with a different combination method
(e.g. perhaps to hybrid with a KEMs that does not meet the requirements in
this document), they can simply not cite this document.

Likewise, I don't think it's useful to extend the registry here. Any
NamedGroup, this method or otherwise, already needs a standard name (the
Description column) and a defining document (the Reference column). Those
two are sufficient to distinguish value=1234; desc=x25519_somepqscheme;
ref=[[some doc that uses this thing]] from value=5678;
desc=x25519_somepqscheme_v2; ref=[[some doc that uses a newer thing]].

David

On Thu, Apr 28, 2022 at 7:19 AM Nimrod Aviram <[e-mail]>
wrote:

> I'd like to reiterate my suggestion: While for now there is concensus for
> using concatenation to combine the two shared secrets, we should have a
> clear upgrade path if we want to use other combination methods in the
> future.
>
> As Douglas notes here [1], the document does commit to concatenation as
> the combination method. One possible upgrade path is for the relevant code
> points in the NamedGroup registry to indicate not only the key exchange
> algorithms, but also the combination method. I'm not sure whether this is
> sufficient for an upgrade path, but it seems necessary.
>
> As for the document itself, I support moving it forward. As Douglas noted,
> if we would eventually introduce a new key combination method, that can
> happen in a new document.
>
> [1] https://mailarchive.ietf.org/arch/msg/tls/SGyUKtTWoW9h9rX6Mo64fwfmxMY/
>
>
>
> On Wed, 27 Apr 2022 at 18:28, Christopher Wood <[e-mail]>
> wrote:
>
>> This email commences a two week WGLC for draft-ietf-tls-hybrid-design,
>> located here:
>>
>>    https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
>>
>> We do not intend to allocate any code points at this time and will park
>> the document after the call is complete. Once CFRG produces suitable
>> algorithms for consideration, we will then add them to the NamedGroup
>> registry through the normal process [1] and move the document forward.
>>
>> Please review the draft and send your comments to the list. This WGLC
>> will conclude on May 13.
>>
>> Best,
>> Chris, for the chairs
>>
>> [1]
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>