IETF Logo Mail Archive

Re: [quicwg/base-drafts] Idempotency and replay (#4393)

Kazuho Oku <notifications@github.com> Mon, 30 November 2020 12:10 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 732703A09D4 for <quic-issues@ietfa.amsl.com>; Mon, 30 Nov 2020 04:10:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.483
X-Spam-Level:
X-Spam-Status: No, score=-1.483 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, 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 DrEbwwg0r2nL for <quic-issues@ietfa.amsl.com>; Mon, 30 Nov 2020 04:10:45 -0800 (PST)
Received: from smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C09B3A09C5 for <quic-issues@ietf.org>; Mon, 30 Nov 2020 04:10:45 -0800 (PST)
Received: from github.com (hubbernetes-node-16c1bc0.va3-iad.github.net [10.48.111.39]) by smtp.github.com (Postfix) with ESMTPA id 6BFC95C03FA for <quic-issues@ietf.org>; Mon, 30 Nov 2020 04:10:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1606738244; bh=Vj5dMPwkmRJh2QNpmHVgfGTUXzEIZ5MqWUj52HLi574=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=C2lcUK1n+mkZ8EGlDr9ttSbz4YwebCRZT/zLPj1SSz9XSUz54ijkcjt7NRzq0mCU0 fb5POSxbKgd2LWos5htDziTBNFL3KQ/uvV5IIFQR08krDDSqA96SeL7IEamjeBRnL9 fTw3Bslnfclg2Z5ykO5AnptNghfQ69bgbnKfmIgY=
Date: Mon, 30 Nov 2020 04:10:44 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYGUVG7M3CRX34B4YN52DBEJEVBNHHCY6WRSA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/4393/735748080@github.com>
In-Reply-To: <quicwg/base-drafts/issues/4393@github.com>
References: <quicwg/base-drafts/issues/4393@github.com>
Subject: Re: [quicwg/base-drafts] Idempotency and replay (#4393)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5fc4e14468a28_113b19b42862ba"; 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/ndPsEAcukUjgarc4pk1M9Nsf_ak>
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: Mon, 30 Nov 2020 12:10:46 -0000

@nibanks I think you are correct in pointing out that we do not have such a restriction in QUIC-TLS. That in turn means that QUIC is deviating from TLS 1.3 that mandates the application to "instruct" if data sent in 0-RTT should be replayed. I think that having such a requirement in QUIC is difficult, because QUIC stacks might retransmit data sent in 0-RTT packets using 1-RTT packets.

I think that leads to the conclusion that QUIC has to specify it's own "replay safety," because it cannot have have all the "out of abundance of caution" MUSTs that TLS 1.3 have. At the end of the day, I think #4394 is fine as it is.

-- 
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/issues/4393#issuecomment-735748080

v2.23.0 | Report a Bug | By Email