[Next][Index][Thread]

Re: Passphrases in or out

OK, I'll do the risky thing and come out on the other side of this issue
from my employer (I just got my check, so I've got at least a month).

At 12:12 PM -0800 8/2/96, Christopher Allen wrote:
>At 12:43 PM -0700 8/2/96, Dan Simon wrote:
>>Okay, here's one thing:  they can't protect password-based
>>challenge-response transcripts with strong encryption while adhering to
>>export restrictions.  If the application is restricted to exportable
>>encryption, then it can't properly protect challenge-response pairs from
>>brute force attacks--first against the encryption, then against the
>>password.
>
>Ok, so far this is the only requirement that I've seen that can't be done
>with TLS now.

I believe it's fallacious to use this as a metric. I mean, you could do all
of this with straight IP, if you wanted; you'd just have to write a lot of
redundant code. The question is: where do things belong?

[...]

>I could be persuaded to drop my objections if there was the following:
>
>a) A concrete proposal, to the bits level, of how you can protect
>password-based challege-response bits at a higher level of encryption than
>the exportable SSL stream, and how this proposal fits into the the broader
>TLS protocol, and *DOESN'T* try to do more than this.

I believe that Microsoft has made such a proposal; I haven't evaluated it,
but I don't think this is the hard thing. None the less, we should have a
proposal on the table. Chris, maybe I'll write one in my copious free time.

>b) An evaluation of whether this couldn't better be done through another
>"standard" technique like APOP or some of the other AUTH frameworks at the
>application level, or by using some out-of-band technique.

I believe that this authentication belongs in TLS. TLS already mixes in
authentication by smearing it in with key exchange. I think it would be an
architectural disaster to require implementors to have authentication at
two widely seperated parts of their software.

>c) An evaluation of whether this really is exportable.

This I have no knowledge of, and it probably depends on a).

>d) Some comments on if adding a feature because of only US export issues
>that could impact security is acceptable.

There are already quite a few features in SSL specifically for
exportability. Compliance with export law is such a huge impact on our
industry that we would be insane (from a commercial success standpoint) not
to recogize and design towards its requirements, regardless of our beliefs
surrounding its appropriateness.

>e) Some other parties besides Netscape, MicroSoft, and CompuServe to speak
>up on the proposal.
>
>f) Some cryptographers to speak up on the proposal.

I don't know if I qualify, but I think we need to evaluate a specific
proposal (in a) to do this).

>g) An "exit" strategy, so that we can be sure that this hack has a sunset,
>and that it would not be a requirement of TLS to always support this in the
>future.

I think that if we build it, it's an optional part of the protocol; there
is no obligation to support it now or in the future, but I wouldn't
recommend putting in an explicit sunset for its legality.

>I'll summarize my objections so far:
>
>1) It is inelegant architecturally.

I believe it is far more inelegant to remove it and require those who want
to use passwords or mix password and client cert authentication to have two
different authentication layers.

>2) It serves a need that can be just as easily answered at the application
>protocol level.

I believe that addressing it at the application layer has serious drawbacks.

>3) I'm concerned about security issues (I'm not a cryptographer, so I can't
>say that it is not secure, only that I've not heard enough from them to
>feel more confident.)

It should be fairly simple to design a secure exchange protocol.

>4) I'm concerned that it will delay implementation of client certificates.

Two things:
 1) I think you'll find you get faster adoption of client certs if you make
it possible for password and certificate authentication to coexist than if
you require seperation. In the first case, providers (like Compuserve) can
gradually move their customers to client certs. In the second, they may
have to switch large numbers of customers at once from one system to the
next; that may be an investment that never gets made.
 2) I agree with Dan; if client certificates aren't appealing enough to be
adopted on their own merits on a level playing field with passwords, then
why should we hold a gun to people's heads? Realistically, security is only
one factor in a universe of considerations. If customers want to trade
security off across cost or aggravation, who are we to tell them what they
want? Compuserve sells a service for a few dollars a month. The cost of
issuing a certificate is a large fraction of their income. Given that their
exposure is low, why should they invest millions of dollars into developing
a certificate architecture? What does it buy them? Why can't passwords be
good enough for some purposes?

Best,
 - Tim

Tim Dierks  --  timd@consensus.com  --  www.consensus.com
Head of Thing-u-ma-jig Engineering, Consensus Development
References: