Re: [quicwg/base-drafts] Why does stateless reset have to be checked after MAC failure (#2152)

MikkelFJ <> Mon, 26 August 2019 11:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 259AA120129 for <>; Mon, 26 Aug 2019 04:23:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.454
X-Spam-Status: No, score=-6.454 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, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D23EwigVkFsx for <>; Mon, 26 Aug 2019 04:23:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D3EE61200EB for <>; Mon, 26 Aug 2019 04:23:54 -0700 (PDT)
Date: Mon, 26 Aug 2019 04:23:54 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=pf2014; t=1566818634; bh=vMpJwIC+CEyFH1BRwWH/lJg+G2Fs2xiacohJ4JRK/M0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=sgH/5EsN3hNBVJ22XayLfJBzb2tB5+truLeJPd/kyD5/a4U7wp8ULoHqwKbitjIlL k3DxwsQQh9m3nE9sXAlMvxrss9BbJiUpZs2HcJuEstwqReynTW3pqCuZD3p2A7VIj4 7U8dtm1lynCIbskl8+vv3nN6ThtKgy+5cniH3z0A=
From: MikkelFJ <>
Reply-To: quicwg/base-drafts <>
To: quicwg/base-drafts <>
Cc: Subscribed <>
Message-ID: <quicwg/base-drafts/issues/2152/>
In-Reply-To: <quicwg/base-drafts/issues/>
References: <quicwg/base-drafts/issues/>
Subject: Re: [quicwg/base-drafts] Why does stateless reset have to be checked after MAC failure (#2152)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d63c14a1d8fa_14aa3f91a94cd964130863"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
Archived-At: <>
X-Mailman-Version: 2.1.29
List-Id: Notification list for GitHub issues related to the QUIC WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 26 Aug 2019 11:23:56 -0000

Thus, a solution to the reset problem could be to define an algorithm and share keys with the client. The problem is that the clients key must be session specific while that server cannot share its server keys, so something creative must be invented. If this is done, another latency will be added to the per packet overhead, which is also not desirable, similar to header protection.

You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub: