Re: Key updates

Martin Thomson <martin.thomson@gmail.com> Mon, 06 August 2018 09:31 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63BE3130E77 for <quic@ietfa.amsl.com>; Mon, 6 Aug 2018 02:31:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qW9eHTuWRxd for <quic@ietfa.amsl.com>; Mon, 6 Aug 2018 02:31:29 -0700 (PDT)
Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 538A9128C65 for <quic@ietf.org>; Mon, 6 Aug 2018 02:31:29 -0700 (PDT)
Received: by mail-oi0-x236.google.com with SMTP id j205-v6so21011936oib.4 for <quic@ietf.org>; Mon, 06 Aug 2018 02:31:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i8szRashV7AyCBjzHEDCm8ylKChRB6yUc3QJQ5IXJLA=; b=iO3fjrRCAA9Nq4xSv7HnY/vGQ604dFvi/JX9GPb1+yCgVT2EjkNEUaphyyCFxBq55K SQf3vqUcMal7Ra+MtBDsJmjeQqJNXyHvpIjqnhpENdi/qHRH3sb8EpvkQa3f7ej2aiD/ VTV5nfxEcYMXLzHAPulx6Hbz/B7JDBsB06sHqylChB4KcsyAHq0BzKsTJ1HmbqCBj2OP gwzVHeIIBzkxhx0crPjkym4c/bJfYJlLGI9uUAqcrdvZjro8JbIIzMXL55qBa15GtCUx cLFskiVMPD80F/di1ZbPDIbPh5P1zdYVbFbsdDj/2bqwJcWWoPUoLtf4YXHYfI09Ic9l Ce5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=i8szRashV7AyCBjzHEDCm8ylKChRB6yUc3QJQ5IXJLA=; b=dYrL52ZoAayWcqKhoYDgggP/HJP3rPxYo1Sj80YwwnxveFAXP6fpxtgM4BnzEHHvEo JvD1XaypOUbhDmXvppZnFkBiOTZ/pUB1SM/4+qxt/Fiy3uFMAUbJL/bHWbNCf+9JwgKd 7iEWtpwTPAi2lgDqi7DtJzRVg4oLIoBWso+0QBxYiU9JQTTVdLHju2TS8e48SHfRR36d sPKUhA4RF+XvksrXN/7hbkuigA5SBI7vM6BVtkVkmU8ZeCfwUBAEo0biAuNNWIarCy6h irWLGySNu+eDOYXeQ6GnerqS2n9EPNFUhc7WBRzpttoQLcKPL37Zw2CUlPFurUqZn2MS TrRg==
X-Gm-Message-State: AOUpUlHSiA4xSexkZ2s0M/XRYAU+EBDSp0iRtiGQK5ObrY6BCntzTXNr 6rtpRQrpeOtDDFTl1Fno+gqueMKKRy3Mn+c2vNU=
X-Google-Smtp-Source: AAOMgpdNkGku9Jj/XD15qq3WIaa0pPreAyZU/O8hmDHDDpsXLtWE7vq8hiHEwczRD0ZqjBPyBBWMag3mBbnOyBZGwLs=
X-Received: by 2002:aca:4e50:: with SMTP id c77-v6mr12646562oib.254.1533547888398; Mon, 06 Aug 2018 02:31:28 -0700 (PDT)
MIME-Version: 1.0
References: <CABkgnnW9-Jn1CH0rSwbtDmMrOZ+jstugVsOpWtShDJgT_KSyOw@mail.gmail.com> <CAN1APddA3f3t76aoW3Z06ng-5usadf5u9qeqnWT0hRxv6SqH2Q@mail.gmail.com>
In-Reply-To: <CAN1APddA3f3t76aoW3Z06ng-5usadf5u9qeqnWT0hRxv6SqH2Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 6 Aug 2018 19:31:16 +1000
Message-ID: <CABkgnnWQRqum83WXE0+wO5=f2x5dY9E0J14R=vb3rCtH7_+J=g@mail.gmail.com>
Subject: Re: Key updates
To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000002257ae0572c0f1b0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/IlkQivYxbsh4geHVW5Me3f4gf80>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Aug 2018 09:31:32 -0000

On Mon, 6 Aug. 2018, 19:22 Mikkel Fahnøe Jørgensen, <mikkelfj@gmail.com>
wrote:

> On the last part: using a longer packet number - that would create an
> observable signal similar to an unencrypted key-phase bit because many
> packets would tend to have similar sizes, then suddenly spike a few bytes
> in length.
>

The size of a packet number is hidden. Given that most packets are full
sized, the only effect on those would be less available space for payload.
ACK packets would increase in size by a couple of octets, which could be
masked easily and cheaply if necessary.

Key phase could also be tied to connection id, and perhaps some
> consideration should be given to a possible multi-path design before opting
> for the more complex solution.
>

This is definitely an option I have considered. If you have a workable
design, I would be interested. I couldn't reconcile the desired rates of
updates. Connection IDs are needed in spikes, where the rate for key
updates is more measured.

As I understand it, the commit option still requires synchronised key
> updates in both directions. How about one-sided key updates?
>

The option I describe doesn't require that both sides update at the same
time, not do endpoints need to update in lock-step (they can require
reciprocal updates, but that is discretionary).


> On 6 August 2018 at 07.56.18, Martin Thomson (martin.thomson@gmail.com)
> wrote:
>
> One of the open items out of the design team work was the interaction
> between TLS and key updates. As you might know, TLS key updates are
> synchronous, which works well in TCP, but less well in QUIC, where you
> need at least two active keys for reception around a key change.
>
> As it is, I think that there are two serious options:
>
> 1. Use KEY_PHASE to signal a change. This requires that both
> endpoints are loosely synchronized, which disadvantages asymmetric
> data exchanges.
>
> 2. Use a prepare-commit style. DTLS does this by having each peer
> send a KeyUpdate message, then requiring that to be acknowledged
> before they can switch to the new epoch. QUIC could do the same. The
> change is still signaled in the key phase bit, but only after this
> signaling exchange.
>
> The weakness of the first option is that packets marked with a change
> of key phase trigger trial decryption. And it requires synchronized
> changes, where if one endpoint moves to epoch N (epoch == encryption
> level with fewer characters to type), then the other has to follow
> before either can move to epoch N+1. The second has more moving
> parts, but avoids both of these problems.
>
> I tend to think that the second is a better design on balance, if only
> to dispense with the trial decryption, which we've managed to avoid in
> every other case thus far. The complication might also present some
> opportunities, which I will explain below, but that's a secondary
> concern.
>
> If we want to use this signaling method, we need to decide who drives
> key updating, TLS or QUIC:
>
> TLS: The DTLS design might work in QUIC, but with the KeyUpdate
> message hidden in an opaque CRYPTO frame, it could be a little tricky
> to manage properly. If we let TLS drive the key update, then it will
> send a KeyUpdate message in a CRYPTO frame and inform QUIC of the
> change in sending keys. From here, QUIC can keep using old keys until
> all CRYPTO frames from that epoch are acknowledged. The receiver will
> inform QUIC of new receive keys when it receives KeyUpdate, which can
> be installed.
>
> QUIC: Here we define a new frame type (KEY_UPDATE, say) that QUIC
> sends when it wants to update keys. When this is acknowledged, new
> keys can be installed and used for sending. A new API is needed to
> TLS to support cranking the key schedule forward. Invoking that API
> would lead to TLS signaling the availability of new keys. The receive
> side isn't any different from the TLS option. If this was to have
> parity with TLS, this would probably need to be two frame types so
> that a unilateral update could be distinguished from an update that
> includes a request for a mutual update.
>
> In both cases, QUIC will install new receive keys, but retain old
> receive keys so that it can deal with reordering. A few round trips,
> an RTO, 2MSL, or whatever we decide for the handshake is probably
> fine. Sending keys can be discarded immediately.
>
> The advantage of having TLS drive is that it uses the same machinery
> we have for the handshake. And there is no disparity between what TLS
> and QUIC understand to be current: when TLS wants to send something (a
> NewSessionTicket message for example), then it asks for an epoch that
> matches what QUIC is using.
>
> The disadvantage of using TLS is that there are more moving parts
> involved. It fits the rules we have for the handshake neatly: for
> instance, the CRYPTO frame would be retransmitted using the strict
> encryption-level rules, reusing that code from the handshake. But
> those rules aren't really necessary given that the rules for a
> KEY_UPDATE easily have the same effect.
>
> My inclination here is to have TLS drive this. The additional
> complexity seems to be manageable in the sense that it uses mechanisms
> that should already exist for the handshake. I also don't think that
> a new API for this feature is a good way to ensure that it is used.
>
> Those who are implementing, I know that key updates are often a long
> way down the list of priorities, but has anyone spent time considering
> the options here? (I personally implemented key updates for TLS, but
> I still haven't managed to find time to do it for DTLS, which might
> say something...)
>
> --
> Addendum: Optional Key Phase ?
>
> One of the nice things about either prepare-commit design is that it
> opens a new option for how we use bits in headers. If there is a
> concern about spending a bit on every packet for the key phase (a
> whole bit!), we could design an encoding that only included the key
> phase if a longer packet number encoding was in use.
>
> The idea would be that you could use the longer packet number encoding
> while you have a key update outstanding, so that the key phase was
> available for the entirety of the changeover. Once packets with the
> new epoch were acknowledged, you could switch back to a shorter
> encoding that didn't include a key phase. The receiver would switch
> to expecting the new epoch after receiving the first packet in the new
> epoch.
>
> That's a saving that might allow endpoints to use the shortest packet
> number encoding in more cases. Of course, the header design is
> already complex enough, so maybe we don't actually *want* more options
> to consider there :)
>
>