[TLS] Re: draft-ietf-tls-key-share-prediction next steps

[David Benjamin <[e-mail]>]

Thanks for the comments! Responses inline.

On Wed, Sep 11, 2024 at 3:39 AM John Mattsson <[e-mail]>
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.
>

There is also no normative text in RFC 8446 forbidding the client from
changing the cipher suites or any other parameter based on such data.
Rather, RFC 8446 simply gives the semantics of the fields, and implementers
can then fill in those fields based on those documented semantics:

>    When sent by the client, the "supported_groups" extension indicates
>   the named groups which the client supports for key exchange, ordered
>   from most preferred to least preferred.

That text is exactly the requirement you mention. The "supported_groups"
extension does not indicate the named groups which the client thinks is
most likely or anything like that. It indicates the ones the client
supports.


> 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.
>

It doesn't make a whole lot of sense to specifically call out
supported_groups when this is how every parameter works. Rather, I think
what would be more appropriate is a discussion about how TLS's downgrade
protection is relative to the ClientHello and that attacks with influence
on the ClientHello can influence the selection accordingly. This includes
key_share. Rather, the reason it's OK for key_share is that key_shares
semantics make this tolerable, as Security Considerations discusses.


> "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.
>

The original version of the draft separated them. This was removed based on
WG feedback. I think that feedback was correct.

DNS authentication is not the same as TLS authentication. Then you need to
reason about the kind of DNS-level authentication and how it compares to
the (usually X.509-based) authentication that you've configured in TLS, and
whether one is substitutable for the other. All that is unnecessary here.
In the simpler model, we've simply defined away the problem, which means
that we're not expending any particular effort to accommodate
unauthenticated DNS. If it works for unauthenticated DNS, it will also work
for authenticated DNS, and we do not need this more complex analysis.


> 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.
>

This relies on servers correctly implementing its desired policy, based on
the documented semantics of the ClientHello, as specified in RFC 8446.

If the server believes that all supported named groups are of comparable
security class (quite defensible if it only implements ECDH key shares!),
the server could reasonably prioritize HRR avoidance. If the server
believes some named groups (e.g. PQ) are in a different category from
others (e.g. ECDH), RFC 8446's text implies the server must consider those
categories before HRR avoidance.

You are right that this exercises an assumption on the server that wasn't
previously as well-exercised. Like I said in the email, the earliest
versions of the draft tried to avoid exercising this and took a much more
conservative position, at the expense of considerable complexity in the
draft. Is that the version you would prefer?

I'm OK with either option, but WG discussion prior to adoption seemed to
clearly prefer this version. I also prefer this version, but not very
strongly, so if the WG has changed its mind wants to go back to the other
one, or if there is another proposal to solve this, that's fine by me! I
started this thread purely because the draft has sat for a while now
without another proposal coming up, so it's about time we progress the
topic.


> 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.
>

I don't think this is a compelling thing for the client to accommodate. If
the server believes X25519 and P-256 are equivalent in security (and
implements a policy as such), but then also fails to do point validation in
P-256, its policy is demonstrably incompatible with its behavior and it is
the server's responsibility to fix this.

It sounds like you know of a TLS server implementation which does not do
P-256 point validation. Do you have a pointer to it? Have you reported a
vulnerability? This class of problem has been known for some time, and
Section 4.2.8.2 even explicitly calls it out.



> Cheers,
>
> John
>
>
>
> *From: *David Benjamin <[e-mail]>
> *Date: *Tuesday, 10 September 2024 at 23:41
> *To: *<[e-mail]>
> *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
>