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

[Anders Rundgren <[e-mail]>]

On 2013-06-19 01:40, Geoffrey Keating wrote:
> Anders Rundgren <[e-mail]> writes:
> 
>> On 2013-06-18 23:39, Geoffrey Keating wrote:
>>> Anders Rundgren <[e-mail]> 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 fly in the soup is that few if any of the web-server application frameworks
out there like Java Servlets have any information or control over the TLS session.
You'd probably have to program at "MOD-SSL" level or something like that :-)

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

Today VISA and MasterCard authorize credit-card transactions on the
Internet with a "User ID" (card number + other details) together
with a "Password" (CCV) printed in clear (!) on the back of the card.

It is pretty obvious that there is a total disconnect between the
different parties so we are essentially at the mercy of tech giants
like Google who "can think for everybody else".  Google have (with U2F)
indirectly declared TLS CCA as not useful for consumer-auth and that's
about it.

Anders

>