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

Trevor Perrin <> Thu, 05 December 2013 22:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DD6861AE21D for <>; Thu, 5 Dec 2013 14:14:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.208
X-Spam-Status: No, score=-1.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_WEB=0.77] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id BN5Z6pSxWL1J for <>; Thu, 5 Dec 2013 14:14:07 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2207E1AE218 for <>; Thu, 5 Dec 2013 14:14:06 -0800 (PST)
Received: by with SMTP id z12so16985736wgg.3 for <>; Thu, 05 Dec 2013 14:14:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=NfozyQZFZSsRIF2o7f+LDcuoj9FsT9Ty2jwypLCK6SA=; b=W1hkVHhYjOL2vkshPdoiFVMf+0V7cyDCXXww9HOZ0SGPkbYhT+yORed2vqTQ8YJQHE p4HCg4NPVYplrV3oMf3h6IFzgOTSskBUcbv7zur1sGhgPMxVOqbqIX5fu/GNmHulh6O5 Op0BmXmaggvO8KSnihGEZLhF6B/0TCp5VY3b/BGU5qf7I0UzStm6XFPURb1O61a0jApr 8QMkC6bnRzGzGreVVQQD+mZPPtJ8y5J/u5GSGaRKXv9gPhsfXecX00kMEUNSWnY/fVZW n9geCxhAdRxloZ/J55kKAVjvJ4jFxid9OC3xW3Afrmf4MIs5nRAim9xtMjFUowgIGo8r cpWA==
X-Gm-Message-State: ALoCoQmunaoxif/A+aSZvjjSR/OQOjSaeILQzKlYRX8WDvVrJlqfMUOUDkFR+51fmB1hAJCQADrq
MIME-Version: 1.0
X-Received: by with SMTP id gc2mr1613722wjb.75.1386281643163; Thu, 05 Dec 2013 14:14:03 -0800 (PST)
Received: by with HTTP; Thu, 5 Dec 2013 14:14:03 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 5 Dec 2013 14:14:03 -0800
Message-ID: <>
From: Trevor Perrin <>
To: Dan Harkins <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
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: Thu, 05 Dec 2013 22:14:09 -0000

On Thu, Dec 5, 2013 at 1:13 PM, Dan Harkins <> wrote:
> On Thu, December 5, 2013 12:42 pm, Trevor Perrin wrote:
>> On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins <> wrote:
>>>   Yes I am aware that the original EKE patent expired. But EKE cannot be
>>> used with elliptic curves.
>> Not true, for example see Hamburg and Bernstein's Elligator 2 [1],
>> which could be used as the basis for a DH-EKE style PAKE.
>   Now THAT is an interesting alternative.
>   But, alas, the benefit of doing that is uncompelling to you so I don't
> know why you mention it. According to you the cryptographic difference
> provided by EKE using Elligator public keys has nothing to do with the
> architectural differences that you insist are behind the disinterest
> (according to you) of PAKE protocols in TLS.

That's true.  I wouldn't support any PAKE for TLS without some new
interest from TLS implementors.

But if that interest existed, and a PAKE could be integrated into a
TLS handshake in a way that hides the client's username; is simple,
efficient, and secure; and is "state-of-art" relative to alternatives,
that could be worth considering.

>> We should not standardize protocols which are inferior to existing
>> ones and to newer alternatives, have insufficient cryptographic
>> analysis, have no application, and have no support in the WG beside
>> the draft authors and the NSA [2].
>   That is just pathetic FUD and a really lame smear. You should be
> ashamed of yourself.

I reviewed the TLS and CFRG mailing lists, and while I found a great
deal of criticism of this draft, the only positive feedback I could
find, prior to Mohamad, was from Kevin Igoe, NSA employee and CFRG
chair [1,2].  I presume Kevin also provided the "verbal report" to our
chairs that CFRG considers this satisfactory.

I find Kevin's enthusiasm strikingly at odds with other expert review
(compare [1,2] vs. this entire thread).  Furthermore, it's well-known
that Kevin's employer expends considerable resources to "Influence
policies, standards, and specification" for commercial cryptography to
make it more "tractable" to cryptanalysis [3].

In these lights, I find Kevin's feedback a source of concern.