Re: [quicwg/base-drafts] Client's initial destination CID is unauthenticated (#1486)

MikkelFJ <notifications@github.com> Mon, 09 July 2018 20:30 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 7F49C131057 for <quic-issues@ietfa.amsl.com>; Mon, 9 Jul 2018 13:30:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.01
X-Spam-Level:
X-Spam-Status: No, score=-8.01 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, T_DKIMWL_WL_HIGH=-0.01] 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 XqlhvjHxHnF1 for <quic-issues@ietfa.amsl.com>; Mon, 9 Jul 2018 13:30:06 -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 266BE130DE1 for <quic-issues@ietf.org>; Mon, 9 Jul 2018 13:30:06 -0700 (PDT)
Date: Mon, 09 Jul 2018 13:30:05 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1531168205; bh=cVgCYAdd3P0jHNeMqX1w8EmvA5TYju8hWdOLk32Na28=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=xQ/N9yyGWrNIgDdaMlmFYacetjlaEM6imeTbV7tCRG8sM8csxwXO2BnWhifS1yT8U 93Sqacfz1EgqaemoTrYqUeXgnCQI63PsiPcoVQvTNiS6Hsncmk5wDJKY5kD9Qcba2U WibmNtZDRgy+cPtRZZaYac5wI2Q06Eh2rww2MxYc=
From: MikkelFJ <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab4822a46958e4472890dded6f3a175e9639c1293d92cf00000001175b87cd92a169ce140801b8@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1486/403609915@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1486@github.com>
References: <quicwg/base-drafts/issues/1486@github.com>
Subject: Re: [quicwg/base-drafts] Client's initial destination CID is unauthenticated (#1486)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b43c5cd5d057_a162ab006210f581743de"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: mikkelfj
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/viCHn56K8jJvHwKTMwQFVdoWvng>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 09 Jul 2018 20:30:09 -0000

@ekr - yes I was just about to post the below as you wrote. I was confused by thinking that you only need 1 roundtrip to have a secret - the DH secret - but that is the inner layer of TLS.

Still hard to follow - but as I read it, the initial keys are used for a few roundtrips. Full encryption with DH exhanged keys would be possible at servers response, but that is not what happens. The outer layer stays weakly encrypted, but the TLS messages are protected until a solid 1-RTT key is forged, which is more production safe than the early DH exchange. Therefore the client is forced to verify that ODCID was received if it wants to complete the handshake.

The AEAD tag cannot be used to strengthen that verification further because the AEAD tag depends on the initial secret and cannot depend on itself.

It would still be safer if the clients AEAD tag were to be stored in the servers TP as an extra precaution because on path attacker could otherwise spoof the initial packet contents knowing the ODCID from plain text. QUIC doesn't generally try to protect from on-path attacks, but that is in regards to service disruption, not loss of integrity. This is worse.

-- 
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/1486#issuecomment-403609915