Re: KEYS_READY
Kazuho Oku <kazuhooku@gmail.com> Thu, 14 February 2019 04:22 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 C12EA130F6C for <quic@ietfa.amsl.com>; Wed, 13 Feb 2019 20:22:47 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 1E0IjxgCbk_Y for <quic@ietfa.amsl.com>; Wed, 13 Feb 2019 20:22:45 -0800 (PST)
Received: from mail-lj1-x22c.google.com (mail-lj1-x22c.google.com [IPv6:2a00:1450:4864:20::22c]) (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 25591130F62 for <quic@ietf.org>; Wed, 13 Feb 2019 20:22:45 -0800 (PST)
Received: by mail-lj1-x22c.google.com with SMTP id s5-v6so3967636ljd.12 for <quic@ietf.org>; Wed, 13 Feb 2019 20:22:45 -0800 (PST)
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:content-transfer-encoding; bh=gAeCVvdpAls+5DSaYDTDAYBPHV1juzMbXnPe2/XLeKQ=; b=CyUFwwdBkuxVnC3A5zLa0zHty9R7dJkVI8lageShf4dZq8GLxwp25oQYkyyS3N1Yuu kwcNk2gtnAX1ichkR4caY9iSp+2MhFuIUvdT8m7pOuWkyTNvm+dgtCArl8QUbxuzKAW+ xn5IPPvR0ZFNnH0qjzB1EhRbX0Ak81632kE/KFXFSY9moCLmUXWUffnqf4sfNRp1PSSb mJYlmeVo59iyAASar0YWKFTxi4+JeHJwLoPiOIZ4V1DUu7Lw/pwPczT7Ynu8FjaTqoax sUqgjK7btegtjl49pRqPOR0L3knwOnseorgLbwGEHWESwgBXU+a+GPMs/7j2dugMTYsK Puqw==
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:content-transfer-encoding; bh=gAeCVvdpAls+5DSaYDTDAYBPHV1juzMbXnPe2/XLeKQ=; b=c/QADtw+ffKHJFM6vlVRJ2jqcibh6joLiJw+8kQvDISkS4L5EZhPpP2jfT8EUVU5du 5CQoO2AIqbe8EXD9ZlOFdTE19WoujCmeaqE7Jc3c19jdWL1iIdqSYmb+rF7g4PauSrS3 v4tFQG4irMozXgXeUTXvz6fVSj3XBU/Mvmcj0wnj/ktJJOTaKWcD+NZl5vY/gmDA0hUH hvuZcFDD5A99n7oIh1roLosNxUk0uo7YzJ5NdNEkv6UL6EyJV0TzqulGWpHdql1rSUMT JsCa0i5FonhiRxAaWclU449bFM5JtspFSgDIf8mRZFpo/Z4gywoo6GU16hI0OcuWH+Wp uPrA==
X-Gm-Message-State: AHQUAuaC5mrTnUlwq+n0B4oCdKQKJmfiRjRPEgrTY2TQEnEcCKbqJHOx PA30OmtlRSU015QQt6pL7iOkUzACUthQYqScLiWOlw==
X-Google-Smtp-Source: AHgI3IY89WptN5xJdNWX63U4dfCIwosKZ/DvURAJFlP0ktOFs+HPaklIU0rXtS6bum2PB1KBJ7m6Aw87il5hpfTlqA8=
X-Received: by 2002:a2e:8847:: with SMTP id z7mr851986ljj.99.1550118163223; Wed, 13 Feb 2019 20:22:43 -0800 (PST)
MIME-Version: 1.0
References: <1550022355.557617.1656828112.4DD1CEE6@webmail.messagingengine.com> <CANatvzy_juza_meGR_-KuBV9FA=F754mv54aawxMb8hYWxb1gA@mail.gmail.com> <CAN1APdcVYKWuapZ3XHxXa_nVACwkRD-xeF3ub-5ROttE7QVrmQ@mail.gmail.com> <CAOYVs2ooxAuwu_zr2XZ-y9UqUP5kTbjoFrckAOi40bF9vODGOg@mail.gmail.com> <CAKcm_gNk=jKrnXM4Ht4yF0RX25wtVifjxz0c1gay0uie7PMw6A@mail.gmail.com> <CANatvzxBYzEaDZ1Ftt=o1zT5zVcVTd1EwtGiJOC-mkrNUWzVAQ@mail.gmail.com> <CAN1APdfzepc9DE98UsWw=hB4dM38qKLxdAjpsYuddDBatcscDA@mail.gmail.com> <739AFC55-DD02-47AA-A29E-B9C34ED7D6F9@gmail.com> <CAN1APddWLdmRo+ZZDnmvrBEFQk4TTcS3UK_9AU4KqAeSkiBvJQ@mail.gmail.com> <375A63C5-7120-4688-8873-EEA90693332E@huitema.net> <CANatvzxoOFzpkcH_4VpQscpZq8ak0QL0D6REvyJVjE+ga97SVQ@mail.gmail.com> <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com>
In-Reply-To: <1550111606.3717440.1657643080.033E200B@webmail.messagingengine.com>
From: Kazuho Oku <kazuhooku@gmail.com>
Date: Thu, 14 Feb 2019 13:22:31 +0900
Message-ID: <CANatvzy_ApgnZHnVC9N2GSXR8+pzKtHYZiidDnA8gt7Xu_AU=A@mail.gmail.com>
Subject: Re: KEYS_READY
To: Martin Thomson <mt@lowentropy.net>
Cc: IETF QUIC WG <quic@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/NNOzxNWldmfiUN9avCdiQMNVXMw>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 14 Feb 2019 04:22:48 -0000
TL;DR I think that the issue with the PR is that it not only tries to address issue but it changes existing mechanism. It might make sense to consider just fixing the issues. Proposal below. I think there are two concerns regarding the PR. The PR changes how Initial keys are retired. Instead of relying on the delivery of Handshake packets, it relies on the delivery of KEYS_ACTIVE frames. However, we do not require KEY_ACTIVE frames to be included in every Handshake packet being sent. There is a risk that Initial keys might not get dropped as early as they are now. The other issue is that an endpoint might never receive a Handshake packet that carries a KEY_ACTIVE frame. This happens packet loss occurs. To accommodate that, the PR states that the delivery of KEY_ACTIVE frame in either a Handshake or a 1-RTT packet signals the disposal of the Initial packet. That's workable, but I think it shows the problem with the approach. KEY_ACTIVE frame does not name the key that is activated. That is causing the strange retransmission rules for the frame. The right approach seems to suggest endpoints to incorporate the frame in every ACK-eliciting packet it sends. This is a logic we have not had so far, and it could be difficult for certain implementations that do not know what it is sending when it starts to build a packet. Considering these two issues, I think it might be worth discussing the following straw-man: * Do not touch how Initial keys are dropped. Use the new frame just to indicate the completion of the handshake and the retirement of the previous generation of 1-RTT keys. * Include the 1-RTT key generation number in the frame, so that ordinary retransmission logic can be used. Note also that the retransmission rule does not need to be aggressive, because we do not use the frame for dropping Initial keys. When the handshake is complete, both endpoints send KEYS_ACTIVE(generation=0). That indicates the peer that the peer can drop the Handshake keys, and also that the endpoint is ready to receive a key update. Completion of key update works exactly the same way. When key update is complete, both endpoints send KEY_ACTIVE(generation=previous_generation), indicating that the peer can drop the 1-RTT keys, and that the endpoint is ready to receive another key update. Regarding the validation of the generation number, I think we can call it a MAY. 2019年2月14日(木) 11:33 Martin Thomson <mt@lowentropy.net>: > > A few different responses... > > On Wed, Feb 13, 2019, at 23:59, Marten Seemann wrote: > > I agree with Kazuho that using a bit in the first byte seems to capture the > > update logic we're looking for better. There's no need to retransmit any > > information, since the bit is set on every subsequent packet. > > I was OK with that PR, and while we might go back and forth on the merits of using a bit vs. a frame, the consensus in Tokyo was that the frame was superior. Also, this solves more problems. > > On Thu, Feb 14, 2019, at 02:48, Kazuho Oku wrote: > > IIUC key updates are rare, and therefore the frame can be non-ack- > > eliciting. FWIW, the current design does not elicit an ACK in response > > to key update. > > I used the opposite logic. Key updates are rare and therefore eliciting an acknowledgment does not cost much. It's one packet per update. The interesting thing there is that you guarantee that KEYS_ACTIVE frame is sent, so maybe the text about not sending it until you have something to send is not needed. > > On Thu, Feb 14, 2019, at 09:09, Kazuho Oku wrote: > > 2019年2月14日(木) 3:20 Christian Huitema <huitema@huitema.net>: > > > The more I look at it, the more I think that key update / key ready should be treated in much the same way as path challenge / path response. > > > > I am not sure if I like that alternative, primary because it does not > > seem right as a way to drop Initial, 0-RTT, Handshake keys. We are > > trying to address two issues at once; how to drop those keys in lower > > epochs, and how to do key update correctly. > > The test we are looking for is whether a peer can read packets with a particular key. You can test easily if they can write packets with a key because you receive a packet protected with that key. > > PATH_CHALLENGE/PATH_RESPONSE have baggage, so I don't want to use those. A new challenge/response could work, but it doesn't offer much over a simple assertion (which is what the proposed frame is). If the assertion is wrong, then the consequence is a broken connection, so there isn't much incentive to get this wrong. PATH_CHALLENGE/PATH_RESPONSE contain a field that protects against lying, because there are scenarios in which lying provides advantage (that is, the "DoS this IP please" case). > -- Kazuho Oku
- KEYS_READY Martin Thomson
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Mikkel Fahnøe Jørgensen
- Re: KEYS_READY Marten Seemann
- Re: KEYS_READY Ian Swett
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Mikkel Fahnøe Jørgensen
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Mikkel Fahnøe Jørgensen
- Re: KEYS_READY Christian Huitema
- Re: KEYS_READY Mikkel Fahnøe Jørgensen
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY Christian Huitema
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Jana Iyengar
- Re: KEYS_READY Jana Iyengar
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY Marten Seemann
- Re: KEYS_READY Mikkel Fahnøe Jørgensen
- Re: KEYS_READY Mikkel Fahnøe Jørgensen
- Re: KEYS_READY David Schinazi
- Re: KEYS_READY Ryan Hamilton
- RE: KEYS_READY Mike Bishop
- Re: KEYS_READY David Schinazi
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY David Schinazi
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY David Schinazi
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY David Schinazi
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY David Schinazi
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY Nick Harper
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY David Schinazi
- Re: KEYS_READY Kazuho Oku
- Re: KEYS_READY Martin Thomson
- Re: KEYS_READY David Schinazi