"To avoid downgrade attacks, the client MUST continue to send its full preferences in the supported_groups extension."
I don't think sending full preferences is a requirement in RFC 8446. As far as I can see there is no normative text in RFC 8446 forbidding the client to change the "supported_groups" extension based on unauthorized data such as the domain name, IP address, etc. I think RFC 8446 should be update to state: The client MUST NOT change the content of the "supported_groups" extension based on unauthenticated information. ------------ "DNS responses are unauthenticated in many deployments." I think the draft should describe the two cases "authenticated DNS" and "unauthenticated DNS" separately. The security considerations are very different. ------------ I think the security considerations are way too optimistic and need major work. "To avoid downgrade attacks, the client MUST continue to send its full preferences in the supported_groups extension." "it is safe for clients to admit attacker control over the set of named groups preferred in key_share, provided supported_groups always reflects the true client preference." This relies on servers ignoring performance and always chosing security. My understanding is that there is nothing in RFC 8446 saying that servers should behave like this. I think the only reasonable assumption in case of unauthenticated DNS is that the weakest group supported by the client will be used. This is problematic. If a server is not doing point validation on P-256 (which we know happens), an attacker can find the private key. As TLS key shares unfortunatly are not ephemeral (TLS 1.3 allows reuse), an attacker can downgrade a real connection from x25519 to P-256 (which is unfortunatly MTI) and then completely compromise the connection with the key share private key it got from earlier connections with the server. Cheers, John From: David Benjamin <david...@chromium.org> Date: Tuesday, 10 September 2024 at 23:41 To: <tls@ietf.org> Subject: [TLS] draft-ietf-tls-key-share-prediction next steps Hi all, Now that we're working through the Kyber to ML-KEM transition, TLS 1.3's awkwardness around key share prediction is becoming starkly visible. (It is difficult for clients to efficiently offer both Kyber and ML-KEM, but a hard transition loses PQ coverage for some clients. Kyber was a draft standard, just deployed by early adopters, so while not ideal, I think the hard transition is not the end of the world. ML-KEM is expected to be durable, so a coverage-interrupting transition to FancyNewKEM would be a problem.) We adopted draft-ietf-tls-key-share-prediction in June to address this. There hasn't been a whole lot to do on it since. I've cut a new draft, draft-ietf-tls-key-share-prediction-01, with some very minor changes that were queued up in GitHub. I'd like to sort out next steps and move forward. Beyond that, there are a couple of minor issues in the issue tracker. I don't believe either of these need to block getting a codepoint. https://github.com/tlswg/tls-key-share-prediction/issues/4 - unless folks think otherwise, I plan to just leave this alone and close this https://github.com/tlswg/tls-key-share-prediction/issues/7 - unless folks think otherwise, I plan to just leave this alone and not require the receiver to check Finally, there's the question of downgrade protection: https://github.com/tlswg/tls-key-share-prediction/issues/11 For some background if folks have forgotten, the original key share prediction draft included a ton of complexity to accommodate existing server behavior that would preferentially pick groups out of key_share even if an otherwise more preferred group was in supported_groups. Depending on what the server was trying to do there, this could be perfectly fine (if the server believes the groups are comparable in security) or a downgrade risk (if the server actually believed they were in different security classes---PQ vs classical---but implemented a key_share-first selection algorithm anyway). Pre-adoption, my original draft took the position that it was ambiguous and we cannot safely assume the server knew what it was doing. It designed a scheme to clarify the semantics going forward and use codepoints to ratchet in whether the server implemented the new semantics. https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html After WG discussion, I think we broadly concluded the semantics were actually already present in RFC 8446, and it was not worth the trouble to second-guess the servers here. That led to the much simpler draft, which simply discusses why this is OK in security considerations: https://www.ietf.org/archive/id/draft-ietf-tls-key-share-prediction-01.html#name-security-considerations As I wrote that text, I unsurprisingly agree with and am fine with this outcome. :-) But there was some chatter about it in the adoption thread (see GitHub link), so I filed the issue so we continued to discuss it. I think perhaps now is the time to discuss it, if we're going to. Do folks want to discuss it? Are there alternate proposals, or should we just stay the course? Unless we have an alternate proposal, I propose we just stay the course and go with [what I understand the conclusion to be from] the previous WG discussion. If there are no further significant changes that folks want to make, I would like to propose we get a codepoint for this and unblock implementation. The earlier this is ready, the more likely that we will be prepared by the time the next KEM transition happens. Thoughts? David
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
