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

[Ilari Liusvaara <[e-mail]>]

On Sat, Apr 30, 2022 at 04:48:59PM +0100, Stephen Farrell wrote:
> 
> On 30/04/2022 10:05, Ilari Liusvaara wrote:
> > On Sat, Apr 30, 2022 at 01:24:58AM +0100, Stephen Farrell wrote:
> > > 
> > > 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/
> > > 
> > 
> > However, I did come up with compression method:
> > 
> > 1) Sub-shares in CH may be be just replaced by a group id (two octets).
> >     The replacements can be deduced from length of the whole share.
> > 2) First sub-share copies from first octets of share for the designated
> >     group.
> > 3) Second sub-share copies from last octets of share for the designated
> >     group.
> > 
> > This can be decoded regardless of if the sever knows what the referenced
> > groups are. The compression can also never run into loop, as recursive
> > references are not allowed.
> > 
> > 
> > So for example, if one wants to send x25519, p256, x25519+saber and
> > p256+saber, one can do that as:
> > 
> > - x25519: <x25519 share> (32+4 octets)
> > - p256: <p256 share> (65+4 octets)
> > - x25519+saber: <x25519 id><saber share> (2+992+4 octets)
> > - p256+saber: <p256 id><x25519+saber id> (2+2+4 octets)
> > 
> > Total overhead is 22 octets. 16 for 4 groups, and 6 for the compression
> > itself.
> 
> So yes that could work. We'd need to think through how
> it'd interact with the ECH scheme were both to end up
> standardised.

The ECH scheme copies entiere extensions whereas this works inside
the key_share extension, so I do not see any nontrivial interactions.
Furthermore the extension involved (key_share) REALLY SHOULD NOT
differ between inner and outer hello.


(The same analysis that says that key_share should not differ between
inner and outer hellos also trips my hinky detection on interaction
between ECH and PSK. And those interactions look much too complicated
for me to analyze.)


> > > - 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.
> > 
> > Well, avoiding HRR impiles that client is willing to bloat its client
> > hello even for servers that do not support PQ. And for such clients,
> > using PQ at all requires servers to priorize it (send HRR even if
> > acceptable share is present).
> 
> I don't understand the above sorry;-)
> 
> ISTM one would need to analyse/guess what'll happen with
> this scheme and HRR before being done. Maybe someone's
> done that but if so, I'm surprised there's no mention in
> the draft.

Well, three scenarios:


1) PQ without HRR:

Client hello (large): Hybrid key share, classical key share.
Server hello: Hybrid key share.


2) PQ with HRR:

Client hello (small): Hybrid supported, classical key share.
Server hello: Restart handshake, hybrid.
Client hello (large): Hybrid key share, classical supported.
Server hello: Hybrid key share.

(The "Hybrid supported, classical key share." turning into "Hybrid
key share, classical supported." is due to standard TLS rules on
HRR.)


3) Failure to use PQ even if supported by both sides:

Client hello (small): Hybrid supported, classical key share.
Server hello: Classical key share.

 
> > 
> > > - 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.
> > 
> > Just yeet McEliece. Its keys are just too large for it to be practical
> > in TLS, even if the keys did not bust hard limits.
> > 
> > After removing McEliece from consideration, all the finalists and
> > alternates can trivially be supported (albeit FrodoKEM busts some
> > soft limits).
> 
> Nonetheless, this is another respect in which the draft
> text has to remain incomplete because we're IMO progressing
> it too soon.

I disagree. None of this stuff will change. The reason why current
approach can not accomodiate McEliece is that McEliece public keys are
just plain too big. And that McEliece is the only finalist/alternate
where that is the case has been known since 3rd round annoucement on
July 22, 2020.


Furthemore, any approach that can accomodiate McEliece is highly risky
due to fundamential modifications to TLS required. The problematic part
is actually inside TLS 1.x invariants.



I personally consider McEliece harmful. Due to:
1) Causing reputational problems for whole PQC.
2) Encouraging unsafe designs to try to acomodiate its huge keysizes.




-Ilari