[prev in list] [next in list] [prev in thread] [next in thread]
List: ietf-tls
Subject: Re: [TLS] A suggestion for handling large key shares
From: "Kampanakis, Panos" <kpanos=40amazon.com () dmarc ! ietf ! org>
Date: 2024-03-20 2:30:19
Message-ID: 85f9ae284c3046ae9fd3af4bac9cbc0d () amazon ! com
[Download RAW message or body]
[Attachment #2 (text/plain)]
ACK, thx, I had missed the discussions. It looks like what I was referring to is \
addressed more prescriptively in rfc8446bis. That is great.
From: David Benjamin <davidben@chromium.org>
Sent: Tuesday, March 19, 2024 4:42 PM
To: Kampanakis, Panos <kpanos@amazon.com>
Cc: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org>; TLS@ietf.org
Subject: RE: [EXTERNAL] [TLS] A suggestion for handling large key shares
CAUTION: This email originated from outside of the organization. Do not click links \
or open attachments unless you can confirm the sender and know the content is safe.
I think you're several discussions behind here. :-P I don't think \
draft-ietf-tls-hybrid-design makes sense here. This has nothing to do with hybrids, \
but anything with large key shares. If one were to do Kyber on its own, this would \
apply too. Rather, per the discussion at IETF 118, the WG opted to add some \
clarifications to rfc8446bis in light of draft-00.
It has also turned out that:
a) RFC 8446 actually already defined the semantics (when I wrote draft-00, I'd \
thought it was ambiguous), though the clarification definitely helped b) The \
implementation that motivated the downgrade concern says this was not bug from \
misunderstanding the protocol, but an intentional design decision
Given that, the feedback on the list and \
https://github.com/davidben/tls-key-share-prediction/issues/5, I concluded past-me \
was overthinking this and we can simply define the DNS mechanism and say it is the \
server's responsibility to interpret the preexisting TLS spec text correctly and pick \
what it believes is a coherent selection policy. So draft-01 now simply defines the \
DNS mechanism without any complex codepoint classification and includes some \
discussion of the situation in Security Considerations, as you noted.
Of what remains in Security Considerations, the random client MAY is specific to this \
draft and does not make sense to move. The server NOT RECOMMENDED is simply restating \
the preexisting implications of RFC 8446 and the obvious implications of believing \
some options are more secure than others. If someone wishes to replicate it into \
another document, they're welcome to, but I disagree with moving it. In the context \
of the discussion in that section, it makes sense to restate this implication because \
this is very relevant to why it's okay for the client to use DNS to influence key \
shares.
David
On Wed, Mar 20, 2024 at 6:08 AM Kampanakis, Panos \
<kpanos@amazon.com<mailto:kpanos@amazon.com>> wrote: Hi Scott, David,
I think it would make more sense for the normative language about Client and Server \
behavior (section 3.2, 3.4) in draft-davidben-tls-key-share-prediction-00 \
(https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html ) to \
go in draft-ietf-tls-hybrid-design. These are now discussed in the Sec Considerations \
of draft-davidben-tls-key-share-prediction-01, but the "SHOULD" and "SHOULD NOT" \
language from -00 section 3.2 and 3.4 ought to be in draft-ietf-tls-hybrid-design.
I definitely want to see draft-davidben-tls-key-share-prediction move forward too.
Rgs,
Panos
From: TLS <tls-bounces@ietf.org<mailto:tls-bounces@ietf.org>> On Behalf Of David \
Benjamin
Sent: Tuesday, March 19, 2024 1:26 AM
To: Scott Fluhrer (sfluhrer) \
<sfluhrer=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>>
Cc: TLS@ietf.org<mailto:TLS@ietf.org>
Subject: RE: [EXTERNAL] [TLS] A suggestion for handling large key shares
CAUTION: This email originated from outside of the organization. Do not click links \
or open attachments unless you can confirm the sender and know the content is safe.
> If the server supports P256+ML-KEM, what Matt suggested is that, instead of \
> accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then continue \
> as expected and end up negotiating things in 2 round trips.
I assume ClientHelloRetry was meant to be HelloRetryRequest? If so, yeah, a server \
which aims to prefer P256+ML-KEM over P256 should, well, prefer P256+ML-KEM over \
P256. :-) See the discussions around draft-davidben-tls-key-share-prediction. In \
particular, RFC 8446 is clear on the semantics of such a ClientHello:
This vector MAY be empty if the client is requesting a
HelloRetryRequest. Each KeyShareEntry value MUST correspond to a
group offered in the "supported_groups" extension and MUST appear in
the same order. However, the values MAY be a non-contiguous subset
of the "supported_groups" extension and MAY omit the most preferred
groups. Such a situation could arise if the most preferred groups
are new and unlikely to be supported in enough places to make
pregenerating key shares for them efficient.
rfc8446bis contains further clarifications: \
https://github.com/tlswg/tls13-spec/pull/1331
Now, some servers (namely OpenSSL) will instead unconditionally select from key_share \
first. This isn't wrong, per se. It is how you implement a server which believes all \
of its supported groups are of comparable security level and therefore prioritizes \
round trips. Such a policy is plausible when you only support, say, ECDH curves. It's \
not so reasonable if you support both ECDH and a PQ KEM. But all the spec text for \
that is in place, so all that is left is that folks keep this in mind when adding PQ \
KEMs to a TLS implementation. A TLS stack that always looks at key_share first is not \
PQ-ready and will need some changes before adopting PQ KEMs.
Regarding the other half of this:
> Suppose we have a client that supports both P-256 and P256+ML-KEM. What the client \
> does is send a key share for P-256, and also indicate support for P256+ML-KEM. \
> Because we're including only the P256 key share, the client hello is short
I don't think this is a good tradeoff and would oppose such a SHOULD here. PQ KEMs \
are expensive as they are. Adding a round-trip to it will only make it worse. Given \
the aim is to migrate the TLS ecosystem to PQ, penalizing the desired state doesn't \
make sense. Accordingly, Chrome's Kyber deployment includes X25519Kyber768 in the \
initial ClientHello. While this does mean paying an unfortunate upfront cost, this \
alternative would instead disincentivize servers from deploying post-quantum \
protections.
If you're interested in avoiding the upfront cost, see \
draft-davidben-tls-key-share-prediction-01. That provides a mechanism for clients to \
predict more accurately, though it's yet to even be adopted, so it's a bit early to \
rely on that one. Note also the Security Considerations section, which further \
depends on the server expectations above.
David
On Tue, Mar 19, 2024 at 2:47 PM Scott Fluhrer (sfluhrer) \
<sfluhrer=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote: \
Recently, Matt Campagna emailed the hybrid KEM group (Douglas, Shay and me) about a \
suggestion about one way to potentially improve the performance (in the ‘the server \
hasn't upgraded yet' case), and asked if we should add that suggestion to our draft. \
It occurs to me that this suggestion is equally applicable to the pure ML-KEM draft \
(and future PQ drafts as well); hence putting it in our draft might not be the right \
spot.
Here's the core idea (Matt's original scenario was more complicated):
* Suppose we have a client that supports both P-256 and P256+ML-KEM. What the \
client does is send a key share for P-256, and also indicate support for P256+ML-KEM. \
Because we're including only the P256 key share, the client hello is \
short
* If the server supports only P256, it accepts it, and life goes on as normal.
* If the server supports P256+ML-KEM, what Matt suggested is that, instead of \
accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then continue as \
expected and end up negotiating things in 2 round trips.
Hence, the non-upgraded scenario has no performance hit; the upgraded scenario does \
(because of the second round trip), but we're transmitting more data anyways (and the \
client could, if it communicates with the server again, lead off with the proposal \
that was accepted last time).
Matt's suggestion was that this should be a SHOULD in our draft.
My questions to you: a) do you agree with this suggestion, and b) if so, where should \
this SHOULD live? Should it be in our draft? The ML-KEM draft as well (assuming \
there is one, and it's not just a codepoint assignment)? Another RFC about how to \
handle large key shares in general (sounds like overkill to me, unless we have other \
things to put in that RFC)?
Thank you.
_______________________________________________
TLS mailing list
TLS@ietf.org<mailto:TLS@ietf.org>
https://www.ietf.org/mailman/listinfo/tls
[Attachment #3 (text/html)]
<html xmlns:v="urn:schemas-microsoft-com:vml" \
xmlns:o="urn:schemas-microsoft-com:office:office" \
xmlns:w="urn:schemas-microsoft-com:office:word" \
xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" \
xmlns="http://www.w3.org/TR/REC-html40"> <head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:182331961;
mso-list-template-ids:-184507400;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">ACK, thx, I had missed the discussions. It looks like what I was \
referring to is addressed more prescriptively in rfc8446bis. That is great. \
<o:p></o:p></p> <p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> David Benjamin <davidben@chromium.org> <br>
<b>Sent:</b> Tuesday, March 19, 2024 4:42 PM<br>
<b>To:</b> Kampanakis, Panos <kpanos@amazon.com><br>
<b>Cc:</b> Scott Fluhrer (sfluhrer) <sfluhrer=40cisco.com@dmarc.ietf.org>; \
TLS@ietf.org<br> <b>Subject:</b> RE: [EXTERNAL] [TLS] A suggestion for handling large \
key shares<o:p></o:p></p> </div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" \
style="border-collapse:collapse"> <tbody>
<tr style="height:15.25pt">
<td width="1123" valign="top" style="width:842.35pt;border:solid #ED7D31 \
1.5pt;padding:0in 5.4pt 0in 5.4pt;height:15.25pt"> <p><strong><span \
style="font-family:"Calibri",sans-serif;background:#FFFF99">CAUTION</span></strong><span \
style="background:#FFFF99">: This email originated from outside of the organization. \
Do not click links or open attachments unless you can confirm the sender and know \
the content is safe.</span><o:p></o:p></p> </td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">I think you're several discussions behind here. :-P I don't \
think draft-ietf-tls-hybrid-design makes sense here. This has nothing to do with \
hybrids, but anything with large key shares. If one were to do Kyber on its own, this \
would apply too. Rather, per the discussion at IETF 118, the WG opted to add some \
clarifications to rfc8446bis in light of draft-00.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">It has also turned out that:<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal">a) RFC 8446 actually already defined the semantics (when I wrote \
draft-00, I'd thought it was ambiguous), though the clarification definitely \
helped<o:p></o:p></p> </div>
<div>
<p class="MsoNormal">b) The implementation that motivated the downgrade concern says \
this was not bug from misunderstanding the protocol, but an intentional design \
decision<o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Given that, the feedback on the list and <a \
href="https://github.com/davidben/tls-key-share-prediction/issues/5" \
target="_blank">https://github.com/davidben/tls-key-share-prediction/issues/5</a>, I \
concluded past-me was overthinking this and we can simply define the DNS mechanism \
and say it is the server's responsibility to interpret the preexisting TLS spec text \
correctly and pick what it believes is a coherent selection policy. So draft-01 now \
simply defines the DNS mechanism without any complex codepoint classification and \
includes some discussion of the situation in Security Considerations, as you \
noted.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Of what remains in Security Considerations, the random client \
MAY is specific to this draft and does not make sense to move. The server NOT \
RECOMMENDED is simply restating the preexisting implications of RFC 8446 and the \
obvious implications of believing some options are more secure than others. If \
someone wishes to <i>replicate</i> it into another document, they're welcome to, but \
I disagree with <i>moving</i> it. In the context of the discussion in that \
section, it makes sense to restate this implication because this is very relevant to \
why it's okay for the client to use DNS to influence key shares.<o:p></o:p></p> \
</div> <div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">David<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Wed, Mar 20, 2024 at 6:08 AM Kampanakis, Panos <<a \
href="mailto:kpanos@amazon.com" target="_blank">kpanos@amazon.com</a>> \
wrote:<o:p></o:p></p> </div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt;margin-left:4.8pt;margin-right:0in"> <div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hi \
Scott, David,<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I think \
it would make more sense for the normative language about Client and Server behavior \
(section 3.2, 3.4) in draft-davidben-tls-key-share-prediction-00 (<a \
href="https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html" \
target="_blank">https://www.ietf.org/archive/id/draft-davidben-tls-key-share-prediction-00.html</a>
) to go in draft-ietf-tls-hybrid-design. These are now discussed in the Sec \
Considerations of draft-davidben-tls-key-share-prediction-01, but the "SHOULD" and \
"SHOULD NOT" language from -00 section 3.2 and 3.4 ought to be in \
draft-ietf-tls-hybrid-design. <o:p></o:p></p>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I \
definitely want to see draft-davidben-tls-key-share-prediction move forward too. \
<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Rgs, \
<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Panos<o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><b>From:</b> TLS <<a \
href="mailto:tls-bounces@ietf.org" target="_blank">tls-bounces@ietf.org</a>> <b>On \
Behalf Of </b>David Benjamin<br> <b>Sent:</b> Tuesday, March 19, 2024 1:26 AM<br>
<b>To:</b> Scott Fluhrer (sfluhrer) <sfluhrer=<a \
href="mailto:40cisco.com@dmarc.ietf.org" \
target="_blank">40cisco.com@dmarc.ietf.org</a>><br> <b>Cc:</b> <a \
href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br> <b>Subject:</b> RE: \
[EXTERNAL] [TLS] A suggestion for handling large key shares<o:p></o:p></p> </div>
</div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
<div> <table class="MsoNormalTable" border="0" cellspacing="0" cellpadding="0" \
style="border-collapse:collapse"> <tbody>
<tr style="height:15.25pt">
<td width="1123" valign="top" style="width:842.35pt;border:solid #ED7D31 \
1.5pt;padding:0in 5.4pt 0in 5.4pt;height:15.25pt"> <p><strong><span \
style="font-family:"Calibri",sans-serif;background:#FFFF99">CAUTION</span></strong><span \
style="background:#FFFF99">: This email originated from outside of the organization. \
Do not click links or open attachments unless you can confirm the sender and know \
the content is safe.</span><o:p></o:p></p> </td>
</tr>
</tbody>
</table>
</div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
<div> <div>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> \
If the server supports P256+ML-KEM, what Matt suggested is that, instead of \
accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then \
continue as expected and end up negotiating things in 2 round trips.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I \
assume ClientHelloRetry was meant to be HelloRetryRequest? If so, yeah, a server \
which aims to prefer P256+ML-KEM over P256 should, well, prefer P256+ML-KEM \
over P256. :-) See the discussions around draft-davidben-tls-key-share-prediction. \
In particular, RFC 8446 is clear on the semantics of such a \
ClientHello:<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> This vector \
MAY be empty if the client is requesting a<br> HelloRetryRequest. \
Each KeyShareEntry value MUST correspond to a<br> group offered in the \
"supported_groups" extension and MUST appear in<br> the same \
order. However, the values MAY be a non-contiguous subset<br> of \
the "supported_groups" extension and MAY omit the most preferred<br> \
groups. Such a situation could arise if the most preferred groups<br> \
are new and unlikely to be supported in enough places to make<br> \
pregenerating key shares for them efficient.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">rfc8446bis contains \
further clarifications: <a href="https://github.com/tlswg/tls13-spec/pull/1331" \
target="_blank">https://github.com/tlswg/tls13-spec/pull/1331</a><o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Now, \
some servers (namely OpenSSL) will instead unconditionally select from key_share \
first. This isn't wrong, per se. It is how you implement a server which believes all \
of its supported groups are of comparable security level and therefore prioritizes \
round trips. Such a policy is plausible when you only support, say, ECDH curves. It's \
not so reasonable if you support both ECDH and a PQ KEM. But all the spec text for \
that is in place, so all that is left is that folks keep this in mind when adding PQ \
KEMs to a TLS implementation. A TLS stack that always looks at key_share first is not \
PQ-ready and will need some changes before adopting PQ KEMs.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Regarding the other half \
of this:<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">> Suppose we have \
a client that supports both P-256 and P256+ML-KEM. What the client does is \
send a key share for P-256, and also indicate support for P256+ML-KEM. \
Because we're including only the P256 key share, the client hello is \
short<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">I don't think this is a \
good tradeoff and would oppose such a SHOULD here. PQ KEMs are expensive as \
they are. Adding a round-trip to it will only make it worse. Given the aim is to \
migrate the TLS ecosystem to PQ, penalizing the desired state doesn't make \
sense. Accordingly, Chrome's Kyber deployment includes X25519Kyber768 in the \
initial ClientHello. While this does mean paying an unfortunate upfront cost, this \
alternative would instead disincentivize servers from deploying post-quantum \
protections.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">If \
you're interested in avoiding the upfront cost, see \
draft-davidben-tls-key-share-prediction-01. That provides a mechanism for clients \
to predict more accurately, though it's yet to even be adopted, so it's a bit \
early to rely on that one. Note also the Security Considerations section, which \
further depends on the server expectations above.<o:p></o:p></p> </div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
</div> <div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">David<o:p></o:p></p> \
</div> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> \
<div> <div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">On \
Tue, Mar 19, 2024 at 2:47 PM Scott Fluhrer (sfluhrer) <sfluhrer=<a \
href="mailto:40cisco.com@dmarc.ietf.org" \
target="_blank">40cisco.com@dmarc.ietf.org</a>> wrote:<o:p></o:p></p> </div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in \
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt"> <div>
<div>
<div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Recently, Matt Campagna \
emailed the hybrid KEM group (Douglas, Shay and me) about a suggestion about one way \
to potentially improve the performance (in the ‘the server hasn't upgraded yet' \
case), and asked if we should add that suggestion to our draft. It occurs to me \
that this suggestion is equally applicable to the pure ML-KEM draft (and future PQ \
drafts as well); hence putting it in our draft might not be the right \
spot.<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Here's \
the core idea (Matt's original scenario was more complicated):<o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<ul type="disc">
<li class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1"> \
Suppose we have a client that supports both P-256 and P256+ML-KEM. What the \
client does is send a key share for P-256, and also indicate support for \
P256+ML-KEM. Because we're including only the P256 key share, the client \
hello is short<o:p></o:p></li><li class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1"> \
If the server supports only P256, it accepts it, and life goes on as \
normal.<o:p></o:p></li><li class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo1"> \
If the server supports P256+ML-KEM, what Matt suggested is that, instead of \
accepting P256, it instead a ClientHelloRetry with P256+ML_KEM. We then \
continue as expected and end up negotiating things in 2 round \
trips.<o:p></o:p></li></ul> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Hence, \
the non-upgraded scenario has no performance hit; the upgraded scenario does (because \
of the second round trip), but we're transmitting more data anyways (and the client \
could, if it communicates with the server again, lead off with the proposal that was \
accepted last time).<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Matt's \
suggestion was that this should be a SHOULD in our draft.<o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">My \
questions to you: a) do you agree with this suggestion, and b) if so, where should \
this SHOULD live? Should it be in our draft? The ML-KEM draft as well \
(assuming there is one, and it's not just a codepoint assignment)? Another RFC \
about how to handle large key shares in general (sounds like overkill to me, unless \
we have other things to put in that RFC)?<o:p></o:p></p> <p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"> <o:p></o:p></p> <p \
class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">Thank \
you. <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal" \
style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto">_______________________________________________<br>
TLS mailing list<br>
<a href="mailto:TLS@ietf.org" target="_blank">TLS@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/tls" \
target="_blank">https://www.ietf.org/mailman/listinfo/tls</a><o:p></o:p></p> </div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</body>
</html>
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--===============1650453094441613241==--
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic