Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

CodesInChaos <> Tue, 03 December 2013 12:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8F2FF1AE11E for <>; Tue, 3 Dec 2013 04:19:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id vl195acJLW0V for <>; Tue, 3 Dec 2013 04:19:22 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c00::236]) by (Postfix) with ESMTP id BAF261AE118 for <>; Tue, 3 Dec 2013 04:19:21 -0800 (PST)
Received: by with SMTP id n12so12357858wgh.33 for <>; Tue, 03 Dec 2013 04:19:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=JE/jsSX9GvNMwtAnTK0NZesY6/4Kf/drXhm373VJ8Io=; b=DcmtxG1Qk6ZYjcp5b/ssJEVCYrxc/dN4cQVrZfb3B7VX/v2zIorZ1iMUIBKz4BjdpQ InDidp7WSyInjqoeg2ce67c61r/xaQkmj0weHcBX35LCKJ67rtW3AnoH+Tu2pdvvkFbE QZ2QgeQsvbKn1Sa8DF4qisvRVIgy9LwaShJ2idO770CqknRkspCuF+VsdtZOpP/dzXDr atKXzrp+zaO4A3+/FJM1oj/exjT0JL7zQiBEzUavbG53GGjqs2kM2CYCO54mJLmwJ1tf d6Y0wFCTZbMaDbZWIl3DyKHwmva72mIV9Sy9qmQv1x6nBoTZurv42WEF9FabBinD8VKy ZJsg==
MIME-Version: 1.0
X-Received: by with SMTP id zb4mr6937286wjc.62.1386073158704; Tue, 03 Dec 2013 04:19:18 -0800 (PST)
Received: by with HTTP; Tue, 3 Dec 2013 04:19:18 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Tue, 3 Dec 2013 13:19:18 +0100
Message-ID: <>
From: CodesInChaos <>
To: Dan Harkins <>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 03 Dec 2013 12:19:23 -0000

The protocol uses a fast hash to hash the password.
The challenge-response nature of the protocol means that the sever
cannot apply additional hashing.
This implies that the server needs to store a badly hashed password
which is easy to crack
when the database is compromised. While the information on the wire
doesn't enable an offline dictionary attack,
database leaks are common. So being strong against those attacks is important.

Why did you use a fast hash like HMAC-SHA-256 over a proper password
hash like PBKDF2-HMAC-SHA-256?

Why does the security considerations section not mention password
guessing attacks / offline dictionary attacks against a compromised