Re: [TLS] User Defined Key Pair

Juho Vähä-Herttua <juhovh@iki.fi> Tue, 25 June 2013 21:38 UTC

Return-Path: <juhovh@iki.fi>
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 F112F21F934C for <tls@ietfa.amsl.com>; Tue, 25 Jun 2013 14:38:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level:
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
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 gPScBraQL6fz for <tls@ietfa.amsl.com>; Tue, 25 Jun 2013 14:38:15 -0700 (PDT)
Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84C5F11E8143 for <tls@ietf.org>; Tue, 25 Jun 2013 14:38:14 -0700 (PDT)
Received: from [10.60.82.223] (188.238.211.223) by jenni2.inet.fi (8.5.140.03) id 51BB235B00E27E67; Wed, 26 Jun 2013 00:38:07 +0300
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
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> <CALxQUYH-4HR7sO2jfxQnbro6+xM5hD_hdW-K_a-Esd9yiZ+oug@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> <CALxQUYEeLRxGz=_CO8pMYc4u2rm8u+u6fTiYH_3UMev-pNFC4g@mail.gmail.com>
From: Juho Vähä-Herttua <juhovh@iki.fi>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CALxQUYEeLRxGz=_CO8pMYc4u2rm8u+u6fTiYH_3UMev-pNFC4g@mail.gmail.com>
Message-Id: <A1581412-3469-46AF-8453-E4056097D061@iki.fi>
Date: Wed, 26 Jun 2013 00:37:38 +0300
To: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
X-Mailer: iPhone Mail (10B329)
Cc: Paras Shah <Paras.Shah@riverbed.com>, "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: Tue, 25 Jun 2013 21:38:21 -0000

On 25.6.2013, at 19.55, "OMAR HASSAN (RIT Student)" <omh1835@rit.edu> wrote:
> >Juho Vähä-Herttua:
> >The whole security of the system seems to be dependant on the security of the "browser plugin" and its key generation and encryption algorithms
> 
> I preferred to make the generation of the key pair as a black box, so we can focus our discussion on the idea itself, so the question is if we have a key generation function that can generate key pair securely based on the username, password, and the file selected, would the idea be a good one.

Personally, I would like to find out if it's possible to do securely (key generation function) before judging if it's a good idea or not. I'm defaulting to not a good idea.

> >What if someone detects this enrollment and sends a new public key for the user before the user has time to fill all the fields? Sounds like a race condition to me.
> 
> The key pair generation is done inside the browser plugin interface, not in the website page, so there is no race condition, the communication with the website will start after the creation of the key pair.

Ok. In that case I don't quite understand why the public key is not sent together with the registration, but beforehand in TLS handshake. It sounds like a much better idea to simply send public key instead of the password.

Also, why don't you simply save the encrypted private key to the USB stick? Why is saving random bytes and generating the private key from those more secure?

> Additionally it's not only about custom sign in, it's also about eliminating the dependence on the CA, so the session key must be encrypted with the user public key not encrypted with a key that claims to be the server public key.

It doesn't matter if the premaster secret is encrypted with a client key or a server key, what matters is that it is encrypted with a key that is authenticated one way or another. This doesn't seem to be the case.

The fact is that in your system, I could do a MITM in the registration phase and get you to register my public key with your information, and you wouldn't even notice before you access it from somewhere where I cannot MITM. At that point you would have probably already confirmed your email address etc. and effectively given me tools to impersonate as you.


Juho