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

martinduke <notifications@github.com> Fri, 28 September 2018 21: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 DF846129AB8 for <quic-issues@ietfa.amsl.com>; Fri, 28 Sep 2018 14:18:31 -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 EL0JHEkN5PmD for <quic-issues@ietfa.amsl.com>; Fri, 28 Sep 2018 14:18:30 -0700 (PDT)
Received: from out-15.smtp.github.com (out-15.smtp.github.com [192.30.254.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3810D127133 for <quic-issues@ietf.org>; Fri, 28 Sep 2018 14:18:30 -0700 (PDT)
Date: Fri, 28 Sep 2018 14:18:29 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1538169509; bh=mOC6OYBCBIBMnALxT6xOhdEwXTZkoCMkkFVZoaJ17hg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=holub3lydT2SzxAnZJT7rrJToUAtr7mh9nPUb1ISjGRascK2Gju9jCkCMiILkDJhC 7VgbrY0M+D8mmb02sI2wBhMGsfvXBiF0gixenVc/bOhRpxZhgekwCzYd7AjezgjrlW vFnwXX4cuztQpw8idd6Z/ALlC00dSBBylbgtVsgk=
From: martinduke <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab2c86d07040961f9d3da928d6b2fd4927eea7199692cf0000000117c65ca592a169ce159f31b4@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/425568975@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_5bae9aa57f881_5e7c3fdfd6cd45c4110539"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: martinduke
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/rPVZcxsBGYzdjNvHTgAhskTsV_g>
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 21:18:32 -0000

@ianswett Personally, I'm reluctant to cross the implicit ACK bridge. Messing with the ack and retransmission logic, at this point, could result in unforeseen consequences in the handshake. I would much rather restrict the weirdness to error cases in the just after the Initial phase, which is unlikely to be exercised often.

@kazuho I want to clarify an important distinction here. There is nothing we can do about injection attacks in the first 1.5 RTTs, and that is not the objection here. There is a further vulnerability, after handshake keys are employed, until we dispose of the keys. I am trying to close that hole without driving people to run their timers too short.

You may be right that people will do it anyway. But I'd like to spec to be consistent with best practice.

Do people think this is discussion is far enough along that they'd like to see a PR?

-- 
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-425568975