IETF Logo Mail Archive

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

Bodo Moeller <bmoeller@acm.org> Tue, 19 November 2013 11:38 UTC

Return-Path: <SRS0=DFJz=U4=acm.org=bmoeller@srs.kundenserver.de>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 751691ADEA3 for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:38:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.454
X-Spam-Level:
X-Spam-Status: No, score=-1.454 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.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WmQGf6gCpz7e for <tls@ietfa.amsl.com>; Tue, 19 Nov 2013 03:38:38 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.126.171]) by ietfa.amsl.com (Postfix) with ESMTP id 1A65D1AD8D8 for <tls@ietf.org>; Tue, 19 Nov 2013 03:38:38 -0800 (PST)
Received: from mail-oa0-f45.google.com (mail-oa0-f45.google.com [209.85.219.45]) by mrelayeu.kundenserver.de (node=mrbap3) with ESMTP (Nemesis) id 0LaUDn-1VGZTt3ARL-00lotF; Tue, 19 Nov 2013 12:38:31 +0100
Received: by mail-oa0-f45.google.com with SMTP id o6so2252016oag.32 for <tls@ietf.org>; Tue, 19 Nov 2013 03:38:29 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=4jr6GZmhEs68WRhJWGyphnj6+KfCEKr4NU0zBgnke/Q=; b=FTRmL2dRU7y1c2nAZ0FLutiLLXjiozBoZ5rpfvTNtkxldjasVJILS99GkaqmfwaetT PrPqMDZxaXWMDs4epDxl20rUa3x8XiF8Pu4rk/dkZWqTIUI2Dmq0Z9nG3vf1zmI2OXj1 I65tzJhgniD9s97v7lhRrEILc8LBNksby8TxrwGvqiI6J+P/lM5WpIyr8+6WZN3nqG0r P3VFFM0zm1sSyhWyY3K8Koy0bQlbqworO1q+T4VTYJ5d8v6DO+STbP7rNhkvj+qyMVlB RPJEAsf3GCfnrttOjWRnrYCXigHkD5Ae53GZNC/sO6bYWQfX8iWBqSlaB/XMYqa/4eMY TP8g==
MIME-Version: 1.0
X-Received: by 10.182.247.68 with SMTP id yc4mr329131obc.67.1384861109506; Tue, 19 Nov 2013 03:38:29 -0800 (PST)
Received: by 10.60.137.194 with HTTP; Tue, 19 Nov 2013 03:38:29 -0800 (PST)
In-Reply-To: <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au>
References: <3065D910-832C-47B6-9E0B-2F8DCD2657D2@cisco.com> <9CD5611C-2742-435D-8832-9F85448591BA@qut.edu.au>
Date: Tue, 19 Nov 2013 12:38:29 +0100
Message-ID: <CADMpkcJ3wO_GMsSH33B8fQKnnr=nAUdU58bwSkks4ERF9ccAJw@mail.gmail.com>
From: Bodo Moeller <bmoeller@acm.org>
To: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e015384d67f26af04eb861a28"
X-Provags-ID: V02:K0:XvEi0m2EQ1hI6o1WhCEfNmotIjm7qyq0n9v91HuRUQg Ee6ExVEBtKeLzSSWyOxu3eRizkfijSWAiDzRQdEY/bTYRk9ShP aJdmtOcAt7o5FwznNA+g8LkXAaAL3+jKephi1P+cHdzctrX7vg aV7HFfhRYdjg2u6cvCjXKqcNFVXFl9bPCBiAf5AqwnoCQqxmqw OJV3cfy4qVjQ4Mvek104xVkhGYZOeDfEMLwFjkV2y+a6Xqwtpw 33kj2GMPR2e6GyEY0d9PM/MXTfaQu6sp8JyD6Pe700x307oR30 aHo5LjcOkwux3eBtqNb1riZIiVZSLqPTGYRgido3f5JYeRHk4r 5oTlxdCX/Zb/rknyzCYQAAI0PLGgvGYZP+Np9sq7Lje/fOTu2U bJbw5FFxtPa4fHA2YnEqEVMP6Z2pG7BD77mKkK7lOcEKlX0mnE 3dQdb
Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Nov 2013 11:38:39 -0000

2013/11/8 Douglas Stebila <stebila@qut.edu.au>

> 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).

Bodo

v2.23.0 | Report a Bug | By Email