Re: [TLS] User Defined Key Pair

"OMAR HASSAN (RIT Student)" <omh1835@rit.edu> Mon, 24 June 2013 18:27 UTC

Return-Path: <omh1835@g.rit.edu>
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 535F011E8173 for <tls@ietfa.amsl.com>; Mon, 24 Jun 2013 11:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 Vnd3yeUGv5aZ for <tls@ietfa.amsl.com>; Mon, 24 Jun 2013 11:27:17 -0700 (PDT)
Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACB311E816F for <tls@ietf.org>; Mon, 24 Jun 2013 11:27:17 -0700 (PDT)
Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOW00F44TXEWM@smtp-server.rit.edu> for tls@ietf.org; Mon, 24 Jun 2013 14:27:15 -0400 (EDT)
Received: by mail-ie0-f178.google.com with SMTP id u16so24607665iet.23 for <tls@ietf.org>; Mon, 24 Jun 2013 11:27:13 -0700 (PDT)
Received: by 10.43.115.3 with HTTP; Mon, 24 Jun 2013 11:27:13 -0700 (PDT)
X-Received: by 10.43.137.65 with SMTP id in1mr9018760icc.103.1372098433949; Mon, 24 Jun 2013 11:27:13 -0700 (PDT)
X-Received: by 10.43.137.65 with SMTP id in1mr9018757icc.103.1372098433839; Mon, 24 Jun 2013 11:27:13 -0700 (PDT)
Date: Mon, 24 Jun 2013 21:27:13 +0300
From: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com>
Sender: omh1835@rit.edu
To: "Salz, Rich" <rsalz@akamai.com>
Message-id: <CALxQUYF1=oFBk=WZFoey+28j7MV7YvSkAD-YzJSeQ0Dp7uXmEA@mail.gmail.com>
MIME-version: 1.0
Content-type: multipart/alternative; boundary="001a11c2456ebf01c904dfea8f7c"
X-RIT-Received-From: 209.85.223.178
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=zEbpAyKmvz13UxJQKaZ4iF1mLaKmSxGhuHNvne9EWYw=; b=Qr4wfs135fKkdRPzHeGE+96hyWmYtQAD+wj29XuEYhIDPrXczpPGC8jlUMAXvIZS1E 7pJjGvIa/Smse5y+el6WCTBHGJ8ecTm5gE+t2Li+g7GeVkrW83moVoBIGvR08/YaiKWF Qv86cE9CVxPlfFmY4wNxB4Fwt3tOkGP+KuR+HLfVg1MDy7UqW56U72YJA9baELOgCiGJ i1YfEleWPYgTPSlWo81OtKY9qiLpY3sUxTs4tMDnalY6ePCMhhZkmGh5Uw9rFSvGlAbA rpfV9Zz40QgdOnnIAVG5E7aa4jFxV03eEKfLMKZHCggG06yKiVTJzPeYXJxr/lFojMDE BbUw==
X-Google-Sender-Auth: Xa6fDqyREwtAQ_SZIqCqJyHL2Yk
X-Gm-Message-State: ALoCoQn46+ZumgLFLjgMuE9GD2Uahdyt6dpYPFfq/w2zGFw1phH8+sjjsz0cGRDjTHltf2fzQj9YpmTwUwAUSVUnqmZxoEpfVEraIW/haOfefwiuXGE2+PpShdIsEp40cACBcsjP7vJk
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>
Cc: "tls@ietf.org" <tls@ietf.org>
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: Mon, 24 Jun 2013 18:27:23 -0000

Hi Rich,

The security implications is not in the predictably generation of the key
pair, but in the seed length that you will be used to generate the key
pair, in other words it's a matter of it's sustainability against the brute
force attack.

That's why I mentioned three versions of the generate key function,
starting from generating the key pair based on the username, password, and
security question answer pair, and up to having a smart card, or hardware
token that has large enough random seed that will work with the username
and the password as a second factor authentication.

Even in the first case the password must be complex enough, and the each
security question must be follow the best practice of having thousands of
answer for each question, and remember that the question is not leaving the
browser, so the man in the middle attacker will have to try all questions
with all answers.



On Mon, Jun 24, 2013 at 7:33 PM, Salz, Rich <rsalz@akamai.com> wrote:

> **Ø  **On the browser level there should be a plugin that has a function
> to generate the key pair, that function must generate the same key pair for
> the same input parameters.****
>
> ** **
>
> That’s interesting.  This is the first system I’ve heard of that
> predictably generating a keypair is not only a feature, but a requirement.
> ****
>
> ** **
>
> I’m sure that I am not the only person who is bothered by the security
> implications of this.****
>
> ** **
>
>                 /r$****
>
> --  ****
>
> Principal Security Engineer****
>
> Akamai Technology****
>
> Cambridge, MA****
>