[quicwg/base-drafts] client's Handshake write key needs to be exported early (#2328)

Marten Seemann <notifications@github.com> Thu, 10 January 2019 02:47 UTC

Date: Wed, 09 Jan 2019 18:47:00 -0800
From: Marten Seemann <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab206bef1e6d1dfa4c06698876b747a0e97ceb616292cf00000001184e742492a169ce17b3a6da@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2328@github.com>
Subject: [quicwg/base-drafts] client's Handshake write key needs to be exported early (#2328)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c36b224d8dcd_44b93fceb72d45b87156c"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/nljh-xZYMuoT-3abQie_B0B57yI>

In order for the client to be able to acknowledge packets sent with Handshake encryption level, it needs to have access to the Handshake write key right after processing the ServerHello.

https://tools.ietf.org/html/rfc8446#appendix-A.1 states that the Handshake write key is exported after receiving the server's Finished message, which would make loss recovery of Handshake packets impossible.

I found this fact non-obvious, and I think it should be documented in some way that we're deviating from the schedule in which a normal TLS 1.3 implementation would make new keys available.

-- 
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/2328

[quicwg/base-drafts] client's Handshake write key… Marten Seemann
Re: [quicwg/base-drafts] client's Handshake write… Martin Thomson
Re: [quicwg/base-drafts] client's Handshake write… Martin Thomson