Answering a few questions that have come up thus far:
> Downgrade by attacker is only possible if the client attempts insecure
fallback (e.g., offer PQ key share, connection failed, retry without PQ key
share)?
> Or am I missing some other possible downgrade attack?
A fallback is certainly one possible downgrade trigger, but there are
others in the section 3.1 subsections. First, suppose we decide to do a DNS
hint, as the document suggests. DNS is broadly unauthenticated, so an
attacker could easily claim the server prefers a weaker algorithm than it
actually does. (As for why we might want a DNS hint, PQ's large key sizes
means clients will be far less willing to just predict multiple PQ KEMs
just in case. But, as much as we need to cut down on unnecessary options in
the PQ space, I don't think we can bank on never wanting to transition
between PQ KEMs ever. If AwesomeNewKEM comes along that's half the size,
that's definitely worth a transition.)
You could also have a non-attacker-triggered downgrade. Suppose we're
picking between PQ1, PQ2, and X25519. If I predict {PQ1, X25519} on grounds
that PQ1 is more likely than PQ2, and X25519 is free, a server that
supports {PQ2, X25519} and implements a key-share-first selection algorithm
will pick the wrong one.
(Also, to clarify, I very much do not want to implement a fallback for
Chrome and we don't currently plan to. So far we're running doing our
initial Kyber rollout without one. We've run into some compatibility
issues, but have been able to clear them so far. But Bas has described
Cloudflare needing some workaround here. I think, independent of this
fallback possibility, there are enough other forward-looking needs to
justify doing something here. But securing this option is a nice bonus. If
you believe the initial list is largely a prediction, it's intuitive that
this would be safe to do, yet it currently isn't.)
> Servers accepting other than the server’s top-priority group in order to
avoid HRR aren’t necessarily doing this because they honor client
preferences or assume that key_share reflects client preferences.
> They may simply find several groups acceptable and consider RTT reduction
more important than the strength difference between certain groups. I’m not
convinced that this is necessarily wrong, generally.
Yeah, if the server considers all groups equally acceptable, then yeah
that's perfectly okay. And indeed if the server is key-share-first but
believes all currently-implemented groups are equally preferable, that's
fine. I tried to capture that with this paragraph here, but it's certainly
possible I've phrased it badly! (In discussing this space with others at
Google, I found it surprisingly difficult to characterize the issue in a
way that people could understand.)
https://davidben.github.io/tls-key-share-prediction/draft-davidben-tls-key-share-prediction.html#section-3.2-2
The thing that's I think *not* okay is if it implements a key-share-first
selection algorithm *without* affirmatively preferring the RTT reduction
over the strength difference. E.g. OpenSSL has gotten very excited about
pluggable cryptography (so it cannot possibly know all possible named
groups are equally acceptable), explicitly documents that the relevant
configuration on the server is a preference list, and still implements a
key-share-first selection algorithm. That is clearly unreasonable, yet RFC
8446 does not make that clear. This draft is ultimately trying to clarify
that, and draw bounds on future hinting schemes (e.g. DNS) to account for
the past lack of clarify.
> Server-side protection against [clients adjusting HRR predictions on
fallback] is not effective. Especially when we have both servers that
cannot handle large ClientHello messages and servers that have buggy HRR.
I think the discussion about buggy HRR is a red herring. Cloudflare could
easily have avoided that by simply sending key_share={Kyber, X25519}, not
key_share={Kyber}. This issue has nothing to do with that. It's about
key_share={X25519}; supported_groups={Kyber, X25519}. If the client sends
that, the server picks X25519, and all parties agree Kyber is in a
different strength class from X25519, whether the server was wrong for not
honoring its preference, or whether the client was wrong for predicting an
option that wasn't its most preferred.
If we believe that key_share is a prediction, not a preference, then we
should believe that the server is in the wrong here. We should then also
believe that this fallback is actually secure, whether it's desirable or
not. (Like I said, I don't think it's desirable, and I hope we can stick to
that. I'm more concerned with the other desirable scenarios where this
matters.)
> If this is the concern, would it be better to just say that TLS clients
SHOULD NOT/MUST NOT implement insecure fallbacks to weaker TLS parameters?
See above. This isn't *the* concern, or even the primary one. It's, IMO,
just an added bonus. I'm much more concerned about the next transition, at
which point we will regret not getting this right. But the compatibility
issue is the most visible in the near term, so I think folks are fixating
on it.
However, it's also not even clear from RFC 8446 whether such a fallback *is* to
weaker TLS parameters. In all these scenarios, the supported_groups
extension remains fixed, and RFC 8446 says:
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.
At no point is the client's preference, as defined by RFC 8446, different.
What's different is the key_share subset, but I see nothing in RFC 8446
that says how the client picks which key_shares to predict, or that conveys
any kind of semantics to that subset. This draft is about clarifying that.
Does that help clarify things? It is a very confusing topic. We made rather
a mess of named group negotiation. :-(
On Mon, Oct 16, 2023 at 9:00 PM Rob Sayre <say...@gmail.com> wrote:
> On Mon, Oct 16, 2023 at 5:52 PM Andrei Popov <andrei.po...@microsoft.com>
> wrote:
>
>>
>> - But how are you going to detect whether there's a crappy TCP/IP
>> stack or an attack? You can't.
>>
>> Understood. This is a general problem with insecure client-side fallbacks.
>>
>
> Sure, but I think the aim is to say that the server does support Kyber (or
> something else as large), because there will be a period where the reason
> for a failure will be unclear. So, do you see how the DNS signal works
> around that? I think the idea is that if the DNS record says the server
> supports Kyber (or whatever), the client might not want to allow X25519.
>
> There's just going to be a lot of broken stuff for a while, even if the
> actual server does support a PQ algorithm.
>
> thanks,
> Rob
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
