[TLS] tls - Update to a Meeting Session Request for IETF 114

[IETF Meeting Session Request Tool]

An update to a meeting session request has just been submitted by Sean Turner, 
a Chair of the tls working group.


-
Working Group Name: Transport Layer Security
Area Name: Security Area
Session Requester: Sean Turner


Number of Sessions: 1
Length of Session(s): 2 Hours
Number of Attendees: 120
Conflicts to Avoid: 

   


People who must be present:
  Eric Rescorla
  Sean Turner
  Joseph A. Salowey
  Paul Wouters
  Christopher A. Wood

Resources Requested:

Special Requests:
  
-


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Stephen Farrell]

Hiya,

On 27/04/2022 16:27, Christopher Wood 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/


As I guess I've said before, I think progressing this draft
now, even with this WGLC-then-park approach, is premature.

However, I seem to be in the rough on that so can live with
this ad-hoc process (teeth grinding mind you:-) so long as we
park this for a sufficient period *and* are open to changing
anything at the end of the parking-lot period.

Even so, I think this is not yet ready for any such ad-hoc
parking-lot:

- section 1.5 implies a wish to reduce the number of
octets sent - ECH creates a way to point from one part
of the (encrypted, inner) ClientHello to another (the
outer ClientHello). I don't think we want two such
mechanisms, or one mechanism defined in ECH but none at
all here, or even worse a second method. For me, that
implies not "freezing" the structural work here 'till
we see if ECH gets widespread deployment at which point
we should consider re-use of the ECH mechanism. (Or maybe
even consider both cases of re-using octets and invent
another thing, but not 'till we see if ECH gets traction.)

- section 2: if "classic" DH were broken, and we then
depend on a PQ-KEM, doesn't that re-introduce all the
problems seen with duplicating RSA private keys in
middleboxes? If not, why not? If so, I don't recall
that discussion in the WG (and we had many mega-threads
on RSA as abused by MITM folks so there has to be stuff
to be said;-)

- similar to the above: if PQ KEM public values are
like RSA public keys, how does the client know what
value to use in the initial, basic 1-RTT ClientHello?
(sorry if that's a dim question:-) If the answer is
to use something like a ticket (for a 2nd connection)
then that should be defined here I'd say, if it were
to use yet another SVCB field that also ought be
defined (or at least hinted at:-)

- I'm also HRR-confused - if we don't yet know the
details of the range of possible PQ KEM algs we want to
allow here, how do we know that we almost always continue
to avoid HRR in practice and thus benefit from a mixture of
classic and PQ algs? (It's also a bit odd that HRR,
much as I dislike it, doesn't get a mention here;-) I
think the problem is that we don't want HRR to push a
client back to only "classic" groups, if the client but
not the server is worried about PQ stuff while both
prioritise interop.

- section 4: if this cannot support all NIST finalists
due to length limits then we're again being premature
esp. if NIST are supposed to be picking winners soon.
We'd look pretty dim if we didn't support a NIST winner
for this without saying why.

- section 5: IMO all combined values here need to have
recommended == "N" in IANA registries for a while and
that needs to be in this draft before it even gets
parked. Regardless of whether or not the WG agree with
me on that, I think the current text is missing stuff
in this section and don't recall the WG discussing that

Nits etc below:

- TLS1.1 and earlier mixed hash functions when deriving
keys on the basis of then-suspected weaknesses in MD5, yet
there were arguments made that that ad-hoc mixing wasn't
useful, so we moved away from that in TLS1.2+. I don't
see an argument or pointer in this draft to a justification
that this (also seemingly ad-hoc?) catenation approach
won't suffer analagous infelicity. Absent that, ISTM trying
to finalise the structural parts of this now may be a
cryptographically bad plan. (Even if in practice that's ok.)

- 1.2: it's longer 2019 - one of the year or tense (of
"include") should change, probably the former given the
idea of parking this for some time

- section 2: the tendency to document APIs (e.g. "KeyGen()")
in protocol documents seems to me a bit of a double-edged
sword - it should help some implementers but OTOH might
mean we fail to consider how implementations with other
internals might perform, so I'd prefer we are more clear
as to how those APIs are optional, but that's really a
matter of style I guess

- section 2: HPKE is now RFC9180

Cheers,
S.


OpenPGP_0x5AB2FAF17B172BEA.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Douglas Stebila]

Thanks for the feedback Martin.  I see what you're getting at regarding 
phrasing it in terms of KeyGen[i], Encaps[i], etc.  This is a good point:

>> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the 
>> concatenation of the key_exchange field for each of the constituent 
>> algorithms. 
> 
> I think that this text is a mistake as it implies that the component key 
> exchange algorithm has a defined key_exchange format.  What you want is a 
> definition in the form above, or as HPKE has it.

Indeed it makes sense to be able to define a hybrid key exchange method 
independent of whether the all of the component algorithms are already defined 
standalone key exchange methods in TLS 1.3.  I do however want to tie back 
somehow to the idea that, *if* one of the algorithms is already defined as a 
key exchange method in TLS 1.3, then the value that should be put in the key 
share concatenation is just the key share that was used when it was a 
standalone method.  Is that okay?


> With something like this, I'd like to see the implication that the TLS key 
> schedule is changed by this draft can be removed (in Section 3.3 
> specifically).

I don't read Section 3.3 as implying that the TLS key schedule is changed.  It 
says how one of the inputs to the key schedule is computed, but otherwise I 
think it's just saying: put this concatenated value into the obvious place in 
the existing key schedule.  Can you point me to where you read it as implying 
more changes to the TLS key schedule?

Douglas




> On Apr 27, 2022, at 20:56, Martin Thomson  wrote:
> 
> I found the introduction of KeyGen, Encaps, and Decaps to be underutilized.  
> It would require a little work, but I think that it would be better to 
> describe a method whereby you produce each of these functions by taking an 
> ordered collection of these functions (KeyGen[i], Encaps[i], and Decaps[i]) 
> and constants (Npk[i], Nek[i], etc...).
> 
> With something like this, I'd like to see the implication that the TLS key 
> schedule is changed by this draft can be removed (in Section 3.3 
> specifically).
> 
> In essence, you are describing a known-good process for composing key 
> exchange methods.  (Not existing TLS 1.3 key exchange methods, as implied by 
> this:
> 
>> For a hybrid key exchange, the key_exchange field of a KeyShareEntry is the 
>> concatenation of the key_exchange field for each of the constituent 
>> algorithms. 
> 
> I think that this text is a mistake as it implies that the component key 
> exchange algorithm has a defined key_exchange format.  What you want is a 
> definition in the form above, or as HPKE has it.
> 
> I'd prefer to see this work done before publication, but as I'm not able to 
> volunteer to do it, I can't really insist on it.  This is useful work and the 
> document, despite these niggles, is pretty clear and well-reasoned.
> 
> On Thu, Apr 28, 2022, at 01:27, Christopher Wood 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
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

[Nimrod Aviram]

Ah, got it. You're saying the Reference column would allow us to introduce
other combination methods if needed, through separate defining documents.
That sounds good to me as an upgrade path. Thanks!


On Thu, 28 Apr 2022 at 22:29, David Benjamin  wrote:

> 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
> . 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 
> 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 
>> 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
>>> TLS@ietf.org
>>> https://www.ietf.org/mailman/listinfo/tls
>>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls