Re: [TLS] User Defined Key Pair

Alex Elsayed <eternaleye@gmail.com> Thu, 11 July 2013 21:05 UTC

Return-Path: <ietf-ietf-tls@m.gmane.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578A011E8176 for <tls@ietfa.amsl.com>; Thu, 11 Jul 2013 14:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRZzrwD0K1Cw for <tls@ietfa.amsl.com>; Thu, 11 Jul 2013 14:05:05 -0700 (PDT)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) by ietfa.amsl.com (Postfix) with ESMTP id EADF811E8170 for <tls@ietf.org>; Thu, 11 Jul 2013 14:05:04 -0700 (PDT)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <ietf-ietf-tls@m.gmane.org>) id 1UxO2x-000720-9R for tls@ietf.org; Thu, 11 Jul 2013 23:05:03 +0200
Received: from c-24-17-197-101.hsd1.wa.comcast.net ([24.17.197.101]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Thu, 11 Jul 2013 23:05:03 +0200
Received: from eternaleye by c-24-17-197-101.hsd1.wa.comcast.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Thu, 11 Jul 2013 23:05:03 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Alex Elsayed <eternaleye@gmail.com>
Date: Thu, 11 Jul 2013 13:53:24 -0700
Lines: 54
Message-ID: <krn5vv$qec$1@ger.gmane.org>
References: <CALxQUYGdagDHr+A4EKN5qPD1jZG+dH8PHwb0-fKJVUN_vC1MSg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <CALxQUYGpcKPOAoZ8J56AoUGx8B3JhdmMche8MdQuqD_S=Y22ZQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <CALxQUYF1=oFBk=WZFoey+28j7MV7YvSkAD-YzJSeQ0Dp7uXmEA@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <764a0c52c3800444b69cca4b5b26157c.squirrel@www.trepanning.net> <CALxQUYFwZ8WyFDmCebvLyHoqsOGNBuCaEjiWhZPx0QyExWzcrw@mail.gmail.com> <7648a5048f19c6f255dbc0cc5d7772d5.squirrel@www.trepanning.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: c-24-17-197-101.hsd1.wa.comcast.net
User-Agent: KNode/4.10 rc3
Subject: Re: [TLS] User Defined Key Pair
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: Thu, 11 Jul 2013 21:05:09 -0000

Dan Harkins wrote:

> 
>   Hi Omar,
> 
> On Thu, July 11, 2013 2:42 am, OMAR HASSAN (RIT Student) wrote:
>> Hi Dan,
>>
>> I had a quick look at your work item, and I have some questions:
>>
>> What will be the consequences if the server data has be stolen? will the
>> attacker be able to impersonate as the user?
> 
>   Successfully stealing records from the server's password file will
> enable the thief to impersonate the client (back to the hacked server)
> for all stolen records.
> 
>> How will the password be stored in the server initially?
> 
>   That is completely up to the server.
> 
>> How will you handle TLS termination that is used many websites to
>> centralize the related measurements and protection against the common SSL
>> attacks in one place, and to allow the application firewalls to validate
>> and check the incoming requests for application-level attacks such as SQL
>> injection and cross-site scripting?
> 
>   This is really an operational question. At the risk of sounding flippant
> I guess I'd just say it will be handled in the best way possible.
> 
>   You claim in your draft that "UDKP aims to completely replace the TLS
> protocol." That is a much more ambitious goal and you will need to handle
> these sorts of issues. The tls-pwd draft just defines certificate-less
> ciphersuites that are resistant to dictionary attack (and are better than
> the various PSK ciphersuites) for use with the existing TLS protocol.

<snip>

I'd like to also point out:

TLS-SRP: https://tools.ietf.org/html/rfc5054
TLS-AugPAKE: https://tools.ietf.org/html/draft-shin-tls-augpake-00

Both are:

* Password-authenticated
* Do not involve CAs at all
* Do not allow a compromised server to impersonate the user
    - Zero-knowledge password proofs are rather useful
* Are designed to work with TLS, rather than replace it wholesale

While RFC 5054 is Informational rather than Standards track, it is supported 
by OpenSSL since 1.0.0h and 1.0.1 (https://www.openssl.org/news/news.html) 
and GnuTLS since at least 2007.