Re: [quicwg/base-drafts] HOL blocking on Finished (#446)
Martin Thomson <notifications@github.com> Sun, 23 April 2017 23: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 691A0126C0F for <quic-issues@ietfa.amsl.com>; Sun, 23 Apr 2017 16:18:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.799
X-Spam-Level:
X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-2.8, 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 VoQCd1yutUNi for <quic-issues@ietfa.amsl.com>; Sun, 23 Apr 2017 16:18:27 -0700 (PDT)
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2-ext3.iad.github.net [192.30.252.194]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45501201F2 for <quic-issues@ietf.org>; Sun, 23 Apr 2017 16:18:26 -0700 (PDT)
Date: Sun, 23 Apr 2017 16:18:26 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1492989506; bh=SZnNxF676jg6rscnFO4987VEpjfy1QsSe9r29JJndIY=; h=From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=tDkLz3vH/KMeZbisI/c/sEhddMI1kgS1X789rUW88s2izpjhEP5bNd9AAOyIoSbyT Lhhph4rU/5yHbZkISAcCgHSl828+xRqXZcQMc+BrhXRCjBGJqn6mN/Uh5rPZh4N3Hy y7nbLdb0DxYHC2g0GVkqOOzDasuI3hL1qr2eyHmU=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abb4e963d37117d1343b3ab24ee7ef433566d929ad92cf000000011514f84292a169ce0d495814@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/446/296496236@github.com>
In-Reply-To: <quicwg/base-drafts/issues/446@github.com>
References: <quicwg/base-drafts/issues/446@github.com>
Subject: Re: [quicwg/base-drafts] HOL blocking on Finished (#446)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_58fd36423a4a3_7d593fd62e333c38110863"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinthomson
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/KM4qnnxGlswBsGN3_QInwsM-IlU>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
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, 23 Apr 2017 23:18:28 -0000
This assertion that record layer authentication is equivalent to the Finished message is one that caused cryptographers considerable heartburn. They were unwilling to commit to that being sufficient for key confirmation for a range of reasons. Your point about client authentication is not so clear-cut. It is arguably possible to have two boolean status values at the server: "is the connection up" and "is the client authenticated", which can lead to a situation where the server can provide *some* responses even if the client isn't authenticated. Think about those cases where we have post-handshake authentication. There are some things on the server that aren't universally accessible to unauthenticated clients, but maybe not everything. In the general case though, you are right. Generally, guidance is that a server that has requested that the client authenticate wait until it knows for sure. But we have a lot of servers that request authentication for clients but don't close the connection if the client refuses. That suggests that the above model - while more complex - is at least valid. -- 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/446#issuecomment-296496236
- [quicwg/base-drafts] HOL blocking on Finished (#4… Martin Thomson
- Re: [quicwg/base-drafts] HOL blocking on Finished… Victor Vasiliev
- Re: [quicwg/base-drafts] HOL blocking on Finished… Martin Thomson
- Re: [quicwg/base-drafts] HOL blocking on Finished… Victor Vasiliev
- Re: [quicwg/base-drafts] HOL blocking on Finished… ekr
- Re: [quicwg/base-drafts] HOL blocking on Finished… Martin Thomson
- Re: [quicwg/base-drafts] HOL blocking on Finished… Martin Thomson
- Re: [quicwg/base-drafts] HOL blocking on Finished… Martin Thomson