Re: [TLS] TLS-OBC proposal

Dirk Balfanz <balfanz@google.com> Fri, 02 September 2011 17:20 UTC

Return-Path: <balfanz@google.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 5025C21F8BA7 for <tls@ietfa.amsl.com>; Fri, 2 Sep 2011 10:20:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.143
X-Spam-Level:
X-Spam-Status: No, score=-105.143 tagged_above=-999 required=5 tests=[AWL=-0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_HTML_USL_OBFU=1.666, USER_IN_WHITELIST=-100]
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 DafrSqrsBUKN for <tls@ietfa.amsl.com>; Fri, 2 Sep 2011 10:20:09 -0700 (PDT)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.44.51]) by ietfa.amsl.com (Postfix) with ESMTP id D13B621F8C18 for <tls@ietf.org>; Fri, 2 Sep 2011 10:20:08 -0700 (PDT)
Received: from hpaq14.eem.corp.google.com (hpaq14.eem.corp.google.com [172.25.149.14]) by smtp-out.google.com with ESMTP id p82HLaRP009997 for <tls@ietf.org>; Fri, 2 Sep 2011 10:21:36 -0700
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1314984100; bh=uXw4U2gER5ekVbFWVhJz+oKYAb8=; h=MIME-Version:In-Reply-To:References:Date:Message-ID:Subject:From: To:Cc:Content-Type; b=qf7kVM5ima8IiuI78hOqfQ18ENrd8PKpuFpnoINyuzkAx5XWSTLDpFGcIwFb8hatF TpAklM6uLuUHJjhM7aIHA==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=dkim-signature:mime-version:in-reply-to:references:date: message-id:subject:from:to:cc:content-type:x-system-of-record; b=If3C5FcEaiO9qJP6hdMj97nrGSJ1G2dXoNaDtp9xn3NEEvQA/m1hmZWvHn33GWQIR n6qPdOLzIY685/FUzTe4g==
Received: from ywb5 (ywb5.prod.google.com [10.192.2.5]) by hpaq14.eem.corp.google.com with ESMTP id p82HKmQt003724 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <tls@ietf.org>; Fri, 2 Sep 2011 10:21:35 -0700
Received: by ywb5 with SMTP id 5so3049539ywb.12 for <tls@ietf.org>; Fri, 02 Sep 2011 10:21:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2rAh/xR609jUSgzWAedcYoWvMqwbbWRojOTApgSaGi4=; b=XLFV5sNVp8424l6x82b9JYDRvIeN4umsXTIMHETWe/Wpa01Wy06xsqoATfFq75GWNd ru28EZwlQbi+8Wxj5KRA==
Received: by 10.90.164.17 with SMTP id m17mr1050342age.152.1314984094953; Fri, 02 Sep 2011 10:21:34 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.90.164.17 with SMTP id m17mr1050332age.152.1314984094414; Fri, 02 Sep 2011 10:21:34 -0700 (PDT)
Received: by 10.90.56.4 with HTTP; Fri, 2 Sep 2011 10:21:34 -0700 (PDT)
In-Reply-To: <4E5F71AC.5090900@gnutls.org>
References: <CADHfa2AMOeShxH_k5ZEB3DUVJAnOqvZmLMg5Yz8smtBDGkQsNg@mail.gmail.com> <4E5F71AC.5090900@gnutls.org>
Date: Fri, 2 Sep 2011 10:21:34 -0700
Message-ID: <CADHfa2Ad2dU5FkaDjZA6Hn+gnp_crf6Phw9eJMqfg8gd9Kdeyw@mail.gmail.com>
From: Dirk Balfanz <balfanz@google.com>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: multipart/alternative; boundary=0016362846b4d5367f04abf8978c
X-System-Of-Record: true
Cc: tls@ietf.org
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: Fri, 02 Sep 2011 17:20:10 -0000

On Thu, Sep 1, 2011 at 4:51 AM, Nikos Mavrogiannopoulos <nmav@gnutls.org>wrote;wrote:

> 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<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)
>

The site where I wrote the documentation - browserauth.net - is an example
for this. There is a sign-in link at the bottom of each page. Are you saying
that with TLS Client Auth, the server would require a certificate from the
client, and the user would have to decide upfront whether or not to supply a
certificate. Then, when the user gives no certificate or a "wrong"
certificate, there would be no sign-in link on the site (but it would still
render), but when the "right" certificate is given by the user, then the
server would give the user a sign-in link on the page? At that point, the
sign-in link isn't really about signing in. It's more a "you already know
who I am, please give me some edit controls on this page"-link. Also, note
that the user had to decide whether or not to provide a certificate before
they saw the page.

With TLS-OBC, you have the normal cookie model. The first time you go to the
site, you have no cookies. It's up to the server to decide whether or not it
can give you a meaningful UI in that case (browserauth.net decides that it
can). Then, when it's time to reveal to the server who you are, you click on
the sign-in link, and eventually end up with a cookie that you send to the
server, which will allow it to identify you, and draw a "logged-in" state
UI.

I totally agree that this a UI issue - a pretty subtle one. But I think that
TLS Client Auth will dictate a different UI from what we're used to today,
whereas TLS-OBC with cookies will allow us to stick to the same UIs we have
today.


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

The critical extension is there so that these certificates can't be used out
of context. For example, we require the server to check that the extension
is there, or else reject the certificate. We should fix the IA5String. I
forget why we picked that - I think it was something like Adam Barth's web
origin spec not defining a UTF8 serialization of web origins when we wrote
our draft or something like that. I agree it should allow unicode.

A separate question is whether that string (the origin) should be in the
cert to begin with. I take it that your inclination would be to not include
it, which is what I'm also considering now.

Dirk.



>
> * 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
> ______________________________**_________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/**listinfo/tls<https://www.ietf.org/mailman/listinfo/tls>
>