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

Watson Ladd <> Fri, 06 December 2013 07:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E50EE1AE308 for <>; Thu, 5 Dec 2013 23:24:10 -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 zrGt5eeA5bzJ for <>; Thu, 5 Dec 2013 23:24:08 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22f]) by (Postfix) with ESMTP id ABBFD1A1F54 for <>; Thu, 5 Dec 2013 23:24:07 -0800 (PST)
Received: by with SMTP id hi5so438655wib.2 for <>; Thu, 05 Dec 2013 23:24:03 -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=zjB3w+uBby0RcBwNZ00yOCOWiHB5Csaj/+4p1J1I9pw=; b=OEtwYqVtJayPUYI5MShje5/cIiMi1J/NeZEJyJO1FFNNoOU9Xm0R271hJC0XAIapAY 5PUG4ZECNDwXHnhGXGE2xmaL9uefJ04dMwYd8BaNFWr/RmFs3X5+3/nY3m3NZ8UQaO0X axR0vpiklSbefpTCKrQNQ+IZh+HX8EhgFWqbbGEaOXXa2B3enkpCAQ+DPByNHdQP+khZ IyuQ5uKt3hvGs11+OmiAJb9LXzW2w+3D66iapBOIxVgbou3ioDuSbT5s7WB/eti5OgNg VMHIwLt8+mpsKcTRnUiWDup/49WGoG6ReAJI0WDWGn8EUPsSx6hlIzgkmnt+zvphb3v+ VL/Q==
MIME-Version: 1.0
X-Received: by with SMTP id f11mr1643913wjz.14.1386314643443; Thu, 05 Dec 2013 23:24:03 -0800 (PST)
Received: by with HTTP; Thu, 5 Dec 2013 23:24:03 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Date: Thu, 5 Dec 2013 23:24:03 -0800
Message-ID: <>
From: Watson Ladd <>
To: Dan Harkins <>
Content-Type: text/plain; charset=UTF-8
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: Fri, 06 Dec 2013 07:24:11 -0000

On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins <> wrote:
> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
>> On Thu, Dec 5, 2013 at 9:15 AM, Dan Harkins <> wrote:
>>> On Thu, December 5, 2013 3:48 am, Bodo Moeller wrote:
>>>> Dan Harkins <>rg>:
>>>> The exchange was reviewed by the CFRG with, as Joe noted, satisfactory
>>>>> results.
>>>> While it is true that Joe noted that, I think the point of the present
>>>> discussion is that the protocol wasn't actually reviewed by the CFRG
>>>> with
>>>> satisfactory results.
>>>   No, that's not really true.  There is a difference between "your
>>> protocol has
>>> not been proven secure" and "your protocol has a security flaw". And
>>> while
>>> the former has been pointed out on this list and the CFRG list, the
>>> later
>>> has not.
>> Yes, it has.  Bodo pointed out a security flaw.
>   You should read the entire email before you respond to it. Like the
> very next 6 lines.
>>>   You have pointed out an issue with using an in-band server-provided
>>> domain parameter set and I'm going to address that in a subsequent
>>> version.
>>> That's not really a flaw in the key exchange, it's how the key exchange
>>> has
>>> been inserted into TLS and it can be addressed by some text rewrite. I
>>> am genuinely thankful for your comment and I will address it in a
>>> subsequent version.
>>>   The present discussion on the list boils down to these subjects:
>>>   1) there's no security proof and that is unacceptable (Rene, Watson)
>>>   2) there's nothing special about this protocol so why don't you (being
>>>       me) spend your time working on something else that we (Rene,
>>>       Watson) think is better.
>>>   3) the TLS-pwd benefits and your use cases are not compelling to
>>>       me (Trevor).
>>> The response to #1 is that security proofs have never been required
>>> and we have standards-track protocols today that are susceptible to
>>> offline dictionary attack (every PSK cipher suite). So it's an appeal to
>>> a
>>> process that does not exist.
>> At Watson points out, times have changed and the bar is higher now.
>   You are appealing to a process that does not exist.
There is no set process for getting things through a WG. Checking
boxes will never make
up for a lack of substance. This argument seems to be that because we
made mistakes in
the past, we can't avoid making them in the future. The process you
seem to think applies
did not prevent RC4, implicit IVs, MAC-pad-encrypt, downgrade attacks,
or the parser complexity
responsible for many security vulnerabilities.

I don't see why demanding security reductions in some acceptable model
is so onus a requirement.
If it means we are unnecessarily conservative, I'm fine making that
tradeoff. If this means that
no changes to TLS get made because no one wants to do the work to get
me to approve, I'm fine with
that. We have a working TLS ecosystem right now for some definition of
"working", namely Suite B. We still
don't have secure code implementing TLS on all CPUs.
That took 20 years, and still isn't widespread. Jeopardising that is
not worth a yet another PAKE.
>>> The response to #2 is that lack of implementation of these other
>>> protocols has been hampered by patents
>> See the discussion around SRP that occurred when you first presented
>> this.  Any patent FUD which *might* have existed, once, has expired:
>   Yes I am aware that the original EKE patent expired. But EKE cannot be
> used with elliptic curves. Now I know elliptic curve support is not a
> compelling use case for you but, again, so what?
>> Additionally, developments such as Elligator and AugPAKE hold promise
>> for protocols that have both security proofs *and* no IPR encumbrance.
Just because one particular protocol is patented does not mean others aren't.
J-PAKE is going through the CFRG, works with ECC, and has a proof. Why couldn't
you use that instead? (yes, it does incur an additional round.)
You could use a key hiding authentication system and generate a key
from a password.
You can use any multiparty equality computation protocol.
All of these are more acceptable to us than something that doesn't
even have a formal
statement of security claims, let alone a proof. What do you mean that
Dragonfly is
secure? Because for many random oracles it isn't.
>>> The response to #3 is: so? There is rarely uniformity in viewpoints
>>> as everyone's experience is different. Now there's a choice and if
>>> the benefits of one are not compelling then be happy you can
>>> choose the other.
>> The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
>> has nothing to do with this draft's cryptographic differences.  It has
>> to do with architectural issues with the approach, which your draft
>> does not improve on.
>   You are free to not use this protocol as well if you do not find it
> compelling.
The problem is that people faced with the choice of TLS-SRP and TLS-PWD
will not be aware of the relevant tradeoffs, and make the *wrong
choice*. The goal
of this WG is not to provide a choose your own adventure, where mistakes lead to
other people reading your passwords. There is tremendous pressure on TLS
implementations to implement objectively bad ideas that are part of
the standard,
and it is quite hard to get rid of them.

Take your financial institution, and see what gets negotiated with your browser.
And you want to give the people responsible for that more ways to
shoot themselves in the foot?
>   Dan.
> _______________________________________________
> TLS mailing list

"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin