IETF Logo Mail Archive

Re: [quicwg/base-drafts] handling of KeyUpdate in other epochs are specified in RFC 8446, do not override (#4412)

Kazuho Oku <notifications@github.com> Mon, 30 November 2020 07:18 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 816E93A1086 for <quic-issues@ietfa.amsl.com>; Sun, 29 Nov 2020 23:18:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.481
X-Spam-Level:
X-Spam-Status: No, score=-1.481 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, 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 (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 wSlJx9Ca80uw for <quic-issues@ietfa.amsl.com>; Sun, 29 Nov 2020 23:18:10 -0800 (PST)
Received: from smtp.github.com (out-21.smtp.github.com [192.30.252.204]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C716B3A1084 for <quic-issues@ietf.org>; Sun, 29 Nov 2020 23:18:10 -0800 (PST)
Received: from github.com (hubbernetes-node-e542fe5.ac4-iad.github.net [10.52.121.56]) by smtp.github.com (Postfix) with ESMTPA id CAB9C52006A for <quic-issues@ietf.org>; Sun, 29 Nov 2020 23:18:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1606720689; bh=d5S8xQYAm1OnCLwcZOMLqWRQRZTcJPihwH7EMV0iKSA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=0Kom55TNc62Gn9yykoUHHjXhEYSRWH5mm0lgQe95joprTBs4TGKq+5+DwwzB4EV7S jUtoIRmpwW7PzjCWYq519UxVkz+DmUZTmo2951PPty9D5Lm6R3OGbuA4NQAyl6CLJk zPWOUstRsXwFs6WKNmsy1/pRf4ZHr7IvWaZj309E=
Date: Sun, 29 Nov 2020 23:18:09 -0800
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7W62GAJDCEDRQPD3N52B63DEVBNHHCZX3BKQ@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/4412/c735601008@github.com>
In-Reply-To: <quicwg/base-drafts/pull/4412@github.com>
References: <quicwg/base-drafts/pull/4412@github.com>
Subject: Re: [quicwg/base-drafts] handling of KeyUpdate in other epochs are specified in RFC 8446, do not override (#4412)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5fc49cb1c62f1_5819b47511"; 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/sjdo1dWigxOGDPd2fQR9cPsmQaE>
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 07:18:13 -0000

@kazu-yamamoto 
> It's possible but it's not reasonable because QUIC stack needs to parse TLS messages.

A QUIC stack that discards the TLS state post-handshake is committing to handle TLS messages by itself. Therefore, it has to handle them correctly.

In practice, such QUIC stack running as clients have to handle NewSessionTicket messages correctly (therefore they need to be capable of parsing TLS messages). Such stacks running as servers can respond with unexpected_message alert for any post-handshake message because in RFC 8446 there isn't a case where a client unilaterally sends a post-handshake message with the only exception being KeyUpdate.

> BTW, where can I find the fallback rule?

It is defined at https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#section-11-2.

-- 
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/pull/4412#issuecomment-735601008

v2.23.0 | Report a Bug | By Email