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

Watson Ladd <> Thu, 05 December 2013 17:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 302D21ADE84 for <>; Thu, 5 Dec 2013 09:41:24 -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 RtuH_FFFFCx0 for <>; Thu, 5 Dec 2013 09:41:21 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c05::22c]) by (Postfix) with ESMTP id 18AAE1AE03A for <>; Thu, 5 Dec 2013 09:41:20 -0800 (PST)
Received: by with SMTP id en1so23584wid.11 for <>; Thu, 05 Dec 2013 09:41:17 -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=amSxRIGJNGRAUjs0x9LQrvAYL2yhz9KGGrtaGkWuZw4=; b=mlkZrLb6jIMXMWqqT4OboZJX7PNYhE8hmvO5LfWqfyeht9LWsADN0jdFjEDIz9V6my X0HSftGVvImIlg5VsJMNBiZvvOWo6vmyOxGN0XbPnPuJitoLCxB8WW2ULdrv+dkVUbw+ 9XnmzqqbHklg9HltcwpBsInEHoF/WCT9pfQFiCTpxHNML3Q9J9CC4W+McXrwFmTrDuUj ekM8UPYiNKK1yhViQzie+NLGWxuxPmTQAthxXr0ZnhbcRPx/4xJdDz7DTwQ3gfdoDjsw pKk5o6Gn3rqo3DKJDkClt8iioubGLtSebz+z7bhs9xhcYhPTMhQyaFuA3rdF3dcgVtux jGBw==
MIME-Version: 1.0
X-Received: by with SMTP id k18mr13126719wic.44.1386265277258; Thu, 05 Dec 2013 09:41:17 -0800 (PST)
Received: by with HTTP; Thu, 5 Dec 2013 09:41:17 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <> <> <> <>
Date: Thu, 5 Dec 2013 09:41:17 -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: Thu, 05 Dec 2013 17:41:24 -0000

I disagree with the summary of my position.
TlS-SRP is deployed and implemented now. It can be used freely by
everyone, because the patent is freely licensed.
It has been a part of the TLS standard for years.

There are PAKE protocols with security proofs. It is not unreasonable
to demand that a new PAKE meet the standard which existing
protocols have set. A ZKPK on a hash of the temporary Diffie-Hellman
key+the password is perfectly fine, but quite computation heavy.
But for the examined use case computation work isn't a problem:
embedded devices don't handle thousands of connections.

The history of authentication protocols is littered with protocols
believed secure by their creators which were flawed, only for
the flaws to be discovered years later. Wide-Mouth Frog, early
Kerberos, station-to-station protocol, the various Tor key exchanges,
etc. As a result it is reasonable to demand a proof of any new
protocol in this field, especially when once in the standard it will
take years
to remove if a problem is found.

Dragonfly isn't secure in the sense that there exists an algorithm
that carries out an offline guessing attack. I can't provide the
it depends on a bunch of numbers which are the discrete logarithms of
the various PKEs in the terminology of dragonfly. But it exists,
meaning that stating what it means for dragonfly to be secure is
beyond our current knowledge. (Hash functions suffer from this also,
but in practice this can be worked around) In particular, there are
some random oracles for which dragonfly is broken (namely ones which
jigger the point picking process).

Users depend (unwisely, given the history of this WG) on TLS to be
secure above all else. Arguing that the processes previously existing
in the WG has not provided this guarantee is arguing for increased
scrutiny, not less. Adding complexity to TLS has a cost in making
implementations larger and harder to audit, as well as introducing all
sorts of ways to have misconfiguration. We should only introduce
new options when they satisfy usecases existing ones do not.

What does Dragonfly offer over J-PAKE? What does Dragonfly offer over
SRP? Are these benefits worth losing the benefit of security proofs
and years of analysis? And why isn't J-PAKE suitable for your usecase?
Watson Ladd