IETF Logo Mail Archive

Re: [Last-Call] Secdir last call review of draft-ietf-quic-v2-05

Martin Duke <martin.h.duke@gmail.com> Mon, 10 October 2022 18:16 UTC

Return-Path: <martin.h.duke@gmail.com>
X-Original-To: last-call@ietfa.amsl.com
Delivered-To: last-call@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE63C1524D4; Mon, 10 Oct 2022 11:16:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wHsVeIesyKrW; Mon, 10 Oct 2022 11:16:21 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8EAFC1524DC; Mon, 10 Oct 2022 11:16:17 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id t25so69884qkm.2; Mon, 10 Oct 2022 11:16:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=vZBZ9T/vpKHYiAuHO8FiVuU4RfwIGlOMRynXOtO5YJs=; b=cSWTfEfPMi+ngzk57O3sYcJCDGsvxaeyEqeqmxJbfFZoF3RCQQiY4A38INpBCoQ/iR suMGdtg2naaB9cXH51RiobbIGcFlnWQ+zlj6bnqw41/rMpELLiieUrG7Q/cxOLFbDMdN NMP71c7Ow23SmQWQpqc2RoFxVm1vbxYh6ZXy3gb/vB47Lj6VcKZRwwyIOoEDyE2XsnDE CL9RY05hjW+2MKq6GZnemcZi5UC6eO4ZAJlT7L2vcZQinXArDgHyfWjtUg/pZLMiLg5M k9jvVgDkM6abkPUs2xnpIobC7cUikgKyjKRRn9LqD/8qbZnVFcpyCrKd5cXbinq2PaI+ C8+g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vZBZ9T/vpKHYiAuHO8FiVuU4RfwIGlOMRynXOtO5YJs=; b=K4y2nhcZ/C1eFMIjWx0aFVpZGGJhxkEVyOOX5kew/8YvRmXkEOBKfFFdWCnI9ou1sQ 0Dl00VAs1kLOiOCDP0h9sGgRF4NI6i1+wcVud9Xh0r5mvXrYaGv5ZbUpM6+pCrA39K8W I9zHgmqkG6FSzm7Ap7ri5wtQuczGOMtYXlqd1axlYpfaM658ufd8qnxxEJYJ8ge/j28R x29Svu1FiUDctqgsloqzHCgwFuyOlwVHYFgQxVqOeztGd4XgTvNNot7MN5nII3KmW30z gLASAAUjzLfSKV5ogHS3/62fqTZjumrrhlH3LfgjH3ItesbismnRM5z5MiZkvUzaK81u oEZw==
X-Gm-Message-State: ACrzQf0olNkhT2mabTJMLfNFuI8Wh08yz5TXstSOsPX6kLh+yiRfeunf ecA1UskwLP+ZIMXS9q6ZKMjmk+TZCl41g8v7uBzxYZUQiUM=
X-Google-Smtp-Source: AMsMyM6+hSgFZzDmRJydUnazQy2JRcvivEOwKELJv+A4DQWQRB/VIXTbmqBj1uMtt1OukousomL2PGwqd7IbasLEcaU=
X-Received: by 2002:a05:620a:454e:b0:6ec:61a0:1865 with SMTP id u14-20020a05620a454e00b006ec61a01865mr5175229qkp.414.1665425776497; Mon, 10 Oct 2022 11:16:16 -0700 (PDT)
MIME-Version: 1.0
References: <166489673663.46010.13599556145012423275@ietfa.amsl.com>
In-Reply-To: <166489673663.46010.13599556145012423275@ietfa.amsl.com>
From: Martin Duke <martin.h.duke@gmail.com>
Date: Mon, 10 Oct 2022 11:16:05 -0700
Message-ID: <CAM4esxTg9x3WF8BqY93gba_of+FBYsPEfszGQ1Da3UX8iYw1=w@mail.gmail.com>
To: Kyle Rose <krose@krose.org>
Cc: secdir@ietf.org, draft-ietf-quic-v2.all@ietf.org, last-call@ietf.org, quic@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ced76c05eab22795"
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/mOxzmAMYGa594J4aGc8IcuOEIQI>
Subject: Re: [Last-Call] Secdir last call review of draft-ietf-quic-v2-05
X-BeenThere: last-call@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF Last Calls <last-call.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/last-call>, <mailto:last-call-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call/>
List-Post: <mailto:last-call@ietf.org>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/last-call>, <mailto:last-call-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Oct 2022 18:16:23 -0000

Hi Kyle,

Thanks for the review! There's a PR with the resulting changes:
https://github.com/quicwg/quic-v2/pull/75

replies inline

On Tue, Oct 4, 2022 at 8:18 AM Kyle Rose via Datatracker <noreply@ietf.org>
wrote:

> Reviewer: Kyle Rose
> Review result: Ready
>
> I have only three additional questions/comments:
>
> - What are the implications of the server not encoding the version in its
> Retry
> message and subsequently checking that the client didn't change versions
> upon
> retrying?
>

AFAICT there are no security implications here. The spec is restrictive to
reduce the
complexity of the code, and gives the server the option of enforcing the
rule in order
to discourage clients from violating it.


>
> - Is there any optimization possible if the server keeps the Initial
> receive
> keys slightly longer than the first instance of processing a packet using
> keys
> generated for the negotiated version? I'm guessing not, but I just wanted
> to
> confirm.
>

No. It might want to keep around the 0-RTT keys from the original version,
but once it
receives the negotiated version there are no outstanding client Initial
packets with the
old version.


>
> - In "Endpoints have no need to generate the keying material that would
> allow
> them to decrypt or authenticate these packets", I would s/these/such/.
>
>
>

v2.23.0 | Report a Bug | By Email