User-Agent: Cyrus-JMAP/3.3.0-dev0-525-ge8fa799-fm-20200609.001-ge8fa7990
Mime-Version: 1.0
Message-Id: <04a71698-968d-436b-9940-29afc9fea37d@www.fastmail.com>
In-Reply-To: <CACsn0c=+P4vRpOHw-MD4NxU5nVPKORBHoNPYnxxtk=fk0OCGiA@mail.gmail.com>
References: <CACsn0c=+P4vRpOHw-MD4NxU5nVPKORBHoNPYnxxtk=fk0OCGiA@mail.gmail.com>
Date: Mon, 15 Jun 2020 09:37:23 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Why not exporters?
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZVOfoKoPCurIxDZi0owOxOQa4Iw>
Precedence: list

On Mon, Jun 15, 2020, at 06:24, Watson Ladd wrote:
> I'm afraid I missed the discussion of using exporters in the TLS QUIC
> draft. Exporters would assure the domain separation from TLS, and have
> an IANA registry to maintain that separation across versions. There
> doesn't seem to be a good reason not to do it.

Hi Watson,

We used exporters in an earlier version of the specification.  Indeed, the introduction of the early exporter in TLS 1.3 was - at least in part - in support of providing exporter keys that QUIC could use for 0-RTT.

However, when we moved to more closely following the TLS key schedule for packet protection, we decided to use TLS secrets rather than define a Handshake key exporter.  In the current design, those secrets are not used by TLS.

Domain separation is now achieved at the leaf. Until key updates occur, QUIC packet protection keys are derived from the same secrets that TLS uses for record protection, but the labels used for deriving the individual values (key, iv, hp) use a different label.  This ensures that keys cannot be synchronized.  That is in addition to the handshake being different due to containing a QUIC-specific extension and the guarantee provided by TLS that different connections have different keys. It's not as good as a clean separation might be, but there are several layers of defense.

Hope that helps,