Re: [quicwg/base-drafts] Initials carrying different first ClientHello are considered as belonging to different connections (#2076)

Kazuho Oku <notifications@github.com> Tue, 04 December 2018 01:57 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 4215B130DD3 for <quic-issues@ietfa.amsl.com>; Mon, 3 Dec 2018 17:57:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.46
X-Spam-Level:
X-Spam-Status: No, score=-9.46 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-1.46, 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 b_YdqtiqSvvr for <quic-issues@ietfa.amsl.com>; Mon, 3 Dec 2018 17:57:46 -0800 (PST)
Received: from out-5.smtp.github.com (out-5.smtp.github.com [192.30.252.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45B7D129533 for <quic-issues@ietf.org>; Mon, 3 Dec 2018 17:57:46 -0800 (PST)
Date: Mon, 03 Dec 2018 17:57:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543888665; bh=PGKu5KtJkmqCChBitfp8RqiqE2p8IsJtpGNy9Sagol0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=VhmzMgJs7lMuqVc3MKr7iV714TXctrEDn8f3guNgMNsOs+t0PpgZeC8NAtW+fCfNh xZtftqmfQDU49xysS/OUcc1/GUgi75LeCORGoCUQUczfo9TznAHrf0L9uKUDaLvucM Mv3rpAZbsm1tOWogIr0s/7SK3BTCkzwun2/W9wFM=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba71c9ad7560ec053216c221a7b850bbf61a28c7492cf00000001181da11992a169ce1701edfc@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/2076/review/181063549@github.com>
In-Reply-To: <quicwg/base-drafts/pull/2076@github.com>
References: <quicwg/base-drafts/pull/2076@github.com>
Subject: Re: [quicwg/base-drafts] Initials carrying different first ClientHello are considered as belonging to different connections (#2076)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c05df195bd9_33c23fd1b8ed45bc2885a"; 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/Mo_WStHdnSJg1si_RWGCM8KRxv8>
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, 04 Dec 2018 01:57:48 -0000

kazuho commented on this pull request.



> @@ -1037,8 +1037,18 @@ Servers MUST drop other packets that contain unsupported versions.
 
 Packets with a supported version, or no version field, are matched to a
 connection using the connection ID or - for packets with zero-length connection
-IDs - the address tuple.  If the packet doesn't match an existing connection,
-the server continues below.
+IDs - the address tuple, with the following exception.
+
+A server that uses a non-zero-length connection ID SHOULD handle Initial packets
+that share the same address tuple, Source and Destination Connection IDs, but
+contain different first ClientHello messages as belonging to different
+connections.  This might be used by a client to defend against attacks that race
+spoofed Initial packets with legitimate ones.  A server can treat every Initial
+packet containing a CRYPTO frame at an offset of 0 as potentially creating a new
+connection, discarding any packet that has the same Destination Connection ID
+and CRYPTO frame content as one that has been answered.
+

Yeah the text that discusses the approach purely by referring to the CRYPTO frame is hard to understand (and it might be erroneous).

The logic I'd expect the stacks to have is something like below:
```
if crypto_frame.offset == 0:
  ch_hash = sha256(crypto_frame)
  if conn_is_open():
    if open_conn.handshake_key != nil:
      if open_conn.ch_hash != ch_hash:
        handle_as_new_connection()
      else:
        handle_packet_with_care()             // to be addressed in #2045, #2053
    else:
      handle_initial_as_part_of_connection()  // HRR case
  else:
    handle_as_new_connection()
```

> I am concerned that to make this work, we should go back to the "stateless HRR" model, maybe sending the TLS HRR in a crypto frame in the payload of a retry packet.

I do not think so, because our experience in TLS 1.3 tells us that HRR will rarely be used, because the endpoints are incentivized to avoid the additional round-trip imposed by HRR.

-- 
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/pull/2076#discussion_r238506402