[TLS] draft-sheffer-tls-pqc-continuity-02: four comments on the client cache rules
Nazmus Salehin Sammo <[email protected]> Sun, 2 Aug 2026 04:43:06 +0000
| Newsgroups | gmane.ietf.tls |
|---|---|
| Message-ID | <SEZPR02MB7994150469B3D1468943F4C7A1D62@SEZPR02MB7994.apcprd02.prod.outlook.com> |
--===============1605327875371246123==
Content-Language: en-AU
Content-Type: multipart/alternative;
boundary="_000_SEZPR02MB7994150469B3D1468943F4C7A1D62SEZPR02MB7994apcp_"
--_000_SEZPR02MB7994150469B3D1468943F4C7A1D62SEZPR02MB7994apcp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Hi all,
I have been doing a formal analysis of the PQ authentication negotiation
drafts as part of an MRes, and I have read
draft-sheffer-tls-pqc-continuity-02 in full. Four comments on the
client-side cache rules. All four are filed on the draft's tracker with
the detail and the suggested text. I am summarising them here for the
record, rather than starting four threads.
1. Resumption is not addressed. [1]
Enforcement is anchored entirely on the server Certificate message
(S3.2: "apply its PQC policy to every CertificateEntry in the
server's Certificate message"). Per RFC 8446 S4.4.2 the server sends
Certificate for every key exchange method "except PSK", and S2.2 says
directly that on resumption the server "does not send a Certificate
or a CertificateVerify message". So on a resumed handshake that
obligation applies to an empty set. It is satisfied with nothing to
check, the MUST-abort cannot fire, and the commitment is never
consulted. Confirmed on OpenSSL 3.6.2 with a genuine ML-DSA-65 chain:
the resumed handshake completed (Reused, TLSv1.3) with 0 Certificate
and 0 CertificateVerify messages. The draft has no occurrence of
resumption, PSK, ticket or 0-RTT.
RFC 8672 S2, covering the same TLS-layer pinning pattern, handled
this explicitly: "As a result, PSK handshakes MUST NOT include the
extension defined here." That reasoning rested on the misissuance
threat model and does not carry over unchanged to the undisclosed
CRQC attacker of S1, but it is a ready precedent. Exploitation is
bounded by the 7-day ticket cap in RFC 8446 S4.6.1. This is not a
harvest-now, decrypt-later attack and I am not claiming it is. The
specification gap stands on its own, independent of any attacker.
2. The withdrawal path lacks the condition its own rule 1 has. [2]
S3.6 rule 1 conditions caching on "after the handshake completes
successfully". Rule 2 conditions clearing only on receiving the
extension. The suggested fix is one clause, copied from rule 1.
Two things to be clear about. First, the condition is not new:
RFC 6797 S8.1 has gated all HSTS state change, including the
max-age=3D0 removal, on a clean secure transport since 2012, and
RFC 7469 S2.3.1 does the same for pin deletion. Since S1 says this
extension is modelled on HSTS, the honest description is that the
normative text did not restate a condition the stated model already
has. Second, the reference implementation already does the right
thing: it defers both the cache update and the cache delete to
SSL_CB_HANDSHAKE_DONE behind an X509_V_OK check, and says why in a
source comment. So there is no exploitable instance that I know of.
My concern is only that none of that appears in the normative text,
and a second implementer reading rule 2 literally would be conformant
without it. S4 of the draft already says the intended thing
non-normatively ("until they observe zero on a completed handshake"),
which is why I think this is editorial rather than a design change.
3. A question about the port in the cache key. [3]
S3.4 keys entries by (RFC 9525 identity, port, TLS/DTLS) and says
entries differing in any of these MUST NOT be merged, while the
server's obligation in S3.7 carries no port qualifier and the
reference identity is port-independent. So the client enforces
something narrower than the server has committed to. I am asking
rather than asserting: I do not think this is a bypass, since under
S3.4 no commitment is in force for the key that gets used, but I also
do not think it is the trust-on-first-use case S5.1 documents, since
S5.1's own justification depends on the client eventually connecting
directly, which never happens for a port it never uses. Related: S1
invokes HSTS, but RFC 6797 S8.3 says "the HSTS Policy applies to HTTP
over any TCP port of an HSTS Host", so the scoping differs from the
named model. That may be deliberate for DTLS and non-web use. If so
it would be worth saying.
Martin's IETF-126 comments on this cache key not working for
browsers, and on non-uniform multi-CDN deployment, are in the same
area. I am not claiming new ground there, only asking about the port
dimension specifically.
4. "The port" is not defined. [4]
S3.4 does not say whether "the port" is the authority port from the
URI or the TCP port actually connected to. These differ under an
HTTPS RR carrying a port SvcParam, where per RFC 9460 S9.1 the origin
does not change. The two readings give opposite answers about whether
a cached commitment applies, and that decides whether the scope
question in (3) is reachable at all. Two sentences would fix it.
None of this touches issue #23. I have Tamarin models behind (1) and
(2) and am happy to share them, with the caveat that they are models of
the S3.2, S3.5 and S3.6 client state machine, not security proofs of
TLS 1.3. The OpenSSL result behind (1) is the stronger evidence.
Thanks for the draft. Rule 3 of S3.6 and the S4 text made the first two
of these much easier to pin down than they would otherwise have been.
Nazmus Salehin Sammo
Melbourne Institute of Technology, Melbourne, Australia
Student ID: MIT252100
[email protected]
[1] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/29
[2] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/27
[3] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/28
[4] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/26
--_000_SEZPR02MB7994150469B3D1468943F4C7A1D62SEZPR02MB7994apcp_
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"=
>
</head>
<body>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi all,</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
I have been doing a formal analysis of the PQ authentication negotiation</d=
iv>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
drafts as part of an MRes, and I have read</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
draft-sheffer-tls-pqc-continuity-02 in full. Four comments on the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
client-side cache rules. All four are filed on the draft's tracker with</di=
v>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the detail and the suggested text. I am summarising them here for the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
record, rather than starting four threads.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
1. Resumption is not addressed. [1]</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Enforcement is anchored entirely on the server Certificate mes=
sage</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
(S3.2: "apply its PQC policy to every CertificateEntry in=
the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
server's Certificate message"). Per RFC 8446 S4.4.2 the s=
erver sends</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Certificate for every key exchange method "except PSK&quo=
t;, and S2.2 says</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
directly that on resumption the server "does not send a C=
ertificate</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
or a CertificateVerify message". So on a resumed handshak=
e that</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
obligation applies to an empty set. It is satisfied with nothi=
ng to</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
check, the MUST-abort cannot fire, and the commitment is never=
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
consulted. Confirmed on OpenSSL 3.6.2 with a genuine ML-DSA-65=
chain:</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the resumed handshake completed (Reused, TLSv1.3) with 0 Certi=
ficate</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
and 0 CertificateVerify messages. The draft has no occurrence =
of</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
resumption, PSK, ticket or 0-RTT.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
RFC 8672 S2, covering the same TLS-layer pinning pattern, hand=
led</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
this explicitly: "As a result, PSK handshakes MUST NOT in=
clude the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
extension defined here." That reasoning rested on the mis=
issuance</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
threat model and does not carry over unchanged to the undisclo=
sed</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
CRQC attacker of S1, but it is a ready precedent. Exploitation=
is</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
bounded by the 7-day ticket cap in RFC 8446 S4.6.1. This is no=
t a</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
harvest-now, decrypt-later attack and I am not claiming it is.=
The</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
specification gap stands on its own, independent of any attack=
er.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
2. The withdrawal path lacks the condition its own rule 1 has. [2]</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
S3.6 rule 1 conditions caching on "after the handshake co=
mpletes</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
successfully". Rule 2 conditions clearing only on receivi=
ng the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
extension. The suggested fix is one clause, copied from rule 1=
.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Two things to be clear about. First, the condition is not new:=
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
RFC 6797 S8.1 has gated all HSTS state change, including the</=
div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
max-age=3D0 removal, on a clean secure transport since 2012, a=
nd</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
RFC 7469 S2.3.1 does the same for pin deletion. Since S1 says =
this</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
extension is modelled on HSTS, the honest description is that =
the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
normative text did not restate a condition the stated model al=
ready</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
has. Second, the reference implementation already does the rig=
ht</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
thing: it defers both the cache update and the cache delete to=
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
SSL_CB_HANDSHAKE_DONE behind an X509_V_OK check, and says why =
in a</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
source comment. So there is no exploitable instance that I kno=
w of.</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
My concern is only that none of that appears in the normative =
text,</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
and a second implementer reading rule 2 literally would be con=
formant</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
without it. S4 of the draft already says the intended thing</d=
iv>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
non-normatively ("until they observe zero on a completed =
handshake"),</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
which is why I think this is editorial rather than a design ch=
ange.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
3. A question about the port in the cache key. [3]</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
S3.4 keys entries by (RFC 9525 identity, port, TLS/DTLS) and s=
ays</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
entries differing in any of these MUST NOT be merged, while th=
e</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
server's obligation in S3.7 carries no port qualifier and the<=
/div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
reference identity is port-independent. So the client enforces=
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
something narrower than the server has committed to. I am aski=
ng</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
rather than asserting: I do not think this is a bypass, since =
under</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
S3.4 no commitment is in force for the key that gets used, but=
I also</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
do not think it is the trust-on-first-use case S5.1 documents,=
since</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
S5.1's own justification depends on the client eventually conn=
ecting</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
directly, which never happens for a port it never uses. Relate=
d: S1</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
invokes HSTS, but RFC 6797 S8.3 says "the HSTS Policy app=
lies to HTTP</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
over any TCP port of an HSTS Host", so the scoping differ=
s from the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
named model. That may be deliberate for DTLS and non-web use. =
If so</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
it would be worth saying.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Martin's IETF-126 comments on this cache key not working for</=
div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
browsers, and on non-uniform multi-CDN deployment, are in the =
same</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
area. I am not claiming new ground there, only asking about th=
e port</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
dimension specifically.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
4. "The port" is not defined. [4]</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
S3.4 does not say whether "the port" is the authorit=
y port from the</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
URI or the TCP port actually connected to. These differ under =
an</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
HTTPS RR carrying a port SvcParam, where per RFC 9460 S9.1 the=
origin</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
does not change. The two readings give opposite answers about =
whether</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
a cached commitment applies, and that decides whether the scop=
e</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
question in (3) is reachable at all. Two sentences would fix i=
t.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
None of this touches issue #23. I have Tamarin models behind (1) and</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
(2) and am happy to share them, with the caveat that they are models of</di=
v>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
the S3.2, S3.5 and S3.6 client state machine, not security proofs of</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
TLS 1.3. The OpenSSL result behind (1) is the stronger evidence.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Thanks for the draft. Rule 3 of S3.6 and the S4 text made the first two</di=
v>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
of these much easier to pin down than they would otherwise have been.</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Nazmus Salehin Sammo</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Melbourne Institute of Technology, Melbourne, Australia</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Student ID: MIT252100</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[email protected]</div>
<div style=3D"direction: ltr; text-align: justify; font-family: Aptos, Aria=
l, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[1] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/29</d=
iv>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[2] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/27</d=
iv>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[3] https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/28</d=
iv>
<div style=3D"text-align: justify; font-family: Aptos, Arial, Helvetica, sa=
ns-serif; font-size: 12pt; color: rgb(0, 0, 0);">
[4] <a href=3D"https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/i=
ssues/26" data-outlook-id=3D"e3302138-653d-45d0-b4b5-e310f5596ce0">
https://github.com/yaronf/draft-sheffer-tls-pqc-continuity/issues/26</a></d=
iv>
<div id=3D"ms-outlook-mobile-signature" dir=3D"ltr" style=3D"color: inherit=
; background-color: inherit;">
</div>
</body>
</html>
--_000_SEZPR02MB7994150469B3D1468943F4C7A1D62SEZPR02MB7994apcp_--
--===============1605327875371246123==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KVExTIG1haWxp
bmcgbGlzdCAtLSB0bHNAaWV0Zi5vcmcKVG8gdW5zdWJzY3JpYmUgc2VuZCBhbiBlbWFpbCB0byB0
bHMtbGVhdmVAaWV0Zi5vcmcK
--===============1605327875371246123==--