Re: [TLS] Working Group Last Call for draft-ietf-tls-pwd

["Dan Harkins" <[e-mail]>]

On Thu, December 5, 2013 11:24 pm, Watson Ladd wrote:
> On Thu, Dec 5, 2013 at 10:40 AM, Dan Harkins <[e-mail]> wrote:
>>
>>
>> On Thu, December 5, 2013 10:01 am, Trevor Perrin wrote:
>>> See the discussion around SRP that occurred when you first presented
>>> this.  Any patent FUD which *might* have existed, once, has expired:
>>>
>>> http://www.ietf.org/mail-archive/web/tls/current/msg08203.html
>>> http://www.ietf.org/mail-archive/web/tls/current/msg08191.html
>>
>>   Yes I am aware that the original EKE patent expired. But EKE cannot be
>> used with elliptic curves. Now I know elliptic curve support is not a
>> compelling use case for you but, again, so what?
>>
>>> Additionally, developments such as Elligator and AugPAKE hold promise
>>> for protocols that have both security proofs *and* no IPR encumbrance.
>>
>> https://datatracker.ietf.org/ipr/2037/
> Just because one particular protocol is patented does not mean others
> aren't.

  Who said otherwise? Certainly not me. But you sure got that straw man.
Good shooting!

  I was just responding to a statement that purported to mention an
unpatented protocol that not only is patented but also has a pretty nasty
licensing agreement.

> J-PAKE is going through the CFRG, works with ECC, and has a proof. Why
> couldn't
> you use that instead? (yes, it does incur an additional round.)

  I have an idea, why don't you? Work that extra round into the TLS
protocol. Write up an Internet-Draft. Seriously. Please write this up. I
can't wait to see it.

>>> The benefits of *both* are uncompelling.  The low uptake of TLS/SRP
>>> has nothing to do with this draft's cryptographic differences.  It has
>>> to do with architectural issues with the approach, which your draft
>>> does not improve on.
>>
>>   You are free to not use this protocol as well if you do not find it
>> compelling.
> The problem is that people faced with the choice of TLS-SRP and TLS-PWD
> will not be aware of the relevant tradeoffs, and make the *wrong
> choice*.

  Ahh, the voice of inexperience….

  Yes, people do make bad decisions because they don't understand all
the nuances. In the real world what they do is something stupid like a
self-signed certificate ("just check 'OK', it's alright") followed by HTTP
digest authentication. That's the good one, sometimes they just do PAP
with a self-signed certificate. Or they use a PSK cipher suite with a
simple password. When this has been exposed these companies have
responded to me, "but we're using TLS so it's secure" or "we're using AES
so it's secure". The problem is not that these people you refer do not
know  how to choose between TLS-SRP and TLS-pwd, it is that they are
not given the opportunity to use either one.

  But there are other people who can, and want to, make the right choice.
Like using TLS-pwd with ECC to authenticate to an EST server so one can
parlay a simple password/code/phrase/key into a certificate with an
ECC public key-- instead of using a 1024-bit FFC group to certify a
384-bit ECC public key it makes sense to use the same ECC group for
authentication that is used to generate the certified public key. Or
people whose small embedded devices (where hardcoding large FFC
groups is out of the question) have rudimentary UIs that limit ones
choice of credential to something simple like a password and want
to use TLS-pwd to authenticate with a central server.

> The goal
> of this WG is not to provide a choose your own adventure, where mistakes
> lead to
> other people reading your passwords. There is tremendous pressure on TLS
> implementations to implement objectively bad ideas that are part of
> the standard,
> and it is quite hard to get rid of them.

  Oh, so what you're saying is that there is now tremendous pressure to
implement TLS-pwd (an "objectively bad idea" in your opinion)?  You might
want to get with Trevor. You guys seem to be at odds over that one.

> Take your financial institution, and see what gets negotiated with your
> browser.
> And you want to give the people responsible for that more ways to
> shoot themselves in the foot?

  My financial institution will not use TLS-pwd. It won't use TLS-SRP either.
TLS-pwd is not a universal, useful-for-all situations, cipher suite. It has
a very specific set of use cases for which it is applicable and financial
institutions are not one of them.

  Which isn't to say that there are no problems with the TLS connection to
my bank. I have no relationship with  the company whose CA is used by
my bank. I've never audited the processes they use with their CA, I don't
know their disaster recovery plan. I have never met any officers in the
company and have no reason to believe they are trustworthy and not
susceptible to some form of blackmail. So actually I have no reason to
trust the certificate presented by my bank signed by their CA when I
connect to my bank's server. But my browser trusts it for me because
some industry consortium that I am not a party to vouched for it. So
if you're worried about financial institutions and how browsers connect
to them I think you have bigger concerns that TLS-pwd.

  Dan.