From: John Mattsson <john.mattsson@ericsson.com>
To: David Benjamin <davidben@chromium.org>, "<tls@ietf.org>" <tls@ietf.org>
Thread-Topic: [TLS] Exporter compatibility pitfall between (D)TLS 1.2 and 1.3
Thread-Index: AQHbkfnbLUNmCUa1ykm6mPeDNtlzJLNs68UQ
Date: Mon, 10 Mar 2025 22:08:12 +0000
Message-ID: 
 <GVXPR07MB967892EA5A866B81E4AA786089D62@GVXPR07MB9678.eurprd07.prod.outlook.com>
References: 
 <CAF8qwaAqfFMeGFLFaG8Lz=2HtGP5BMBXGX=irFP3vFRQOBFZ5Q@mail.gmail.com>
In-Reply-To: 
 <CAF8qwaAqfFMeGFLFaG8Lz=2HtGP5BMBXGX=irFP3vFRQOBFZ5Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-GB
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: 
 =?Windows-1252?Q?wuTFp/JWOTvmpW+LxGFbmoVGSEHnsTYJCucF5UlARG8UhqF9RSZuHdp1?=
 =?Windows-1252?Q?1gm1i567LAl84PPl1WxNWy72sp7Cw2jHFfzw0rwcwN9L+8qDamaMdTTA?=
 =?Windows-1252?Q?CeDkx0JnS2Mcgqalnh48DjwaMxa9UWxQ6mseh5Co/KWD0TBBY3OXFtwm?=
 =?Windows-1252?Q?zWF9dn5NDh3cETAJXJqjd1gae5c0YbiyBwtYrRSEf7gdGDZYatkbLJT0?=
 =?Windows-1252?Q?zN6YPHnr6XraRd4XLVyTyyoZQMbFvd3QGMNvMmyTCF31xAIuQ68C6F9C?=
 =?Windows-1252?Q?Owas0H+cyJe6vzFPeZg8YXV++1Ph6tBAv9Cqq0LnSPE6hMgrEJWjQbOc?=
 =?Windows-1252?Q?ycEZbMPjbMA2dSmYMgX6lOcA0X+/zo5+Pc9oqgwKpou84EGOpaPWetgt?=
 =?Windows-1252?Q?1+Na/ADN+qLnK8S1U5/BNaLk++z90FheVak6MRdt+zrHGL+NL97RCB8k?=
 =?Windows-1252?Q?VtCtWlZ7SnKDDQ29kx2pBE9hHyjBFZeHCMy53SVqM39+UrorXUXnxfwr?=
 =?Windows-1252?Q?QMT2Kh00i5iLinKx7/YNWZyJM7pV1zlN5+Y97DaoXJyYJ9SQS5wTda3t?=
 =?Windows-1252?Q?VdzXPhdxPbWNwUtTB5kPlyu9Z0lnAKMbzu0b2dZ+Zytkv1OV79EWqN9B?=
 =?Windows-1252?Q?AxGXt0MK9nP4SQ0Vxoq9XNCGDZzSbdXohcDOiBYJtAimqoCsYblLE8DP?=
 =?Windows-1252?Q?AdZUfW77dyPm7E4qsw/vBHPQ+TtIbmNQWMQk44ryM3Di/uGbzUnzpe5d?=
 =?Windows-1252?Q?P1FdvU2PmkT+XCRIby44rCzXS712PB318FRv8j4YD/fTIj2Y1wurJ8jQ?=
 =?Windows-1252?Q?gGMHrQrvgeVnGuu6yXLAa0pYiWCkWS3wNDMLbPRENRqEYSyhcE+Q1Ho7?=
 =?Windows-1252?Q?QE9LsUdNHmCWNSg1ATqzeleJczSiZk+OQ1mGMFwvjZRreZ0gs+yjDURr?=
 =?Windows-1252?Q?WT8SqzH9JCQTTkyHUp+pRl+ikxwX7AwW1IRHvYR0JqUOUWc1VZBZywyz?=
 =?Windows-1252?Q?otvxCvFpkyBxWdETQ44rg987LTnwoPitZ+Mjd0fQkNb3kUyNdu6PtIc5?=
 =?Windows-1252?Q?SFE6Msff8jFaxCsV8oCW4n/puJBjNJpsSxZ+pu2IKjArZBbfreCR6N/N?=
 =?Windows-1252?Q?Qp3rA6A1hDZSfCPEeic/4ua2WTkFTBoGEF6znkdVVr8eaMDvXhJx2oFO?=
 =?Windows-1252?Q?u6/BjBcxmSR5aGjk8VN+/C3q08dU4OfEBSNilt91yWT1NvyifPGRCaMN?=
 =?Windows-1252?Q?W7rvBy8WNjCiFQtqit49JudO9ABQTudk5Nln14yXrkz7XwU09/hJUVea?=
 =?Windows-1252?Q?XkkvGW045zJUckxWz8sDOuXZ7VjP9Si+FWHgJQY9s+47DUktSHhDhelo?=
 =?Windows-1252?Q?n5qBX/mD8+Ea/rLDNsUfqUVQRFeUTXBmmA1AEDhO3hKqS/bftrLpZ2fv?=
 =?Windows-1252?Q?gkaoeVOfrswwkbuf2oENS72joo/+O8u4vzeA1wDs2exo4GSpoKbXLx88?=
 =?Windows-1252?Q?YJdrs2G+/LArMAj7VASAKhkX9UvDcBlYJt+eqAvj98PI3rddN7FOXco7?=
 =?Windows-1252?Q?0JY/xFaHHIa8gDalFVbSzbwjlKU6GCafJFZGCsbjmM5eLtQOArBQWUwZ?=
 =?Windows-1252?Q?3npyGNCp/DvYwZOv5B/8ZBrqKKqRSRCdDQOKOy2arFz0M4tyY1zXlP9q?=
 =?Windows-1252?Q?WzcteH9SO/50+877P5F7epe3Uyh78STE2Vs1lhWk4In+a+mIXlWm1x1q?=
 =?Windows-1252?Q?snW0OM6dgCD7pEdAKOk=3D?=
Content-Type: multipart/alternative;
	boundary="_000_GVXPR07MB967892EA5A866B81E4AA786089D62GVXPR07MB9678eurp_"
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: GVXPR07MB9678.eurprd07.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 
 54254c3e-f7e2-41f7-4dd1-08dd60200caf
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Mar 2025 22:08:12.4321
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: 
 DmFP8OniQYBhZoXcpEIgDvEg+tJadD0HKmjxacWFZ991xJFjDF6sTE8w2LlxuX7cTxayGebc3TFmLqvQ56Wdo+JCTQvOlXvdUsMMrPsUgvQ=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PR3PR07MB6491
Message-ID-Hash: GCFNDA4VN5NS5ZSB57Y7AHWQQ4HMXX7V
X-Message-ID-Hash: GCFNDA4VN5NS5ZSB57Y7AHWQQ4HMXX7V
X-MailFrom: john.mattsson@ericsson.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency;
 loop; banned-address; member-moderation; header-match-tls.ietf.org-0;
 nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size;
 news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: =?utf-8?q?=5BTLS=5D_Re=3A_Exporter_compatibility_pitfall_between_=28D=29TLS_?=
	=?utf-8?q?1=2E2_and_1=2E3?=
List-Id: "This is the mailing list for the Transport Layer Security working
 group of the IETF." <tls.ietf.org>
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/tls/jFbC-k2KXIHjC9jM8Vt_E15o-R0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

--_000_GVXPR07MB967892EA5A866B81E4AA786089D62GVXPR07MB9678eurp_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi David,

I remember that the same problem was discussed when standardizing EAP-TLS 1=
.3. The following text is in RFC 9190:

  =93Note that the key derivation MUST use the length values given above.
   While in TLS 1.2 and earlier it was possible to truncate the output
   by requesting less data from the TLS-Exporter function, this practice
   is not possible with TLS 1.3.  If an implementation intends to use
   only a part of the output of the TLS-Exporter function, then it MUST
   ask for the full output and then only use the desired part.  Failure
   to do so will result in incorrect values being calculated for the
   above keying material.=94

I agree that it would be good if 8446bis discussed the problem.

Cheers,
John

From: David Benjamin <davidben@chromium.org>
Date: Monday, 10 March 2025 at 21:20
To: <tls@ietf.org>
Subject: [TLS] Exporter compatibility pitfall between (D)TLS 1.2 and 1.3
Hi all,

I recently spent some time debugging an interop issue between WebRTC + DTLS=
 1.3 in Chrome and WebRTC + DTLS 1.3 in Firefox. The cause of the issue was=
 a minor but interesting incompatibility between (D)TLS 1.2 and (D)TLS 1.3 =
that doesn't seem to have been flagged in RFC 8446 anywhere. Nothing action=
able for this group, apart from maybe a last minute sentence to add to 8446=
bis (way too late to change how exporters work), but I thought I would pass=
 it along for general awareness.

WebRTC uses DTLS-SRTP, which uses export keying material to generate some s=
pecified number of bytes of data:
https://www.rfc-editor.org/rfc/rfc5764.html#section-4.2

It turns out Firefox exported the maximum key+salt length and then only use=
d a prefix of the output, rather than exporting the length as specified in =
RFC 5764. Back in 1.2, this was just fine and gave the right output. The re=
quested length didn't figure into the derivation. But 1.3 incorporates the =
requested length into the derivation, so now this computes the wrong value.

This means, starting with 1.3, applications must be sure to pass in exactly=
 the length specified by the protocol they're implementing. Applications th=
at relied on this 1.2 property will silently do the wrong thing when upgrad=
ing to 1.3.

David

--_000_GVXPR07MB967892EA5A866B81E4AA786089D62GVXPR07MB9678eurp_
Content-Type: text/html; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DWindows-1=
252">
<meta name=3D"Generator" content=3D"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:Aptos;
	panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	font-size:12.0pt;
	font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Aptos",sans-serif;
	color:windowtext;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;
	mso-ligatures:none;}
@page WordSection1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang=3D"en-SE" link=3D"blue" vlink=3D"purple" style=3D"word-wrap:brea=
k-word">
<div class=3D"WordSection1">
<p class=3D"MsoNormal"><span lang=3D"EN-US">Hi David,<br>
<br>
I remember that the same problem was discussed when standardizing EAP-TLS 1=
.3. The following text is in RFC 9190:<br>
</span><span lang=3D"EN-US"></span><span lang=3D"EN-US"><br>
</span>&nbsp;&nbsp;<span lang=3D"EN-US">=93</span>Note that the key derivat=
ion MUST use the length values given above.<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp; While in TLS 1.2 and earlier it was pos=
sible to truncate the output<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp; by requesting less data from the TLS-Ex=
porter function, this practice<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp; is not possible with TLS 1.3.&nbsp; If =
an implementation intends to use<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp; only a part of the output of the TLS-Ex=
porter function, then it MUST<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp; ask for the full output and then only u=
se the desired part.&nbsp; Failure<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp; to do so will result in incorrect value=
s being calculated for the<o:p></o:p></p>
<p class=3D"MsoNormal">&nbsp;&nbsp; above keying material.<span lang=3D"EN-=
US">=94<o:p></o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"mso-fareast-language:E=
N-US"><o:p>&nbsp;</o:p></span></p>
<p class=3D"MsoNormal"><span lang=3D"EN-US" style=3D"mso-fareast-language:E=
N-US">I agree that it would be good if
</span>8446bis <span lang=3D"EN-US">discussed the problem.<br>
<br>
Cheers,<br>
John</span><span lang=3D"EN-US" style=3D"mso-fareast-language:EN-US"><o:p><=
/o:p></span></p>
<p class=3D"MsoNormal"><span style=3D"font-size:11.0pt;mso-fareast-language=
:EN-US"><o:p>&nbsp;</o:p></span></p>
<div id=3D"mail-editor-reference-message-container">
<div>
<div>
<div style=3D"border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm">
<p class=3D"MsoNormal" style=3D"margin-bottom:12.0pt"><b><span style=3D"col=
or:black">From:
</span></b><span style=3D"color:black">David Benjamin &lt;davidben@chromium=
.org&gt;<br>
<b>Date: </b>Monday, 10 March 2025 at 21:20<br>
<b>To: </b>&lt;tls@ietf.org&gt;<br>
<b>Subject: </b>[TLS] Exporter compatibility pitfall between (D)TLS 1.2 and=
 1.3<o:p></o:p></span></p>
</div>
<div>
<p class=3D"MsoNormal">Hi all,<o:p></o:p></p>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">I recently spent some time debugging an interop issu=
e between WebRTC + DTLS 1.3 in Chrome and WebRTC&nbsp;+ DTLS 1.3 in Firefox=
. The cause of the issue was a minor but interesting incompatibility betwee=
n (D)TLS 1.2 and (D)TLS 1.3 that doesn't
 seem to have been flagged in RFC 8446 anywhere. Nothing actionable for thi=
s group, apart from maybe a last minute sentence to add to 8446bis&nbsp;(wa=
y too late to change how exporters work), but I thought I would pass it alo=
ng for general awareness.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">WebRTC uses DTLS-SRTP, which uses export keying mate=
rial to generate some specified number of bytes of data:<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><a href=3D"https://www.rfc-editor.org/rfc/rfc5764.ht=
ml#section-4.2">https://www.rfc-editor.org/rfc/rfc5764.html#section-4.2</a>=
<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">It turns out Firefox exported the maximum key+salt l=
ength and then only used a prefix of the output, rather than exporting the =
length as specified in RFC 5764. Back in 1.2, this was just fine and gave t=
he right output. The requested length
 didn't figure into the derivation. But 1.3 incorporates the requested leng=
th into the derivation, so now this computes the wrong value.<o:p></o:p></p=
>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">This means, starting with 1.3, applications must be =
sure to pass in exactly the length specified by the protocol they're implem=
enting. Applications that relied on this 1.2 property will silently do the =
wrong thing when upgrading to 1.3.<o:p></o:p></p>
</div>
<div>
<p class=3D"MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
<div>
<p class=3D"MsoNormal">David<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_GVXPR07MB967892EA5A866B81E4AA786089D62GVXPR07MB9678eurp_--