Re: Key updates

Kazuho Oku <kazuhooku@gmail.com> Tue, 07 August 2018 06:10 UTC

Return-Path: <kazuhooku@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 A537E130E72 for <quic@ietfa.amsl.com>; Mon, 6 Aug 2018 23:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 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, 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 ttQEvKsah-Sd for <quic@ietfa.amsl.com>; Mon, 6 Aug 2018 23:10:44 -0700 (PDT)
Received: from mail-lj1-x234.google.com (mail-lj1-x234.google.com [IPv6:2a00:1450:4864:20::234]) (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 8A78F130E5C for <quic@ietf.org>; Mon, 6 Aug 2018 23:10:44 -0700 (PDT)
Received: by mail-lj1-x234.google.com with SMTP id f8-v6so12475146ljk.1 for <quic@ietf.org>; Mon, 06 Aug 2018 23:10:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XjfKyhrujdi4Z0sRYorImjL3v29d5x2jDwjrKu0KcNU=; b=YC5aKfrG1cQHI+DE0p+3WK34eVv/EFveCpVh5yHutB1bbUgVKrKYgviu+vAmjiFuNI FmtJtz07vJC7BMmV40cRTYIRepnjnMjzPBge+vg8cVwmt1n1dCmm8ydRZ5/UirxIXGBd 6JPuE+dqSj6W7WVM5G2GWVViUl0A9edVCSMNAIN++EqhBPnGx1r2KVEdixD/CcM8unVW idU0pqmT7hZ+VFute+JzR081NM0qNAyXe4szcqNdIawFhgvFjwfxIfFXCxzpE0Xwvgyq CR8WCTbFfLkBC3qgfCMPt0KMUUvEbORFP4FD3tEf7XhPYiAj2hxJOOMdaTDexRpkuPwO lgmg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XjfKyhrujdi4Z0sRYorImjL3v29d5x2jDwjrKu0KcNU=; b=aDw5ZlnfLsIRDRRk7YD7z5w9wd4g4p+TOpRVHUkLbcFVGzbQibcpIwr4LG0Eso7/Ae 5VCPwkLfaSSDWU3VAyilDW4edPsKCnL14yKoqQsSfNUrbt4FcUArrf8Wi/CCBsn7Kpbo o4vQJdahneuZHOigYubGf1ffo9tphnkEpbUJRQMeJhA2dnu/0xiparCe0oz55ymyTCxK szLmEs9dRPkre7cZuDHu/Hij9aqDS8VgekvZaVMsLpB7EQzSWwJhW5FKZwSu7PExMK7j 9mK0pzy6vFMioPvAktTu3cDwrlPkKLxq0zTfTbNIe1kLz6ChuJd6pVQmnLOnbYqCTbFn jlaQ==
X-Gm-Message-State: AOUpUlF76RiI+n40olHh1lEIjFKiGV0eRgZDKP1zhJwUdhyEHfzuibwo 0FnDoHEVh66F6be1z7hgD1HukPkAaqVYbc04sVU=
X-Google-Smtp-Source: AAOMgpcoU837dTfOat9DCdzYs8Kf0to6uaIFFVuPQ6hf8Wf3s9Bek7+GjMqWmsxMZLqJOFXraDqz4iqZ57g/AAqt57U=
X-Received: by 2002:a2e:9e55:: with SMTP id g21-v6mr15423503ljk.116.1533622242843; Mon, 06 Aug 2018 23:10:42 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a2e:8996:0:0:0:0:0 with HTTP; Mon, 6 Aug 2018 23:10:42 -0700 (PDT)
In-Reply-To: <CABkgnnWFKLN7obL9H0+ayJDSAmR_Xzk2Yxaj6y92fEJEzD=URQ@mail.gmail.com>
References: <CABkgnnW9-Jn1CH0rSwbtDmMrOZ+jstugVsOpWtShDJgT_KSyOw@mail.gmail.com> <CANatvzxJVMUrCW+28FAFC21-Yg_7g0ayaGMfpyaMyztosaAVjg@mail.gmail.com> <CABkgnnWFKLN7obL9H0+ayJDSAmR_Xzk2Yxaj6y92fEJEzD=URQ@mail.gmail.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Tue, 7 Aug 2018 15:10:42 +0900
Message-ID: <CANatvzz4rC2BUK7xKeUQrHVJzXxzCnp4uXNFEargmkNcz82dLg@mail.gmail.com>
Subject: Re: Key updates
To: Martin Thomson <martin.thomson@gmail.com>
Cc: QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/QFuinzRDiuUFUeY2ao2jbtEb8kg>
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: Tue, 07 Aug 2018 06:10:47 -0000

2018-08-07 14:15 GMT+09:00 Martin Thomson <martin.thomson@gmail.com>om>:
> On Tue, Aug 7, 2018 at 2:55 PM Kazuho Oku <kazuhooku@gmail.com> wrote:
>> I do not think that the current mechanism requires trial decryption.
>> IIUC, the endpoints are not allowed to start sending packets at epoch
>> N+1 until they see peers acknowledging packets that were sent in epoch
>> N. That means that an endpoint only needs to have at most 2 keys (for
>> epoch N+1 and N). The epoch (either N or N+1) can be recovered from
>> the KEY_PHASE bit and there is no need for trial decryption.
>>
>> Am I missing something?
>
> There is a problem right now with concurrent updates.  If both peers
> bump at the same time, then N-1 packets could still be in flight.

I think that we might be having different models in our minds.

My view is that, in principle, an endpoint unilaterally updates its
epoch that it uses for "sending" packets. An endpoint MUST NOT update
the send epoch before it sees an acknowledgement for a packet that was
sent encrypting using the current epoch.

To implement reciprocal key update, we will also state that, if the
send epoch used by the peer becomes greater than the value used by an
endpoint, then the endpoint SHOULD increment it's send epoch as well.

If we define the rules this way, I would assume that there is not
chance of key getting updated twice even in case both the peers decide
to update at the same moment.

To put it another way, the issue with the reciprocal (D)TLS-style key
update is that it is defined as a "request" rather than a state change
with idempotency. The rules above is designed as an idempotent state
change from N to N+1 that can be implemented by either peer without
the fear of double update that will lead to potential loss (unless the
endpoints retains more than two keys).

> A
> little reordering will cause them to be interpreted as N+1 instead
> (because they arrive after packets at N and we only have one bit of
> signal).
>
> So if you want to avoid loss spikes around rekeying, you have to do a
> little trial decryption at that point.
>
> Also, the way you ratchet forward is to observe a bit flip, at which
> point you decrypt with N+1.  If that works, then you do something.
> It's not quite trial decryption in the sense that you only try one
> key, but - having implemented it - it's a little annoying to get
> right.
>
>
>> I am not sure if adding a way to signal the receipt of ACK for a
>> particular TLS message from QUIC to TLS stack is worth the cost. We do
>> not have that kind of mechanism. I am scared that such mechanism could
>> become very complex, considering the fact that the QUIC stack can
>> split TLS handshake in any way that it would like.
>>
>> Or are you suggesting a mechanism other than what is defined in DTLS?
>
> It's pretty close that in DTLS.  Here's what I imagined would work:
>
> You let TLS send its KeyUpdate, which gets bundled into a CRYPTO
> frame.  TLS moves to the new epoch, and advertises the availability of
> new keys.  However, you continue to send in the old epoch until you
> have flushed all pending CRYPTO data from the old epoch (i.e., the
> CRYPTO frame has all been acknowledged).

Thank you for the explanation.

I think that the described algorithm will work fine, but I am not sure
if I like the fact that it requires the QUIC stack to remember the new
encryption key and the fact that a KeyUpdate message has been sent in
a CRYPTO frame at certain offset, and switch to the new key when all
the data up to that offset is acknowledged.

In my view, the design is breaking the layer between the contents
CRYPTO and the QUIC stack (QUIC stack needs to know what is carried in
CRYPTO), and is also requiring the QUIC stack to handle the CRYPTO
frames other than a conveyer of stream of data (by requiring to do
specific action at specific offsets).

> All other processing stays
> the same: CRYPTO frames are always sent using the same keys, even on
> retransmission, new TLS messages would be sent in the new epoch, and
> ACK frames would need to send using the epoch of the packets they
> acknowledge.
>
> The reason we don't have problems with the handshake is that we *know*
> that the peer has keys for the new epoch.  Otherwise we would have to
> do the same thing.  There, following these rules would mean sending in
> the clear, which isn't smart.  Here, it's just a key update.



-- 
Kazuho Oku