[quicwg/base-drafts] ClientFinished is HoL blocking, but has no normative text (#2572)

ianswett <notifications@github.com> Sun, 31 March 2019 18:48 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 857AD1200EF for <quic-issues@ietfa.amsl.com>; Sun, 31 Mar 2019 11:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_32=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, 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 mTb6p-p7rFKc for <quic-issues@ietfa.amsl.com>; Sun, 31 Mar 2019 11:48:50 -0700 (PDT)
Received: from out-10.smtp.github.com (out-10.smtp.github.com [192.30.254.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E222120021 for <quic-issues@ietf.org>; Sun, 31 Mar 2019 11:48:50 -0700 (PDT)
Date: Sun, 31 Mar 2019 11:48:49 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1554058129; bh=Zx/PxEpJ9HNo6CBUXDiT9spJNZHoXZ3r+uUpTtG+Pnw=; h=Date:From:Reply-To:To:Cc:Subject:List-ID:List-Archive:List-Post: List-Unsubscribe:From; b=JenxcnStfXeTuger8nY/RR60qFesBJPN9gyIUte2xzBFlcmzdeTx+2xoEIGUNlyhD wAWg3HGnHERcekozW53g+/IFOqygBYe2x8wt/xYDfmOrTEUk0OPXwfz4H01HPuxUdo z/x4qhErlNFwaDP/ogUNTXMcE0MfWlXuSoCIRdzo=
From: ianswett <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abbe791ed76aab2c40ca03ffbc4f62375c810e5e6892cf0000000118b8cd9192a169ce197a0e86@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2572@github.com>
Subject: [quicwg/base-drafts] ClientFinished is HoL blocking, but has no normative text (#2572)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5ca10b9168bda_39853ff962ad45bc139558"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ianswett
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/QntTyVsPyK3RodhfJG9KrROWgNs>
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: Sun, 31 Mar 2019 18:48:52 -0000

I'm not saying I want the CFIN to be HoL blocking, but previous discussions have established it is.  I don't think the current TLS text is sufficiently clear(and normative) about that.

Section 4.1.1 has:
" Important:  Until the handshake is reported as complete, the
      connection and key exchange are not properly authenticated at the
      server.  Even though 1-RTT keys are available to a server after
      receiving the first handshake messages from a client, the server
      cannot consider the client to be authenticated until it receives
      and validates the client's Finished message.

      The requirement for the server to wait for the client Finished
      message creates a dependency on that message being delivered.  A
      client can avoid the potential for head-of-line blocking that this
      implies by sending a copy of the CRYPTO frame that carries the
      Finished message in multiple packets.  This enables immediate
      server processing for those packets."

https://tools.ietf.org/html/draft-ietf-quic-tls-19#section-4.1.1

-- 
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/2572