Date: Sun, 10 Nov 2019 20:22:35 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts
 <reply+AFTOJKY7ECHNUXFI2URNN2N32YKIXEVBNHHB6CGIZA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3212/552287760@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3212@github.com>
References: <quicwg/base-drafts/issues/3212@github.com>
Subject: Re: [quicwg/base-drafts] Remove handshake confirmed test for KeyUpdte
 (#3212)
Mime-Version: 1.0
Content-Type: multipart/alternative;
 boundary="--==_mimepart_5dc8e20be3bac_bde3fbd294cd9681653735";
 charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/CXuUso0b0I9xN9SxR8e6OECWV8k>


----==_mimepart_5dc8e20be3bac_bde3fbd294cd9681653735
Content-Type: text/plain;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

@nibanks 
> We've done performance tests with msquic and changing the key after each key update is ACK'ed and it showed absolutely no impact on throughput. As far as extra complexity it's hard to say. We implemented key update as it was spec'ed now and didn't have to make any complicated extra logic to get to this state.

I'm not sure if what you describe is following the recommendation. Quoting from the spec:
* Endpoints SHOULD wait three times the PTO before initiating a key update after receiving an acknowledgment that confirms that the previous key update was received. ([section 6.5](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.6.5))
* Endpoints SHOULD instead defer the creation of the next set of receive packet protection keys until some time after a key update completes, up to three times the PTO.  ([section 6.3](https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.6.3))

Depending on how the peer is implemented, updating the key as soon as receiving an ACK would cause packet drops.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3212#issuecomment-552287760
----==_mimepart_5dc8e20be3bac_bde3fbd294cd9681653735
Content-Type: text/html;
 charset=UTF-8
Content-Transfer-Encoding: 7bit

<p><a class="user-mention" data-hovercard-type="user" data-hovercard-url="/hovercards?user_id=20663557" data-octo-click="hovercard-link-click" data-octo-dimensions="link_type:self" href="https://github.com/nibanks">@nibanks</a></p>
<blockquote>
<p>We've done performance tests with msquic and changing the key after each key update is ACK'ed and it showed absolutely no impact on throughput. As far as extra complexity it's hard to say. We implemented key update as it was spec'ed now and didn't have to make any complicated extra logic to get to this state.</p>
</blockquote>
<p>I'm not sure if what you describe is following the recommendation. Quoting from the spec:</p>
<ul>
<li>Endpoints SHOULD wait three times the PTO before initiating a key update after receiving an acknowledgment that confirms that the previous key update was received. (<a href="https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.6.5" rel="nofollow">section 6.5</a>)</li>
<li>Endpoints SHOULD instead defer the creation of the next set of receive packet protection keys until some time after a key update completes, up to three times the PTO.  (<a href="https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#rfc.section.6.3" rel="nofollow">section 6.3</a>)</li>
</ul>
<p>Depending on how the peer is implemented, updating the key as soon as receiving an ACK would cause packet drops.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br />You are receiving this because you are subscribed to this thread.<br />Reply to this email directly, <a href="https://github.com/quicwg/base-drafts/issues/3212?email_source=notifications&amp;email_token=AFTOJK6RWQK6EASATAT2SJTQTDMYXA5CNFSM4JLOVOK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDVT4EA#issuecomment-552287760">view it on GitHub</a>, or <a href="https://github.com/notifications/unsubscribe-auth/AFTOJK55OP4ZZR5ZO7FI3E3QTDMYXANCNFSM4JLOVOKQ">unsubscribe</a>.<img src="https://github.com/notifications/beacon/AFTOJK4VYUREYPD7QCRYOE3QTDMYXA5CNFSM4JLOVOK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDVT4EA.gif" height="1" width="1" alt="" /></p>
<script type="application/ld+json">[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/quicwg/base-drafts/issues/3212?email_source=notifications\u0026email_token=AFTOJK6RWQK6EASATAT2SJTQTDMYXA5CNFSM4JLOVOK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDVT4EA#issuecomment-552287760",
"url": "https://github.com/quicwg/base-drafts/issues/3212?email_source=notifications\u0026email_token=AFTOJK6RWQK6EASATAT2SJTQTDMYXA5CNFSM4JLOVOK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDVT4EA#issuecomment-552287760",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
}
]</script>
----==_mimepart_5dc8e20be3bac_bde3fbd294cd9681653735--