Re: [TLS] TLS-OBC proposal

Nikos Mavrogiannopoulos <nmav@gnutls.org> Thu, 01 September 2011 11:49 UTC

Return-Path: <n.mavrogiannopoulos@gmail.com>
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 F2D1921F8BF9 for <tls@ietfa.amsl.com>; Thu, 1 Sep 2011 04:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.562
X-Spam-Level:
X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, 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 d3MBk2GpLbSO for <tls@ietfa.amsl.com>; Thu, 1 Sep 2011 04:49:41 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFD0321F8BEF for <tls@ietf.org>; Thu, 1 Sep 2011 04:49:40 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1456442wyg.31 for <tls@ietf.org>; Thu, 01 Sep 2011 04:51:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=6hCnb7MIKN8jTnKpdVQjVidjih8hz07Bd/38diXK28s=; b=dVXk5OV6cbEat//3gpDl3iaGnKb9k6oR3mLNwvW8/wkea1kWCHRqgcVf6XNXsO1dFh AadI60P9LSXERXwqNMDa+omGUUTyh9amX1Z50EmRalEWExHzqgz28TRoJItdRXjk6yzY KEvO2gfbCR8vOR8XqhQr8QXkIhpkmFZJpAg3M=
Received: by 10.216.176.17 with SMTP id a17mr80874wem.72.1314877869260; Thu, 01 Sep 2011 04:51:09 -0700 (PDT)
Received: from [10.100.2.14] (94-225-167-75.access.telenet.be [94.225.167.75]) by mx.google.com with ESMTPS id p18sm449181wbh.4.2011.09.01.04.51.07 (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 04:51:08 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <4E5F71AC.5090900@gnutls.org>
Date: Thu, 01 Sep 2011 13:51:08 +0200
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.20) Gecko/20110820 Icedove/3.1.12
MIME-Version: 1.0
To: tls@ietf.org
References: <CADHfa2AMOeShxH_k5ZEB3DUVJAnOqvZmLMg5Yz8smtBDGkQsNg@mail.gmail.com>
In-Reply-To: <CADHfa2AMOeShxH_k5ZEB3DUVJAnOqvZmLMg5Yz8smtBDGkQsNg@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS-OBC proposal
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, 01 Sep 2011 11:49:42 -0000

On 08/22/2011 07:53 PM, Dirk Balfanz wrote:
> Dear TLS-WG,
>
> I few weeks ago I presented a proposal for an "origin-bound certificates"
> TLS extension at IETF 81. It's much easier to understand what this extension
> is trying to accomplish when presented in a broader context of web
> authentication (which I tried to give in Quebec), so I put together a little
> web site that is supposed to do just that for those who couldn't be at the
> IETF meeting: http://browserauth.net (This took me a little while, hence the
> delay in sending out the I-D).
[...]
> All feedback is welcome, of course, but if you can't think of anything to
> comment on, I have a couple particular questions:

I like the proposal. As far as I understand you try to fix the usability 
problem of using multiple certificates for different sites. This is 
similar to an SSH-style authentication for users. As a side-effect 
pseudonymity can be achieved. Some minor comments.

* In http://www.browserauth.net/tls-client-authentication you mention 
the inability to log-out as one reason that TLS client authentication 
fails. However this is not addressed by OBC if I understand correctly. 
(to be honest I think that the inability to log-out is just a UI 
problem. TLS authentication does not need to imply log-in. You might 
have buttons login and logout that will log the user in and out even if 
TLS with authentication was used)

* Why you require a critical X.509 extension for that? (I also don't 
like the IA5String... why not UTF8?)

* After having read the proposal the name OBC was clear to me. However 
before reading it, the name didn't give any clue (to me) of the proposal.

> - in Section 2.1.1 we currently stipulate that the client include the origin
> of the origin-bound cert as part of the OBC X.509 extension. When we
> implemented this, we didn't really know what to do with that data on the
> server side. If the client also uses TLS-SNI, then we could imagine
> comparing the SNI and OBC origins in some manner on the server side, but
> there isn't really a vehicle to signal an error back to the client saying
> "your SNI and OBC origins don't match". Similarly, we could perhaps at some
> higher layer compare the HTTP "Host" header with the OBC origin, but then
> again - what do you do when they don't match?

I'd send a TLS alert or do nothing. What does this check add?

> Respond with a 400 at the HTTP
> layer? An alternative to the current language in the I-D would be to simply
> mark the cert as origin-bound, but without putting the origin itself into
> the cert. Any thoughts?

I don't like having the origin in the certificate as a critical extension.

regards,
Nikos