Re: [quicwg/base-drafts] Server should not accept 1-RTT traffic before handshake completion (#3159)

Martin Thomson <notifications@github.com> Tue, 29 October 2019 03:46 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 6327012008D for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 20:46:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.999
X-Spam-Level:
X-Spam-Status: No, score=-7.999 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_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 tyt7XQCsQ4tm for <quic-issues@ietfa.amsl.com>; Mon, 28 Oct 2019 20:46:28 -0700 (PDT)
Received: from out-17.smtp.github.com (out-17.smtp.github.com [192.30.252.200]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B2912008C for <quic-issues@ietf.org>; Mon, 28 Oct 2019 20:46:28 -0700 (PDT)
Date: Mon, 28 Oct 2019 20:46:27 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1572320787; bh=83PHyKf+8G2XGn5ef5MPRPtf6zy0jbWTY87qycP3B1w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=ZRTnKfH+iHMUmyESqPvFZXbYZn5LcEQbxea4ONXfg4UdOCindgG1kg4usvRA8Wos9 y9GEv4++jI8sMSDBBJC2ySDg/hRnBfR2EkYsWc4ia++shU7A7APgIAKFap8uvxrOOt /QwuGtWzMyOhuAarAV/ifc1tih7JG7O8kGz3Vgvk=
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK3KSO52JNXJ4RSSKEF3YTUJHEVBNHHB5FZ3ZY@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3159/547243572@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3159@github.com>
References: <quicwg/base-drafts/issues/3159@github.com>
Subject: Re: [quicwg/base-drafts] Server should not accept 1-RTT traffic before handshake completion (#3159)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5db7b6139aac5_51413fccdd0cd96c1065c3"; 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/sCy5yt08-guxSoj38aEjY-Mbdog>
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: Tue, 29 Oct 2019 03:46:30 -0000

This recommendation has been made a few times, but we have thus far resisted it on the basis of it not working with client authentication.

The suggestion that the server might offer proof that it didn't do something bad is new.  If I were inclined to take that suggestion seriously, I would instead say that the server should use an exporter to generate something.  You could even see how this might make its way into the proposed HANDSHAKE_DONE frame.

But I don't think that this needs this level of mechanism.  This is something that servers just need to do on their own.  Just like having a good source of randomness for their key generation, the consequences of failure here are that they might be open to attack.

I have no problem with test suites that purposefully "drop" critical packets to reveal misbehaving servers.  That might be better than adding mechanism.

That said, the server can just withhold ACK frames until it sees the whole handshake, even if it processes the entire handshake.  A server could answer requests from 1-RTT until clients start looking for that happening.  Ultimately, we can't stop the server from performing processing if it offers no reliable proof of that happening.  And I don't think that it's worth trying.

-- 
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/3159#issuecomment-547243572