Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06

Bjoern Hoehrmann <derhoermi@gmx.net> Thu, 19 February 2015 21:49 UTC

Return-Path: <derhoermi@gmx.net>
X-Original-To: http-auth@ietfa.amsl.com
Delivered-To: http-auth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF321A0270; Thu, 19 Feb 2015 13:49:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 5xw1SZRWcVes; Thu, 19 Feb 2015 13:49:48 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF8AB1A01FA; Thu, 19 Feb 2015 13:49:47 -0800 (PST)
Received: from netb ([89.204.130.64]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0Lx5hl-1XVv7C0Rtx-016kCT; Thu, 19 Feb 2015 22:49:27 +0100
From: Bjoern Hoehrmann <derhoermi@gmx.net>
To: Julian Reschke <julian.reschke@gmx.de>
Date: Thu, 19 Feb 2015 22:49:23 +0100
Message-ID: <p1mcealih31ku7g6oa2h2itidjrumdni1d@hive.bjoern.hoehrmann.de>
References: <874mqjd49v.fsf@alice.fifthhorseman.net> <54E50FC3.9080708@gmx.de> <871tllbw2c.fsf@alice.fifthhorseman.net> <54E6348A.3080606@gmx.de> <87mw49ac9h.fsf@alice.fifthhorseman.net> <54E648B9.6030606@gmx.de>
In-Reply-To: <54E648B9.6030606@gmx.de>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:CD8YhhO+C0BPniJG+IhXnrBF4/jObob23IS3UD8gZ25OYmJKcnT ip6QFn9F/rRZvUXkp/gOWfl5Yz14uiVgVHqoXwZ398vaNSjJ0vkekMsKSRnO/m77PzDqrlX /BiqcKYO/7UaKwvbVl4y5keShMmNY04Fba2SDxTZdWNJELMjt1tgyMtzdKG9/hFtRsHQZlk lx+Y3z9aP/s7sMWBP4OPA==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-auth/YbDcueD5suKbaZBnpcCnPqn23Co>
Cc: "http-auth@ietf.org" <http-auth@ietf.org>, draft-ietf-httpauth-basicauth-update.all@tools.ietf.org, iesg@ietf.org, Daniel Kahn Gillmor <dkg@fifthhorseman.net>, secdir@ietf.org
Subject: Re: [http-auth] secdir review of draft-ietf-httpauth-basicauth-update-06
X-BeenThere: http-auth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: HTTP authentication methods <http-auth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-auth>, <mailto:http-auth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-auth/>
List-Post: <mailto:http-auth@ietf.org>
List-Help: <mailto:http-auth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-auth>, <mailto:http-auth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Feb 2015 21:49:50 -0000

* Julian Reschke wrote:
>On 2015-02-19 21:15, Daniel Kahn Gillmor wrote:
>> On Thu 2015-02-19 14:07:54 -0500, Julian Reschke wrote:
>>> The network exchange will be take milliseconds. The string comparison
>>> microseconds. /me not convinced there's a problem here.
>>
>> as long as the attacker can measure microseconds, and the network
>> exchange has small or regular-enough jitter to be accounted for with
>> statistical techniques, the size difference between these parts doesn't
>> matter to a timing attack.
>>
>>    http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf
>>
>> says:
>>
>>     The resolution an attacker can time a remote host depends on how many
>>     measurements they can collect. Our simulated attacker using
>>     statistical hypothesis testing was able to reliably distinguish a
>>     processing time differences as low as 200ns and 30µs with 1,000
>>     measurements on the LAN and WAN respectively with. (See Section 6.)
>>
>> Note that salted, hashed passwords where the attacker doesn't know the
>> salt are resistant to using a timing oracle like this to do byte-by-byte
>> guessing.  I still think it's simpler to just recommend that the tests
>> should be constant time.
>
>I'm sorry, I'm not convinced. What do others think?

I would prefer to point to an existing document for considerations such
as this one, and I do not think it is entirely obvious for implementers
of the scheme that comparison should take time independent of the length
of the credentials, so including something brief about this makes sense
to me.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
 Available for hire in Berlin (early 2015)  · http://www.websitedev.de/