Received-SPF: Pass (protection.outlook.com: domain of arm.com designates
 63.35.35.123 as permitted sender) receiver=protection.outlook.com;
 client-ip=63.35.35.123; helo=64aa7808-outbound-1.mta.getcheckrecipient.com;
From: Hanno Becker <Hanno.Becker@arm.com>
To: Christopher Wood <caw@heapingbits.net>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: [TLS] On the two types of ACKs in DTLS 1.3
Thread-Index: AQHWCa+c/6zqL3NX202z6YHPiVC69KiF6cOAgAB387Q=
Date: Thu, 23 Apr 2020 06:49:44 +0000
Message-ID: <AM6PR08MB33181AE7A270DBF7AF08BD789BD30@AM6PR08MB3318.eurprd08.prod.outlook.com>
References: <AM6PR08MB33187063CE8ED77847600C709BC70@AM6PR08MB3318.eurprd08.prod.outlook.com>,
 <d4e4918e-3dc9-47c1-88e6-ca439f5e85b4@www.fastmail.com>
In-Reply-To: <d4e4918e-3dc9-47c1-88e6-ca439f5e85b4@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
Authentication-Results-Original: spf=none (sender IP is )
 smtp.mailfrom=Hanno.Becker@arm.com; 
nodisclaimer: true
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
X-Microsoft-Antispam-Message-Info-Original: picA5+7BedKI+354bfjvtJBuWg8F+BDgxkhtBe04WOGJxlFYfmcL6Z5ZkpX0lumu6cpyq1CZI4MB4FOq/kI/ZH/HWV2r6YlCzCN6qQbzUJUMqtSjWwrT64PPZEoFTxaAXdMd976csDMSTVIAffkt6OGNK4nezlSLRwM+LK++2U39KL/m5Wr24jneMrL1I49dFZIODPoKQkfyFXiU8Z/uBoKYvbckul9rJPPA9/JPTn6gRWOMyJrb4hyAiDRslDqKAWyQIIlqRnBwZ1kJ36ghFe405QEm5AoxNfGPHT9O+kXW3EcqGy6nBrneww+i4II6YvH2JXnhWi9pyakthHNAhltYF8TifZ0ZisRoNHUj2cvp4MSWzeN6g9FjTiUTj243ynARtCthEWTPogOBpLEulxZGuMAvUuuZ7pIXxsIJTn1BTwA+bGuDPSMdzoz8LcS35Zhp0Dz89Rsc2tGzClAH3lC4pgcyAk2rGhzurTbrRDWW1PBCSED8BMobabfTr4dtI6EsZ71oPCRbrrhSKuW1Pg==
x-ms-exchange-antispam-messagedata: ZD7u9wFh7QnodewXO3nKX/ZS8JnswfCpijx6jsZowIh5LaTheBMe63ujgc8QtGwuu+pFptJlIdKZ5ThwpTH+z6lSZzLJHBBfKk4gkMyJfcWUGo7cEVutMwb4C9WLqsmY1olb2Z1WQHPqez2qDeabuQ==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
 boundary="_000_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_"
MIME-Version: 1.0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6PR08MB4949
Original-Authentication-Results: spf=none (sender IP is )
 smtp.mailfrom=Hanno.Becker@arm.com; 
X-EOPAttributedMessage: 0
X-MS-Exchange-Transport-CrossTenantHeadersStripped: VE1EUR03FT037.eop-EUR03.prod.protection.outlook.com
X-Forefront-Antispam-Report: CIP:63.35.35.123; CTRY:IE; LANG:en; SCL:1; SRV:; 
 IPV:CAL; SFV:NSPM;
 H:64aa7808-outbound-1.mta.getcheckrecipient.com; 
 PTR:ec2-63-35-35-123.eu-west-1.compute.amazonaws.com; CAT:NONE; SFTY:;
 SFS:(4636009)(346002)(376002)(39860400002)(136003)(396003)(46966005)(82740400003)(316002)(966005)(110136005)(33656002)(478600001)(336012)(9686003)(36906005)(55016002)(186003)(19627405001)(8936002)(81156014)(52536014)(47076004)(70206006)(7696005)(8676002)(70586007)(81166007)(82310400002)(356005)(86362001)(26005)(30864003)(6506007)(5660300002)(2906002)(53546011);
 DIR:OUT; SFP:1101; 
X-MS-Office365-Filtering-Correlation-Id-Prvs: c3917dc9-dff6-4961-dd1b-08d7e75281cc
X-Forefront-PRVS: 03827AF76E
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: jTmW2laGflTV3RJItSRu1/oSAQ9ztfZm/YFw/nv8jdlhySN+7C5xbI9DgxhSAS0VbEhPjhSs4Z4MpiShk1I6w6rmxZiURFLeRAhZcGm8HkMXZ6jEVFdC+cUgy+IS6GOmTIj+uBrFKSRS2OE2W9xEMgkGIcg4gHUV1Q6xINYAZwp472/P8x5AMAd5bXf6OTfuHs5Jp4r2+n2owt2BnA5qOize6zz7KwZE6DylOvF3vLaTFxDFPoiC2rSowSCCFctUeML7G6r0E53RAK14/zeheeBz+BDKUBNCTjFaKoTzy6OPYDIymBdA+53TCrAC8waoy8d+apw/e/k+M+YfStxYXwm319s7iDxwig2tMMwk/ebdaipO+JGu1BZCAyh5VFteGLA8T/S7NCbDZV9lLoP1q9XhuJj0Qw1AWVlOwscLOotSxK10xp9jNge2z+/45ASA+cbHp2BrAVtRwMUenKVlqrHKGGtpOvbN+1PlMTk1JBuo7Ryj01hdo14zs9k+apIAFY8TB+I+eN4bMzCpz+RLI0fAufqnlQUp8UsPjUww44ofDCvv4rTUKy8q+NliS/j/eyf+iSIhKf4NkhqOmhopEw==
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Apr 2020 06:49:52.1924 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 753a8e44-5346-4b63-9307-08d7e7528655
X-MS-Exchange-CrossTenant-Id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=f34e5979-57d9-4aaa-ad4d-b122a662184d; Ip=[63.35.35.123]; 
 Helo=[64aa7808-outbound-1.mta.getcheckrecipient.com]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR08MB4180
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/YgjbTVTVDQYC9pkrRhSQzXm7vS8>
Subject: Re: [TLS] On the two types of ACKs in DTLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working
 group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>,
 <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>,
 <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Apr 2020 06:50:00 -0000

--_000_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Chris,

Thanks for your reply. No, the PR does not address the issue described belo=
w,
because it keeps the use of a single kind of ACK for the two different purp=
oses
(a) retransmission requests [optional] and (b) acknowledgement of completio=
n
[mandatory]. However, it clearly describes this double-use of ACKs, which a=
lready
is a good thing IMO.

However, as mentioned, given the late stage of standardization, I merely wa=
nted to
have this point raised and perhaps discussed, but didn't expect a change in=
 the end.
Unfortunately, there doesn't seem to be much interest in this, so I think o=
ne can put this
to the records.

Cheers,
Hanno
________________________________
From: TLS <tls-bounces@ietf.org> on behalf of Christopher Wood <caw@heaping=
bits.net>
Sent: Thursday, April 23, 2020 12:34 AM
To: TLS@ietf.org <tls@ietf.org>
Subject: Re: [TLS] On the two types of ACKs in DTLS 1.3

Hi Hanno,

I believe this (now merged) PR addresses your concerns:

   https://github.com/tlswg/dtls13-spec/pull/140

Best,
Chris

On Fri, Apr 3, 2020, at 5:08 AM, Hanno Becker wrote:
>  Hi all,
>
> I am aware that we're late into the standardization of DTLS 1.3, and
> likely too late for any intrusive change, but I'd still like to share
> another comment on the proposed ACKing scheme and its implication on
> complexity of migration from DTLS 1.2 to DTLS 1.3, in addition to the
> aspect discussed earlier regarding handshake-level vs. record-level ACKs
> (https://mailarchive.ietf.org/arch/msg/tls/O0pghTnz_8q1AiHSeMSzxZg30RM/)
>
> As it stands, there are two quite different kinds of ACKs sharing
> the same wire-format:
>
> 1. ACKs as 'retransmission requests'
>
>  Consider the following two excerpts from the draft:
>
>  A:
>  "When an implementation receives a partial flight, it SHOULD generate
>  an ACK that covers the messages from that flight which it has
>  received so far."
>
>  B:
>  "Upon receipt
>  of an ACK for only some messages from a flight, an implementation
>  SHOULD retransmit the remaining messages or fragments."
>
>  This means that ACKs should be sent only on signs of disruption,
>  and that receivers of partial ACKs are supposed to immediately
>  retransmit.
>
>  In particular, this precludes recurring use of ACKs where an ACK
>  is generated for each message as it comes in and is processed:
>  Indeed, implementations behaving this way would trigger multiple
>  retransmissions on the peer, provided the peer obeys (B), even
>  if there's not a single packet-loss or reordering occurring.
>
>  In this sense, the above ACKs are 'negative' and should not be
>  seen at all during a disruption-free handshake.
>
>  Note, also, that handshakes will continue to progress if this
>  kind of ACKs is entirely ignored, which amounts to falling back
>  to how DTLS 1.2 handles retransmissions, purely on the basis
>  of timeouts and implicit acknowledgement.
>
> 2. ACKs as 'acknowledgement of completion'
>
>  In contrast to the previous kind of ACK, those ACKs are 'positive'
>  in that they indicate completion of a handshake, and they are
>  mandatory in that a handshake will not complete unless they are
>  used. In particular, an implementation MUST support those kinds
>  of ACKs.
>
> At the moment, both kinds of ACKs are handled in the same way on the wire=
,
> and in order to even distinguish them an implementation has to maintain
> accurate knowledge of the sequence numbers of records it has sent.
>
> In particular, even if implementations decide to not make use of
> type-1 ACKs -- that is, retransmission requests -- it doesn't buy
> them anything in terms of code-size and simplicity, because they
> still have to implement type-2 ACKs, and detecting those requires
> implementing record sequence number bookkeeping.
>
> I believe that this will harden migration of DTLS 1.2 stacks to DTLS 1.3,
> because it makes the minimal difference between a compliant DTLS 1.3
> implementation and a pair of "DTLS 1.2 + TLS 1.3 logic" quite large.
>
> In contrast, if retransmission requests and completion-ACKs were treated
> differently, and in particular easily distinguishable on the wire, then
> migration from a pair of DTLS 1.2 + TLS 1.3 stack to a minimal compliant
> DTLS 1.3 would only require implementing 'completion-ACKs', which, since
> they convey only a single bit of information, can in principle have a
> much simpler wire-format than what we have for ACKs today.
>
> I would be interested in comments from implementors, esp. for stacks
> targeting embedded / constrained environments.
>
> Cheers,
> Hanno
>
>  IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy
> the information in any medium. Thank you.
> _______________________________________________
> 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
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.

--_000_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"=
>
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
Hi Chris,</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
Thanks for your reply. No, the PR does not address the issue described belo=
w,&nbsp;</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
because it keeps the use&nbsp;<span style=3D"color: rgb(0, 0, 0); font-fami=
ly: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt;">of a single ki=
nd of ACK for the two different purposes&nbsp;</span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica,=
 sans-serif; font-size: 12pt;">(a) retransmission requests [optional]&nbsp;=
</span><span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Arial, Hel=
vetica, sans-serif; font-size: 12pt;">and
 (b) acknowledgement of completion</span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica,=
 sans-serif; font-size: 12pt;">[mandatory]. However,&nbsp;</span><span styl=
e=3D"color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica, sans-seri=
f; font-size: 12pt;">it clearly describes
 this double-use of ACKs, which already&nbsp;</span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
<span style=3D"color: rgb(0, 0, 0); font-family: Calibri, Arial, Helvetica,=
 sans-serif; font-size: 12pt;">is a good thing IMO.</span></div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
However, as mentioned, given the late stage of standardization, I merely wa=
nted to</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
have this point raised and perhaps discussed, but didn't expect a change in=
 the end.</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
Unfortunately, there doesn't seem to be much interest in this, so I think o=
ne can put this</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
to the records.</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
Cheers,</div>
<div style=3D"font-family: Calibri, Arial, Helvetica, sans-serif; font-size=
: 12pt; color: rgb(0, 0, 0);">
Hanno</div>
<div id=3D"appendonsend"></div>
<hr style=3D"display:inline-block;width:98%" tabindex=3D"-1">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font face=3D"Calibri, sans-serif" st=
yle=3D"font-size:11pt" color=3D"#000000"><b>From:</b> TLS &lt;tls-bounces@i=
etf.org&gt; on behalf of Christopher Wood &lt;caw@heapingbits.net&gt;<br>
<b>Sent:</b> Thursday, April 23, 2020 12:34 AM<br>
<b>To:</b> TLS@ietf.org &lt;tls@ietf.org&gt;<br>
<b>Subject:</b> Re: [TLS] On the two types of ACKs in DTLS 1.3</font>
<div>&nbsp;</div>
</div>
<div class=3D"BodyFragment"><font size=3D"2"><span style=3D"font-size:11pt;=
">
<div class=3D"PlainText">Hi Hanno,<br>
<br>
I believe this (now merged) PR addresses your concerns:<br>
<br>
&nbsp;&nbsp; <a href=3D"https://github.com/tlswg/dtls13-spec/pull/140">http=
s://github.com/tlswg/dtls13-spec/pull/140</a><br>
<br>
Best,<br>
Chris<br>
<br>
On Fri, Apr 3, 2020, at 5:08 AM, Hanno Becker wrote:<br>
&gt;&nbsp; Hi all,<br>
&gt; <br>
&gt; I am aware that we're late into the standardization of DTLS 1.3, and<b=
r>
&gt; likely too late for any intrusive change, but I'd still like to share<=
br>
&gt; another comment on the proposed ACKing scheme and its implication on<b=
r>
&gt; complexity of migration from DTLS 1.2 to DTLS 1.3, in addition to the<=
br>
&gt; aspect discussed earlier regarding handshake-level vs. record-level AC=
Ks<br>
&gt; (<a href=3D"https://mailarchive.ietf.org/arch/msg/tls/O0pghTnz_8q1AiHS=
eMSzxZg30RM/">https://mailarchive.ietf.org/arch/msg/tls/O0pghTnz_8q1AiHSeMS=
zxZg30RM/</a>)<br>
&gt; <br>
&gt; As it stands, there are two quite different kinds of ACKs sharing<br>
&gt; the same wire-format:<br>
&gt; <br>
&gt; 1. ACKs as 'retransmission requests'<br>
&gt; <br>
&gt;&nbsp; Consider the following two excerpts from the draft:<br>
&gt; <br>
&gt;&nbsp; A:<br>
&gt;&nbsp; &quot;When an implementation receives a partial flight, it SHOUL=
D generate<br>
&gt;&nbsp; an ACK that covers the messages from that flight which it has<br=
>
&gt;&nbsp; received so far.&quot;<br>
&gt; <br>
&gt;&nbsp; B:<br>
&gt;&nbsp; &quot;Upon receipt<br>
&gt;&nbsp; of an ACK for only some messages from a flight, an implementatio=
n<br>
&gt;&nbsp; SHOULD retransmit the remaining messages or fragments.&quot;<br>
&gt; <br>
&gt;&nbsp; This means that ACKs should be sent only on signs of disruption,=
<br>
&gt;&nbsp; and that receivers of partial ACKs are supposed to immediately<b=
r>
&gt;&nbsp; retransmit.<br>
&gt; <br>
&gt;&nbsp; In particular, this precludes recurring use of ACKs where an ACK=
<br>
&gt;&nbsp; is generated for each message as it comes in and is processed:<b=
r>
&gt;&nbsp; Indeed, implementations behaving this way would trigger multiple=
<br>
&gt;&nbsp; retransmissions on the peer, provided the peer obeys (B), even<b=
r>
&gt;&nbsp; if there's not a single packet-loss or reordering occurring.<br>
&gt; <br>
&gt;&nbsp; In this sense, the above ACKs are 'negative' and should not be<b=
r>
&gt;&nbsp; seen at all during a disruption-free handshake.<br>
&gt; <br>
&gt;&nbsp; Note, also, that handshakes will continue to progress if this<br=
>
&gt;&nbsp; kind of ACKs is entirely ignored, which amounts to falling back<=
br>
&gt;&nbsp; to how DTLS 1.2 handles retransmissions, purely on the basis<br>
&gt;&nbsp; of timeouts and implicit acknowledgement.<br>
&gt; <br>
&gt; 2. ACKs as 'acknowledgement of completion'<br>
&gt; <br>
&gt;&nbsp; In contrast to the previous kind of ACK, those ACKs are 'positiv=
e'<br>
&gt;&nbsp; in that they indicate completion of a handshake, and they are<br=
>
&gt;&nbsp; mandatory in that a handshake will not complete unless they are<=
br>
&gt;&nbsp; used. In particular, an implementation MUST support those kinds<=
br>
&gt;&nbsp; of ACKs.<br>
&gt; <br>
&gt; At the moment, both kinds of ACKs are handled in the same way on the w=
ire,<br>
&gt; and in order to even distinguish them an implementation has to maintai=
n<br>
&gt; accurate knowledge of the sequence numbers of records it has sent.<br>
&gt; <br>
&gt; In particular, even if implementations decide to not make use of<br>
&gt; type-1 ACKs -- that is, retransmission requests -- it doesn't buy<br>
&gt; them anything in terms of code-size and simplicity, because they<br>
&gt; still have to implement type-2 ACKs, and detecting those requires<br>
&gt; implementing record sequence number bookkeeping.<br>
&gt; <br>
&gt; I believe that this will harden migration of DTLS 1.2 stacks to DTLS 1=
.3,<br>
&gt; because it makes the minimal difference between a compliant DTLS 1.3<b=
r>
&gt; implementation and a pair of &quot;DTLS 1.2 &#43; TLS 1.3 logic&quot; =
quite large.<br>
&gt; <br>
&gt; In contrast, if retransmission requests and completion-ACKs were treat=
ed<br>
&gt; differently, and in particular easily distinguishable on the wire, the=
n<br>
&gt; migration from a pair of DTLS 1.2 &#43; TLS 1.3 stack to a minimal com=
pliant<br>
&gt; DTLS 1.3 would only require implementing 'completion-ACKs', which, sin=
ce<br>
&gt; they convey only a single bit of information, can in principle have a<=
br>
&gt; much simpler wire-format than what we have for ACKs today.<br>
&gt; <br>
&gt; I would be interested in comments from implementors, esp. for stacks<b=
r>
&gt; targeting embedded / constrained environments.<br>
&gt; <br>
&gt; Cheers,<br>
&gt; Hanno<br>
&gt; <br>
&gt;&nbsp; IMPORTANT NOTICE: The contents of this email and any attachments=
 are <br>
&gt; confidential and may also be privileged. If you are not the intended <=
br>
&gt; recipient, please notify the sender immediately and do not disclose th=
e <br>
&gt; contents to any other person, use it for any purpose, or store or copy=
 <br>
&gt; the information in any medium. Thank you. <br>
&gt; _______________________________________________<br>
&gt; TLS mailing list<br>
&gt; TLS@ietf.org<br>
&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/tls">https://www.ietf=
.org/mailman/listinfo/tls</a><br>
&gt;<br>
<br>
_______________________________________________<br>
TLS mailing list<br>
TLS@ietf.org<br>
<a href=3D"https://www.ietf.org/mailman/listinfo/tls">https://www.ietf.org/=
mailman/listinfo/tls</a><br>
</div>
</span></font></div>
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose,
 or store or copy the information in any medium. Thank you.
</body>
</html>

--_000_AM6PR08MB33181AE7A270DBF7AF08BD789BD30AM6PR08MB3318eurp_--