On Wednesday, 5 June 2024 15:38:57 CEST, Eric Rescorla wrote:


On Wed, Jun 5, 2024 at 6:35 AM Eric Rescorla <e...@rtfm.com> wrote:


On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote:
Nick Harper <i...@nharper.org> writes:

I see no requirement in section 9 nor in section 4.2.8 requiring MTI curves
be present in the key_share extension if that extension is non-empty.

Just because it's possible to rules-lawyer your way around something doesn't
make it valid (I also see nothing in the spec saying a TLS 1.3 implementation
can't reformat your hard drive, for example, so presumably that's OK too).
The point is that P256 is a MTI algorithm and Chrome doesn't provide any MTI
keyex in its client hello, making it a noncompliant TLS 1.3 implementation.

I don't believe this analysis is correct. You state:

As Nick notes, RFC 8446 explicitly permits the extension to be empty, so
it clearly cannot be the case that mere failure to provide an MTI key_share
in CH makes an implementation noncompliant, contra your statement above.

The only question at hand is whether the specification permits you to send
a non-empty key_shares field that excludes the MTI. However, the specification
*also* permits you to send a subset of supported groups:

   the same order.  However, the values MAY be a non-contiguous subset
   of the "supported_groups" extension and MAY omit the most preferred
   groups.  Such a situation could arise if the most preferred groups

I think the best reading of this text is that you are free to send *any*
subset of the supported groups, whether it includes the MTI or not.

The requirement in S 9.1 is merely that the application "support
key exchange with secp256r1", which Chrome does: it's in "supported_groups"
and (presumably) works if the server sends an HRR. Given the above
more explicit text about "key_shares", I don't think it's reasonable to
infer that MTI requires more than this.

This isn't to say anything about whether this is the best implementation choice,
which is a distinct question from what the specification requires.

One more thing: we are finalizing RFC 8446-bis right now, so if there is
WG consensus to require that clients offer all MTI curves in the key_shares
of their initial CH, then that would be a straightforward text change.

I definitely don't agree with such a requirement.

--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic

_______________________________________________
TLS mailing list -- tls@ietf.org
To unsubscribe send an email to tls-le...@ietf.org

Reply via email to