Re: [TLS] Another [Well-deserved] attack on TLS CCA

Geoffrey Keating <geoffk@geoffk.org> Tue, 18 June 2013 23:40 UTC

Return-Path: <geoffk@geoffk.org>
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 B75B011E8118 for <tls@ietfa.amsl.com>; Tue, 18 Jun 2013 16:40:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 S9ODsBoBF2GF for <tls@ietfa.amsl.com>; Tue, 18 Jun 2013 16:40:25 -0700 (PDT)
Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2214421E80A5 for <tls@ietf.org>; Tue, 18 Jun 2013 16:40:21 -0700 (PDT)
Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B6CB733D0FC; Tue, 18 Jun 2013 23:40:17 +0000 (UTC)
Sender: geoffk@localhost.localdomain
To: Anders Rundgren <anders.rundgren@telia.com>
References: <51C0A762.9030909@telia.com> <m2obb3qes1.fsf@localhost.localdomain> <51C0DC81.3010908@telia.com>
From: Geoffrey Keating <geoffk@geoffk.org>
Date: Tue, 18 Jun 2013 16:40:17 -0700
In-Reply-To: <51C0DC81.3010908@telia.com>
Message-ID: <m2k3lrq97i.fsf@localhost.localdomain>
Lines: 54
User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: "'tls@ietf.org'" <tls@ietf.org>
Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA
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, 18 Jun 2013 23:40:30 -0000

Anders Rundgren <anders.rundgren@telia.com> writes:

> On 2013-06-18 23:39, Geoffrey Keating wrote:
> > Anders Rundgren <anders.rundgren@telia.com> writes:
> > 
> >> https://sites.google.com/site/oauthgoog/gnubby
> >>
> >> Luckily for all users Google didn't select TLS CCA (Client Certificate
> >> Authentication) for their coming U2F system; only a moron would base a
> >> future consumer authentication system on a scheme that is only suited
> >> for VPN tunnels and invisible authentications like as ChannelID.
> >>
> >> What's missing you may wonder?  Well, how about
> >>
> >> - Compatibility with web sessions including timeout and logout
> > 
> > Logout is a client-side function, and occurs (typically) when the user
> > logs out of their local session and/or quits their web browser.
> > Timeout occurs when the TLS connection is closed due to inactivity
> > (typically 60 seconds) and the session resumption token is expired,
> > which is up to the server; or, looking at it another way, when the
> > user's screen lock triggers due to inactivity.
> 
> Yes, but this is not how most web apps work today for good or for worse.

That's because most web apps require the user to type a password, but
you can't require the user to type a password on every click, so they
only ask the user to enter the password once, and then they have to
maintain authentication status information using cookies (or similar).
Client certificates avoid this entirely; you don't need cookies, you
can authenticate on every request.  This can dramatically simplify the
design of a web app.

At least, that's one way to do it.  If you're doing two-factor, you
can combine this with a password: you still have a session, with
login, logout and timeout, but you also require that every connection be tied
to the client certificate.

> >> - A working credential filtering system
> > 
> > I think this is mostly due to lack of demand.  I wouldn't say it isn't
> > "working", just that as commonly implemented, it isn't very good.
> 
> There is a perceived little demand because many organizations who are big
> users of consumer-PKI have no voice in the IETF.  I believe these guys
> would be slaughtered by the IETF bunch since they don't have exactly the
> same "lingo" and probably don't know very much about inner life of TLS.

Asking at the IETF is definitely the wrong place to start this.  At
present there's no consensus that any protocol changes are required
let alone what these changes might be.  These organizations need to
ask the OS and/or browser vendors for better support, explaining in
detail what they need and why, and those vendors can work with them
and then if necessary do any protocol design under the IETF umbrella.