Hi David,
Thanks for posting this and for the discussion on the list.
Before commenting on this proposal, I'd like to make sure we're all
on the same page about the situation.
# Background
1. RFC 8446 states that both supported_groups and key_shares
are in client's preference order but doesn't say what it
means for a value to be omitted from key_shares.
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.
...
client_shares: A list of offered KeyShareEntry values in descending
order of client preference.
2. Some clients only send a subset of their supported groups in key
shares, either to save space/computation or because they are
concerned about compatibility.
3. Some servers negotiate by picking the most preferred key_share
that is present rather than the most preferred common group in
supported groups.
When we combine (2) and (3), the result is that the server may
choose a group which is less preferred by both the client and
server because it is included in the key_shares whereas the
more preferred group is not.
# Downgrade
The draft here talks about there being a downgrade issue. ISTM
that there are two things going on here.
1. If the client chooses its key_shares based solely on authenticated
signals, or, as is presently common, consistently for every server,
then the server may choose a suboptimal combination (from the perspective
of group selection, though not from the perspective of latency), but
the attacker cannot influence this selection.
2. If the client chooses its key_shares based on unauthenticated
signals, such as DNS or falling back on apparent network error
(e.g., due to apparent intolerance of large CH), then the attacker
can exploit the behavior described in (3) to downgrade the selected
groups.
Is this a reasonably accurate summary of the situation?
-Ekr
On Tue, Sep 26, 2023 at 9:46 AM David Benjamin <david...@chromium.org>
wrote:
> Hi all,
>
> A while back, we discussed using a DNS hint to predict key shares and
> reduce HelloRetryRequest, but this was dropped due to downgrade issues. In
> thinking through post-quantum KEMs and the various transitions we'll have
> in the future, I realized we actually need to address those downgrade
> issues now. I've published a draft below which is my attempt at resolving
> this.
>
> We don't need a DNS hint for the *current* PQ transition—most TLS
> ecosystems should stick to the one preferred option, and then clients can
> predict that one and move on. However, I think we need to lay the
> groundwork for it now. If today's round of PQ supported groups cannot be
> marked "prediction-safe" (see document for what I mean by that),
> transitioning to the *next* PQ KEM (e.g. if someone someday comes up with
> a smaller one that we're still confident in!) will be extremely difficult
> without introducing downgrades.
>
> Thoughts?
>
> David
>
> ---------- Forwarded message ---------
> From: <internet-dra...@ietf.org>
> Date: Mon, Sep 25, 2023 at 6:56 PM
> Subject: New Version Notification for
> draft-davidben-tls-key-share-prediction-00.txt
> To: David Benjamin <david...@google.com>
>
>
> A new version of Internet-Draft
> draft-davidben-tls-key-share-prediction-00.txt
> has been successfully submitted by David Benjamin and posted to the
> IETF repository.
>
> Name: draft-davidben-tls-key-share-prediction
> Revision: 00
> Title: TLS Key Share Prediction
> Date: 2023-09-25
> Group: Individual Submission
> Pages: 11
> URL:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-davidben-tls-key-share-prediction/
> HTML:
> https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html
> HTMLized:
> https://datatracker.ietf.org/doc/html/draft-davidben-tls-key-share-prediction
>
>
> Abstract:
>
> This document clarifies an ambiguity in the TLS 1.3 key share
> selection, to avoid a downgrade when server assumptions do not match
> client behavior. It additionally defines a mechanism for servers to
> communicate key share preferences in DNS. Clients may use this
> information to reduce TLS handshake round-trips.
>
>
>
> The IETF Secretariat
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
