Re: [TLS] TLS-OBC proposal

Nikos Mavrogiannopoulos <> Thu, 01 September 2011 11:49 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F2D1921F8BF9 for <>; Thu, 1 Sep 2011 04:49:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.562
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id d3MBk2GpLbSO for <>; Thu, 1 Sep 2011 04:49:41 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id EFD0321F8BEF for <>; Thu, 1 Sep 2011 04:49:40 -0700 (PDT)
Received: by wyg8 with SMTP id 8so1456442wyg.31 for <>; Thu, 01 Sep 2011 04:51:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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 with SMTP id a17mr80874wem.72.1314877869260; Thu, 01 Sep 2011 04:51:09 -0700 (PDT)
Received: from [] ( []) by with ESMTPS id p18sm449181wbh.4.2011. (version=SSLv3 cipher=OTHER); Thu, 01 Sep 2011 04:51:08 -0700 (PDT)
Sender: Nikos Mavrogiannopoulos <>
Message-ID: <>
Date: Thu, 01 Sep 2011 13:51:08 +0200
From: Nikos Mavrogiannopoulos <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110820 Icedove/3.1.12
MIME-Version: 1.0
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] TLS-OBC proposal
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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: (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 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.