On Wed, Sep 11, 2024 at 12:41 AM John Mattsson <john.mattsson= 40ericsson....@dmarc.ietf.org> wrote:
> "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. > Hmmm... Isn't the correct statement here that if the server; 1. Reuses keys 2. Does not do point validation Then the attacker can compromise one key share and attack future connections that use the affected key? If the server does not reuse keys, then this attack doesn't work regardless of TLS not prohibiting reuse Ekr > > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
