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.
- [TLS] Another [Well-deserved] attack on TLS CCA Anders Rundgren
- Re: [TLS] Another [Well-deserved] attack on TLS C… Adam Langley
- Re: [TLS] Another [Well-deserved] attack on TLS C… Anders Rundgren
- Re: [TLS] Another [Well-deserved] attack on TLS C… Nico Williams
- Re: [TLS] Another [Well-deserved] attack on TLS C… Anders Rundgren
- Re: [TLS] Another [Well-deserved] attack on TLS C… Geoffrey Keating
- Re: [TLS] Another [Well-deserved] attack on TLS C… Anders Rundgren
- Re: [TLS] Another [Well-deserved] attack on TLS C… Geoffrey Keating
- Re: [TLS] Another [Well-deserved] attack on TLS C… Anders Rundgren