My interpretation is the same as EKR. Chrome’s behavior seems compliant to me. I also think Chrome’s behavior makes sense and I think Chrome should continue doing that. The server’s Peter talk about do on the other hand not follow the implementation guidance in Appendix C.
C.3<https://datatracker.ietf.org/doc/html/rfc8446#appendix-C.3>. Implementation Pitfalls Implementation experience has shown that certain parts of earlier TLS specifications are not easy to understand and have been a source of interoperability and security problems. Many of these areas have been clarified in this document, but this appendix contains a short list of the most important things that require special attention from implementors. ... - As a server, do you send a HelloRetryRequest to clients which support a compatible (EC)DHE group but do not predict it in the "key_share" extension? As a client, do you correctly handle a HelloRetryRequest from the server? From: Eric Rescorla <e...@rtfm.com> Date: Wednesday, 5 June 2024 at 15:44 To: Peter Gutmann <pgut...@cs.auckland.ac.nz> Cc: tls@ietf.org <tls@ietf.org> Subject: [TLS]Re: Curve-popularity data? On Wed, Jun 5, 2024 at 6:19 AM Peter Gutmann <pgut...@cs.auckland.ac.nz<mailto:pgut...@cs.auckland.ac.nz>> wrote: Nick Harper <i...@nharper.org<mailto: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. -Ekr
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
