From nobody Tue May 11 10:11:07 2021 Return-Path: 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 765C13A1EDA for ; Tue, 11 May 2021 10:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 lyUGhHAHK6b5 for ; Tue, 11 May 2021 10:11:01 -0700 (PDT) Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) (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 0156E3A1ED8 for ; Tue, 11 May 2021 10:11:00 -0700 (PDT) Received: by mail-io1-xd32.google.com with SMTP id t3so18831553iol.5 for ; Tue, 11 May 2021 10:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iv/VfkAy6PBmoAzTVMsXWaYfjjytHxbtj3CsilC/rTU=; b=izVQlpMBVI8AEpsJcQUyLrmonRfhDVycqK7vcyM3kIeKd9ZTdNOTOpuxbKRDbJkrql TX7/KDq3FPURc0sJEYtyunN7dm1ZtawKd6ktmdc4FO4kD5Qw1XOcKUBQgwyXGIh41AW6 2+Qxz4fSARPDaPuzUr8PkL6/hvx8W419Om4sd/On9fnCTXZyaAsuVntpOwG6J0lMcqqJ 7g2+pm/h7uBACHL4s6/QHzSG1yruworTzNVd9DGlYam4+ORly8Z22itMX2iXTsj6Tpk0 g4eJJrlCb9niyz6hHyYR31Ed7GEwtzFgeJj96m/IecSaqd0zo5co/qka229JJr5wZqSl tuhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=iv/VfkAy6PBmoAzTVMsXWaYfjjytHxbtj3CsilC/rTU=; b=lEjoCKVb+50O4GlyXXI1VJD1HL4TQlcbVF8NZcd1xmTVy/NDF+ppSEm5GKK9uAWZQ5 X/I740U7XPGOPdgV6XYFTVWXAx7nUSKSljGpJJemPX7pte8bf32caTC3iKc0x7fMhxYA qWLJP8BOZO38d8a2LM5GdSTtu7vqJGDUkFAX8RVQzpRCAaUjJhr6AaUTNvit3G1ePJEh MEcS0PCGn02xfMOLGuc7pPMkz5syE8Vc6Rj+xq/7EikC5dIPaC4+oDtVoVjemxHsaUhn 7bx9Yp6e27uWP4r8N2re0aFhlHv4RuMXkp7o5Q6lUFEne8r9iU4SR0JuwTosgpZjs4pw BPwg== X-Gm-Message-State: AOAM531uFHryn38AdWqmJ1mZfl5cy9P8ZX+ddtd6UKzoaooKnoQ1Xjoy ecF45ozz7fUGKhkbM7zoETi/CTCu3+e4ioWSNEARBqciP8J3RQ== X-Google-Smtp-Source: ABdhPJx8kMxAE2TgYnnWayZNpgxPO5ybnwLzlCgl3DzxmtBhPLi9M2NgTdSieZecnNOieP2C8i9eU9bZx5LfU6Ib7Po= X-Received: by 2002:a05:6602:446:: with SMTP id e6mr3026140iov.20.1620753058332; Tue, 11 May 2021 10:10:58 -0700 (PDT) MIME-Version: 1.0 From: Martin Duke Date: Tue, 11 May 2021 10:10:49 -0700 Message-ID: Subject: Tacking stuff on to VN packets To: IETF QUIC WG Content-Type: multipart/alternative; boundary="0000000000004f8c0305c210faa8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 May 2021 17:11:06 -0000 --0000000000004f8c0305c210faa8 Content-Type: text/plain; charset="UTF-8" Section 6 of invariants sayeth: "Version Negotiation packets do not use integrity or confidentiality protection. Specific QUIC versions might include protocol elements that allow endpoints to detect modification or corruption in the set of supported versions." I also vaguely remember ekr batting around the idea of tacking some data onto the packet to solve a problem we were discussing. *Maybe we just don't want to do this at all and we can safely ignore this text in invariants.* If we *do* want to do it, the design is a little problematic. There is no length field in VN packets to signal that the supported version list is ending and other stuff is beginning. The only way I can think of to make this work is to use the VN draft to reserve a magic version number to mean "this is the end of the supported version list". That version is not a real version, MUST be the last one listed, and perhaps can be followed by another magic number to indicate the content that follows. Leaving aside legacy stuff negotiating pre-standard versions, which will hopefully go away someday, someone supporting multiple versions would be REQUIRED to support the VN draft and therefore incorporate this change. Thoughts? Martin --0000000000004f8c0305c210faa8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
<= br>
"Version Negotiation packets do not use integrity or con= fidentiality protection. Specific QUIC versions might include protocol elem= ents that allow endpoints to detect modification or corruption in the set o= f supported versions."

I also vaguely remembe= r ekr batting around the idea of tacking some data onto the packet=C2=A0 to= solve a problem we were discussing.

Maybe we j= ust don't want to do this at all and we can safely ignore this text in = invariants.

If we *do* want to do it, the desi= gn is a little problematic. There is no length field in VN packets to signa= l that the supported version list is ending and other stuff is beginning.

The only way I can think of to make this work is to= use the VN draft to reserve a magic version number to mean "this is t= he end of the supported version list". That version is not a real vers= ion, MUST be the last one listed, and perhaps can be followed by another ma= gic number to indicate the content that follows.

L= eaving aside legacy stuff negotiating pre-standard versions, which will hop= efully go away someday, someone supporting multiple versions would be REQUI= RED to support the VN draft and therefore incorporate this change.

Thoughts?
Martin

--0000000000004f8c0305c210faa8--