IETF Logo Mail Archive

Re: [quicwg/base-drafts] Prohibit TLS middlebox compatibility mode (#3594)

Kazuho Oku <notifications@github.com> Thu, 23 April 2020 03:28 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 3EECF3A124A for <quic-issues@ietfa.amsl.com>; Wed, 22 Apr 2020 20:28:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.554
X-Spam-Level:
X-Spam-Status: No, score=-1.554 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_20=1.546, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 x78wX_uDntlY for <quic-issues@ietfa.amsl.com>; Wed, 22 Apr 2020 20:28:07 -0700 (PDT)
Received: from out-27.smtp.github.com (out-27.smtp.github.com [192.30.252.210]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F09503A124E for <quic-issues@ietf.org>; Wed, 22 Apr 2020 20:28:06 -0700 (PDT)
Received: from github-lowworker-fb56993.ac4-iad.github.net (github-lowworker-fb56993.ac4-iad.github.net [10.52.19.31]) by smtp.github.com (Postfix) with ESMTP id AE4DCE0C7E for <quic-issues@ietf.org>; Wed, 22 Apr 2020 20:28:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1587612485; bh=6muaP4/1P1iukTjwMgUnHnFUStsTpCg8wjXXI1GfB4g=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=GojMmvrHtPpdpPRDV8uTtUDJ+F9u4MwEgi5VgopNMZm1CF1oqONXWiflKfLb6WCdg 5odeyajsTWKmn+T50gn/5hVyW9m8BX2l1WIWgnwd5RbUbrx3xbI2z0vfkODkLSjBWq d2Ob+fyrwLGcgLpKi24Maqn2id0NbtejLoIfzYqw=
Date: Wed, 22 Apr 2020 20:28:05 -0700
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK4NISR77XZD2DH462F4VTWELEVBNHHCIEKOAA@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3594/618155197@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3594@github.com>
References: <quicwg/base-drafts/issues/3594@github.com>
Subject: Re: [quicwg/base-drafts] Prohibit TLS middlebox compatibility mode (#3594)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ea10b459d916_3e8f3f81118cd968587a5"; 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/l8hsfqmr20BD4_pjfNhIoD8fxKQ>
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: Thu, 23 Apr 2020 03:28:09 -0000

Just to be clear, picotls has had the switch, but it has been sending a 32-byte legacy_session_id even when the switch was off. That was a violation of a MUST in RFC 8446, purely implementation bug.

@DavidSchinazi 
> I'm not sure what this change would get us. Isn't it simpler to ignore CCS on receipt instead of requiring the receiver to check for CCS and fail the handshake?

In QUIC, it is impossible to send CCS, because the CRYPTO streams of QUIC can only carry handshake messages. CSS is not a handshake message, it's a TLS record. Therefore, it is my understanding that this issue is an editorial clarification.

-- 
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/3594#issuecomment-618155197

v2.23.0 | Report a Bug | By Email