Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)

Kazuho Oku <notifications@github.com> Fri, 15 November 2019 09:20 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 7EF55120164 for <quic-issues@ietfa.amsl.com>; Fri, 15 Nov 2019 01:20:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.595
X-Spam-Level:
X-Spam-Status: No, score=-6.595 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_28=1.404, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 nXwAGZhF_o0J for <quic-issues@ietfa.amsl.com>; Fri, 15 Nov 2019 01:20:44 -0800 (PST)
Received: from out-19.smtp.github.com (out-19.smtp.github.com [192.30.252.202]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D59120154 for <quic-issues@ietf.org>; Fri, 15 Nov 2019 01:20:44 -0800 (PST)
Date: Fri, 15 Nov 2019 01:20:43 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1573809643; bh=ONa+ruYYhXIOKCJUbt2FJ9uTFrFEvj2svmwiRai0T5k=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=HkLXcs5QuxSDsl6fGR6kjU/fGfzx1JQfNZZyfi8I2UuaG0mRBICNFd2qjpVMjp7GM 6AXTP4oXgHV9jfY2GV4hMAm+ALc1Duv7OlTyvragX/IrgkODpc13TxZ3RFsN1nF7W2 j6v3aSvcqqMFlSvS1yVooLSmw9OATSAYK30SanDo=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7GX7BIORV32WCSJA533OQGXEVBNHHB5FNSNM@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3156/c554279982@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3156@github.com>
References: <quicwg/base-drafts/pull/3156@github.com>
Subject: Re: [quicwg/base-drafts] clarify the scope of a NEW_TOKEN token (#3156)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5dce6debbf66a_28173fef6a2cd9605628da"; 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/i_LbOBPaiT3n3G17IaDTwqmkpOs>
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: Fri, 15 Nov 2019 09:20:47 -0000

@ekr Quoting from [RFC 8446 section 4.6.1](https://tools.ietf.org/html/rfc8446#section-4.6.1), the requirement for NST is:
```
   Clients MUST only resume if the new SNI value is valid for the server
   certificate presented in the original session and SHOULD only resume
   if the SNI value matches the one used in the original session.
```

MUST NOT of added in this PR achieves parity with the "MUST only" statement in TLS 1.3.

Regarding the SHOULD in TLS 1.3, I do not think we need feature parity. Compared to TLS 1.3 running over TCP, it is extremely difficult in QUIC to create a proxy that extracts the SNI and then let's different backend server handle the connection. It is natural to assume that a QUIC server that presents a wildcard certificate to be directly hosting all those server identities.

-- 
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/3156#issuecomment-554279982