Re: [quicwg/base-drafts] Server Initial verification for Attacker On The Side defense (#2097)
Kazuho Oku <notifications@github.com> Wed, 05 December 2018 08:32 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 26C3512D4F1 for <quic-issues@ietfa.amsl.com>; Wed, 5 Dec 2018 00:32: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 aXmbJeAdBirA for <quic-issues@ietfa.amsl.com>; Wed, 5 Dec 2018 00:32:46 -0800 (PST)
Received: from out-13.smtp.github.com (out-13.smtp.github.com [192.30.254.196]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4560B12D4E9 for <quic-issues@ietf.org>; Wed, 5 Dec 2018 00:32:46 -0800 (PST)
Date: Wed, 05 Dec 2018 00:32:45 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1543998765; bh=R5BmlmlsVAnKncZd/qNK7VxPmz4E+js7mAuPuOP10l0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=eZ/VTSQn1zOsUneG5+sB5y6QBr7lFlOX1VOJUkBErmyV2CT3gHi1fFQOYDnxgchc3 dyzm5/cia4z1/FHD+7eHuXdq0cRmJ5v+zZYbel83eA/ic2IwHBvRUku3QhaHVlEXr4 8Ny2aFEAHTsrJ8kec6d9ctD7Qe0FYe++rkfqXZ0A=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab99364bd1ab28f1d73e7ec7577e69b15a2bef64e292cf00000001181f4f2d92a169ce17184276@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/2097/444401558@github.com>
In-Reply-To: <quicwg/base-drafts/issues/2097@github.com>
References: <quicwg/base-drafts/issues/2097@github.com>
Subject: Re: [quicwg/base-drafts] Server Initial verification for Attacker On The Side defense (#2097)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5c078d2d7a252_6c753f9ba62d45c04533f4"; 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/rjkiGJ05UhfBHQkL-yzBlJy2q5w>
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: Wed, 05 Dec 2018 08:32:48 -0000
@huitema > This works as long as the attacker forges its responses without knowledge of the server's SCID. If the attacker sees the first Server Hello (step 3), it can race a competing Server Hello with the same CCID, SCID. If the attacker wins the race, it will effectively "own" the context (CCID, SCID). I disagree with this observation (and the therefore the discussion that follows). A client does not need to distinguish each "flow of handshake transcripts" based on SCID. What it should do is distinguish each flow by ServerHello that's being contained (for Initial packets) or the handshake key (for Handshake packets) that decrypts successfully. Therefore, there is no need for a "server token." -- 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/2097#issuecomment-444401558
- [quicwg/base-drafts] Server Initial verification … Christian Huitema
- Re: [quicwg/base-drafts] Server Initial verificat… MikkelFJ
- Re: [quicwg/base-drafts] Server Initial verificat… Christian Huitema
- Re: [quicwg/base-drafts] Server Initial verificat… Kazuho Oku
- Re: [quicwg/base-drafts] Server Initial verificat… Christian Huitema
- Re: [quicwg/base-drafts] Server Initial verificat… Martin Thomson
- Re: [quicwg/base-drafts] Server Initial verificat… Christian Huitema
- Re: [quicwg/base-drafts] Server Initial verificat… Martin Thomson
- Re: [quicwg/base-drafts] Server Initial verificat… Mark Nottingham