Re: [TLS] Should TLS 1.3 use an augmented PAKE by default?

[Anders Rundgren <[e-mail]>]

On 2014-03-19 16:43, Andy Lutomirski wrote:
> On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi <[e-mail]> wrote:
>> On Tue, March 18, 2014 2:55 pm, Andy Lutomirski wrote:
>>>  On 03/18/2014 02:13 PM, Daniel Kahn Gillmor wrote:
>>>>
>>>> Hi Andy--
>>>>
>>>> Thanks for raising this question.
>>>>
>>>> On 03/18/2014 02:11 PM, Andy Lutomirski wrote:
>>>>> 1. When clients authenticate with a password, if they send their
>>>>> password to the wrong server, that server learns their password.
>>>>
>>>> I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN,
>>>> right?  Other authentication mechanisms that are layered on top of TLS
>>>> don't necessarily have the same concern.
>>>
>>>  As far as I know, pretty much all authentication methods that layer on
>>>  top of TLS either have this problem or are, at the very least,
>>>  vulnerable to dictionary attack by a rogue server.  Getting secure
>>>  augmented password-based authentication right is tricky, and I think
>>>  that TLS should offer this service.
>>>
>>>>
>>>>>  This
>>>>> is the basis of most phishing attacks.  (I'm ignoring TLS-SRP, which is
>>>>> basically unused.)
>>
>> Since you raised "phishing" as your concern, I'm entirely responding
>> within the context that you're talking about user-facing actions within
>> the context of a web browser. I have yet to hear of a good mail client
>> "phishing" attack (you *are* validating your IMAP certs, right?), so this
>> seems almost predominantly an issue of attacker-controlled UI - that is,
>> the web.
>>
>>>>
>>>> TLS SRP's lack of use suggests that there is not a high pressure for
>>>> deployment here.
>>>>
>>>> It's probably worth thinking some about why SRP adoption has been so
>>>> slow (i don't know the global answer here, but i only know a few folks
>>>> who are using it)
>>>
>>>  I'd guess it's a chicken-and-egg problem.
>>
>> No. It's really not. It's a usability problem, and one that doesn't get
>> solved easily.
>>
>> It's not unique to TLS-SRP. It's just as applicable to TLS client
>> certificates.
>>
>> Browsers don't want it:
>> - It requires the browser implement a special (trusted) UI, since by
>> definition, it's the browser's responsibility to terminate TLS
>> connections.
> 
> I think that browsers should do *exactly* this.  There's already one
> for the lock icon -- adding one for password entry seems like a
> natural extension.  Even better: users who use such a thing don't need
> to be nearly as careful about checking the actual URL before entering
> their password.

You want something like this?
https://communities.intel.com/community/itpeernetwork/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display

Petty yucky stuff IMO.

Anders

> 
>>
>> Sites don't want it:
>> - Sites don't want to force browser UI on their users, they want to
>> control and customize the UI. They want to handle failures, not rely on
>> browsers that may or may not handle errors in the manner in which they
>> desire.
> 
> This can be fixed.
> 
>>
>> Users don't want it:
>> - Users *like* sites' form-based authentication. It integrates easily with
>> their mental model, provides easy avenues for trouble-shooting ("forgot my
>> password", etc).
> 
> You're assuming that an augmented PAKE with a trusted UI can't do all
> of that.  If a website could request a zero-knowledge proof of
> knowledge of a secret, where the secret has this description next to
> it and this set of extra buttons (the buttons would be plain links and
> would *not* transmit the password), I think that everyone wins.  Heck,
> the whole trusted dialog could be written in HTML and, as long as the
> ability to submit forms were restricted and scripts were blocked, it
> should just work.
> 
> Admittedly, this doesn't really fit in to my suggestion of doing it as
> part of TLS key exchange.
> 
>>
>> This is the exact same problem with client certificates.
>>
>> Both solutions (TLS-SRP and client cert auth) are trying to solve
>> application auth issues at the transport. This doesn't work well. Heck,
>> even GSSAPI doesn't have a good solution for this when authenticating to
>> sites with SPNEGO (although the ongoing work for cred UI is exciting
>> stuff).
>>
>> The real drive - of sites and of browsers - is trying to find ways to give
>> sites as much control of the UI as possible, while simultaneously reducing
>> the risk - of password breaches and security incidents. If you want to see
>> the practical efforts to "solve" the phishing problem, look at stuff like
>> http://fidoalliance.org/
> 
> That was actually my inspiration for suggesting this feature.  Suppose
> you use a second factor (e.g. Fido U2F) device to authenticate to your
> bank.  You've set a PIN "1234".  An attacker subsequently steals your
> U2F device.
> 
> If the device is well designed, locks out the key after a few tries,
> is suitably slow rejecting bad PINs, and is truly tamper proof, then
> everything is OK.  But that's a big if.
> 
> The problem is that using ECDSA signatures or anything like then in a
> second factor is the wrong approach, I think.  If a second factor
> instead answered an augmented PAKE challenge, it could be implemented
> in such a way that it wouldn't be able to distinguish a correct PIN
> from an incorrect PIN.  Then the server could lock out the account
> after a few tries, and an attacker wouldn't be able to usefully attack
> the device even if they completely broke its tamper protection.
> 
> This is mostly outside the scope of the TLS WG, but I think that TLS
> could do a lot to make this kind of thing easier.
> 
> --Andy
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>