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

Bodo Moeller <> Wed, 27 November 2013 17:09 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 582A51ADE7C for <>; Wed, 27 Nov 2013 09:09:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.93
X-Spam-Status: No, score=-0.93 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1-XdHoVx0D0v for <>; Wed, 27 Nov 2013 09:09:32 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 074FF1A1F7D for <>; Wed, 27 Nov 2013 09:09:32 -0800 (PST)
Received: from ( []) by (node=mreu3) with ESMTP (Nemesis) id 0LpUcU-1V6cVb3qac-00fOsH; Wed, 27 Nov 2013 18:09:30 +0100
Received: by with SMTP id uz6so7645170obc.37 for <>; Wed, 27 Nov 2013 09:09:28 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=f4zbxkDneb/VfmtJ35J1CVpTLYnMUkE9EPsMqZT7ARs=; b=AJI9JoD0F7QtJHmU48ncf3USEDLYmAhSRZa8Gi5+1653u51rG/zLGvE4tSCrncQiox WJigAtvExx5mX3blNTvjZwNdYvSjit6rfjTQlemUBZa4sS5vFwmwd9+wA1aS9C7UTHee 67Jc4om/GJEC76ukAaOpVPOaBL9bgjvjLfk1+WmcTtvI9ZlUBXMI9cJ3Ry3ioFw7lSE/ 4Fyh+mZv1Y1LxnYM5jpHDiT6G9Ce3hKgvGNZchYD8RjgIUvAP8xZlYfttX9woIHaRSIp cxtSEtA19VsY2SMB7pFGta+BqBK6TlXanfwX7g6mXwsyQkiC0GG69OKY7qHWH7BPE0gA Xs1Q==
MIME-Version: 1.0
X-Received: by with SMTP id p8mr1066699oel.73.1385572168544; Wed, 27 Nov 2013 09:09:28 -0800 (PST)
Received: by with HTTP; Wed, 27 Nov 2013 09:09:28 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Wed, 27 Nov 2013 18:09:28 +0100
Message-ID: <>
From: Bodo Moeller <>
To: "<>" <>
Content-Type: multipart/alternative; boundary=047d7b5d41a6eaba5e04ec2ba842
X-Provags-ID: V02:K0:Z0QypUsLrKH+fvFvWrHVxM2ihuB6Ejk5P0u+XTod4xc 2GBdcu83fESBWiQBvvxvgUhbHDejNgn1UXR0NTbldFNpZBCVsc VfUBaEPVHv1WkhB7wTD9uIJY2o9BpAhKJPSIUz1MsQgCiTNt/g 7AZNtr6l9bBNaDb8OcimhZnc7YZ0ZlFZvGklutM7mcF/WQmsAH 22FhMPKCdoUa4HW0EvLjdXuLjdr4l4JOHCLMkE8wr2qm34v7br yl0JxAuw4VJjK1BHfNrK7JTl2KZrb5S4S8m/YFLLLNKyjgnQVI 4VllKRwu+HphqxX1ZT9QYI9G4AdAdE6FJ1jvQaBcQEhfpnv2lJ damRkj1OP2i+TNW0NIgTDyJ30Gx1pVjcIJC7ToOjDfZxaefeK3 KySCt8lUFCVpr89KJokWG7t+SOvS6V6QPvG1pBEneob+8oRRjl 4xZ+c
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: Wed, 27 Nov 2013 17:09:34 -0000

2013/11/19 Bodo Moeller <>;

> 2013/11/8 Douglas Stebila <>;
>> I believe that where possible the IETF should aim to standardize
>> cryptographic protocols that have provable security results.  Such proofs
>> of course don't guarantee the protocol is secure in all scenarios, but at
>> least rule out some classes of attacks.  In the field of password
>> authenticated key exchange, there are many provably secure protocols, and
>> so it would be preferable to see one such protocol adopted.

> Right.  So there's already an RFC for using SRP in TLS, but it's
> Informational.  Many other such protocols can be found in the research
> literature (and, sometimes, in Internet-Drafts).  If we're picking a
> password-based key exchange for Standards Track, why this one?  What are
> the advantages of this specific protocol over the others?
> From a brief look, one drawback of draft-ietf-tls-pwd-01 besides lack of
> formal security arguments appears to be that it's presumably less efficient
> than some other such protocols ("hunt-and-peck" loop).

Besides the *general* security concerns about this protocol (cursory review
by CFRG doesn't make up for a lack of formal security arguments), here's a
*specific* concern.  (This should be considered "pars pro toto": for all we
know, the protocol could have countless other problems, as isn't uncommon
for cryptographic protocols not justified by format security arguments.)

Given how draft-ietf-tls-pwd-02 specifies negotiation of domain parameters,
I think that a trapdoor-prime attack similar to the one I previously
described for SRP applies (!msg/sci.crypt/JMcCA6FhTDk/e3BKt-CnvQkJ).
 It makes more sense to standardize domain parameters (allowing a selection
of "named groups").  Full flexibility sounds nice at first, until you
realize that it couldn't only be used by legitimate protocol participants
to select groups that they might deem more secure than whatever is
specified, but could also used by an attacker to select particularly bad
groups (in particular if the scenario doesn't provide for any
authentication other than the password-based authentication the protocol is
meant to provide).