Re: [quicwg/base-drafts] Add Advice and Rules for CONN_CLOSE in Initial and Handshake (#1786)

Kazuho Oku <notifications@github.com> Fri, 28 September 2018 08:33 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 8100D130DCE for <quic-issues@ietfa.amsl.com>; Fri, 28 Sep 2018 01:33:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 EMptxQEYfrJN for <quic-issues@ietfa.amsl.com>; Fri, 28 Sep 2018 01:33:26 -0700 (PDT)
Received: from out-4.smtp.github.com (out-4.smtp.github.com [192.30.252.195]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6193130DC9 for <quic-issues@ietf.org>; Fri, 28 Sep 2018 01:33:25 -0700 (PDT)
Date: Fri, 28 Sep 2018 01:33:24 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538123604; bh=zL/2BAeiwXJxctQVcHQsySy7RQn1lf/J+OawaoQLiz0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZzME6URTq27qMQBHZruhlPqcMguC/oBZTdRkDwJvmc/Ic9h3Vh7U3LUhNOJ8f/Pk1 NGbWj5U5i1toNseB62GogaxDRDVM47BjpjXVbvC0rfC+7sFlAtcJksbuTr3JNL1yMX Mq2ILyNW9EL+F5qcsJMrutDqv7YCb2XEbP9vzSQA=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4abaaee2791aba507849ddef1b1c537e85b3cb4dd4392cf0000000117c5a95492a169ce159f31b4@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1786/425363631@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1786@github.com>
References: <quicwg/base-drafts/issues/1786@github.com>
Subject: Re: [quicwg/base-drafts] Add Advice and Rules for CONN_CLOSE in Initial and Handshake (#1786)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bade754c4212_10333ff4fa6d45b455386f"; 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/Mupo5tViDTHTYZzevce970SXwbc>
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, 28 Sep 2018 08:33:27 -0000

@ianswett 
> I think the sender text is fairly straightforward, but we have 3 options I'm aware of on the receiver side:
> 
> 1. Require implicit ACKs.
> 2. Instruct the receiver to ACK Initial encryption after receiving Handshake, but not process them.
> 3. Decide we don't care about injection attacks.

IIRC the discussion during the handshake redesign process was that we should not care about injection attacks, though the design allows stacks to implement countermeasures (see [TLS Handshake Messsages on QUIC; section 3.4](https://docs.google.com/document/d/1fRsJqPinJl8N3b-bflDRV6auojfJLkxddT93j6SwHY8/edit))

For a middlebox, the easiest way of disrupting a handshake is to send a crafted Initial in response to the client's first flight. We do require the endpoints to implement protection for that. So I do not think there is a reason to care about injection attacks happening at a later moment.

-- 
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/1786#issuecomment-425363631