Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)

Antoine Delignat-Lavaud <notifications@github.com> Thu, 05 March 2020 17: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 9693E3A081A for <quic-issues@ietfa.amsl.com>; Thu, 5 Mar 2020 09:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.1
X-Spam-Level:
X-Spam-Status: No, score=-3.1 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, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, 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 FMNBMmxD2x6I for <quic-issues@ietfa.amsl.com>; Thu, 5 Mar 2020 09:46:53 -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 3CB3E3A0848 for <quic-issues@ietf.org>; Thu, 5 Mar 2020 09:46:53 -0800 (PST)
Received: from github-lowworker-56fcc46.va3-iad.github.net (github-lowworker-56fcc46.va3-iad.github.net [10.48.102.32]) by smtp.github.com (Postfix) with ESMTP id 5CA8726164F for <quic-issues@ietf.org>; Thu, 5 Mar 2020 09:46:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1583430412; bh=5uyY1z542Sa+88hbXv+xzuPL1/3PHBbJjDfOtyRkikg=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=mqrf/QE3EaTdAOQNiZ+SxZqF5xS31FvXvFo6sgbLClRtUf7+vJpHkBcKoZxwI6S1f erpgGaYqKctoxaQwfiav7BdhLTr56tmcD1d0gyEIT3PqSQ8QICJmlga8Xs6gUGC8EQ QgeJO2501JpKSgA740vPgOsnlAYDtS2VqE3n+2YU=
Date: Thu, 05 Mar 2020 09:46:52 -0800
From: Antoine Delignat-Lavaud <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK7ZIJMYMPRGPM75AHN4NUOAZEVBNHHCC4LIRI@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3439/595358978@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3439@github.com>
References: <quicwg/base-drafts/issues/3439@github.com>
Subject: Re: [quicwg/base-drafts] Authenticating connection IDs (#3439)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e613b0c177b0_586e3fe0c30cd968890e2"; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ad-l
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/sDIFqMxvYELcDwh-F9Ts9-Il_tw>
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: Thu, 05 Mar 2020 17:46:56 -0000

> @marten-seemann suggests that forcing a change of connection ID at the server (always? only when there is no Retry?) would be sufficient because all an endpoint needs to do is ensure that the choice they made is retained. I would like to see what @ad-l thinks of that.

It seems a bit brittle to me, for instance it doesn't prevent post-retry adversarial forwarding to a different server with the same token key, which could be used for downgrade as @mikkelfj pointed out. It would play out like this:

```
C->S1 INIT[dcid=X]
S1->A RETRY[token=T,scid=X']
A->S2 INIT[dcid=X]
S2->A RETRY[token=T',scid=Y]
A->C RETRY[token=T, scid=Y]
C->S1 INIT[dcid=Y, token=T] ...
```
That's not a very strong attack by any means but still makes me somewhat uncomfortable.

> If we are to fix this, my choice would be to document the issue and observe that servers can fix it by tying the retry token to their proposed CID. That would implicitly solve Google's issue.

That is also kind of OK but difficult to specify as a requirement - how would implementers interpret something like "you must bind the retry token to the proposed CID"? In practice, they should do something like use the CID as part of the nonce of the ticket encryption, or store it in the stateful token database. Unsurprisingly, I much prefer a mechanism that cryptographically guarantees that the CID is authentic because there is no way for a honest and compliant client to know if the server implements the correct check (the same argument as for the use of the client 1-RTT key before checking the client finished)

-- 
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/3439#issuecomment-595358978