Re: [quicwg/base-drafts] Rework Key Update (#2237)

Kazuho Oku <notifications@github.com> Wed, 26 December 2018 20:14 UTC

Return-Path: <noreply@github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3993F1312D9 for <quic-issues@ietfa.amsl.com>; Wed, 26 Dec 2018 12:14:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.065
X-Spam-Level:
X-Spam-Status: No, score=-8.065 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.065, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.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 qIGlyyz3kpS6 for <quic-issues@ietfa.amsl.com>; Wed, 26 Dec 2018 12:14:48 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0120D1312D8 for <quic-issues@ietf.org>; Wed, 26 Dec 2018 12:14:47 -0800 (PST)
Date: Wed, 26 Dec 2018 12:14:46 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1545855286; bh=/V3me87LBRerGpJR0HnRiMxGCwXYfyYb1He3IKyXUhA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Ki489TjkRvpNVddgDZO+6IuxGpJVSo6yRDWRPqlf0IUqprR97CnGkV90zztchagxN vp4xCCLMFAVDFWCzHFge1pfYP0C+mdmvBUGC//kxiLFupbcSv6rNK/lqa1kbgyTc0P UVwlork01KDKz4oTap3rjYPw5f4rN9grnjSr9wWA=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab67cd00bac93018c3bca478b58993b730679d4e4492cf00000001183ba33692a169ce1770e975@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2237/c450019472@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2237@github.com>
References: <quicwg/base-drafts/pull/2237@github.com>
Subject: Re: [quicwg/base-drafts] Rework Key Update (#2237)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c23e136a7490_2ab63f89452d45c0571465"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/hp6p8WfAvPHj93Lcc3KYKdbLXEI>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Dec 2018 20:14:50 -0000

@marten-seemann We cannot enforce implementors to code correctly.

The issue with the 2-bit KEY_PHASE design is that the receiver has a code path that is very rarely being executed (retaining 3 keys at once). Some stacks might fail to implement it correctly. Or some stacks might not implement key updates correctly at all. Anyways, we might see interoperability issues in the wild, and the bug would be hard to identify, because it's rare and because it would look like an connection stalling to the end user.

"MAY_UPDATE" bit takes a different approach. We do not have a code path that is rarely taken on the receiver side. Hence less chance of having interoperability issues. A receiver that does not allow the sender to update keys can be detected, and then the sender can close the connection with a specific error code. That is much better than the connection silently breaking.

-- 
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/pull/2237#issuecomment-450019472