Re: [quicwg/base-drafts] Add Security Considerations for SRT hash collision attack (#3005)

Kazuho Oku <notifications@github.com> Thu, 05 September 2019 01:38 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 D9BD91208E4 for <quic-issues@ietfa.amsl.com>; Wed, 4 Sep 2019 18:38:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8
X-Spam-Level:
X-Spam-Status: No, score=-8 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_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 2gchieMKlOLH for <quic-issues@ietfa.amsl.com>; Wed, 4 Sep 2019 18:38:50 -0700 (PDT)
Received: from out-24.smtp.github.com (out-24.smtp.github.com [192.30.252.207]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F276A12004C for <quic-issues@ietf.org>; Wed, 4 Sep 2019 18:38:49 -0700 (PDT)
Date: Wed, 04 Sep 2019 18:38:48 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1567647529; bh=9OMirzCFFjTUSqJor7++nA6vbBIImBazrYKI1sDARNk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=miLNIHCbYy6aOTzy6njfS4mS4ApujeQF68S0yHQEPAxDDZ4q89aqJe8ZYNMKPUiFp YEAOIXVLVc/rNItSqlpVvEwGqk7D1kYAf72wy54s+E2S2bEjrpk4JzYHKsycleMBey P4JQiEdNKNsuB8RlqsLvOogFV66ZCbjaNywitlUk=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKZGWZUJIZX2CHOVD7N3PWM2REVBNHHB2JBBPE@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/pull/3005/c528158485@github.com>
In-Reply-To: <quicwg/base-drafts/pull/3005@github.com>
References: <quicwg/base-drafts/pull/3005@github.com>
Subject: Re: [quicwg/base-drafts] Add Security Considerations for SRT hash collision attack (#3005)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d706728f2c5c_43e13fa1342cd96c1165fb"; 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/tccbYUSwvMZbsyCZWvhOVraxKso>
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 Sep 2019 01:38:53 -0000

@ianswett 
> A similar concern exists on the server side for connection ID lookup I believe? Not as much the constant time aspect, but hash collisions.

That's a good point. For most CIDs no, but yes for the server CIDs that are initially chosen by the client. Though, for such CIDs, I think a hash map that uses `client-address-port || CID` as the key should be used for identifying connections, as the collision of CIDs (rather than the collision of hashed values) would be an issue.

We might want to expand on that.

OTOH, I think @martinthomson makes a good point in asking if collision of hashed values (or raw values) in general is something we need to talk. If we are to limit the discussion to how endpoints can fulfill the no-leak requirement regarding stored SRTs, maybe something like https://github.com/kazuho/base-drafts/commit/8908632504a0db7467ea73f05ceb99b0537ee72c would be sufficient.

FWIW, my intent behind creating this PR has been to give advice on how implementations can cope with the requirement, and nothing more.

-- 
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/3005#issuecomment-528158485