Re: Closing on shared-key authentication

Jeff Williams wrote:
> At 12:30 PM 10/10/96 -0700, you wrote:
>> You are quite correct.  However, short term customer requirements for
>> password authentication can be met by using existing authentication
>> mechanisms in existing protocols.  There is no need to add a
>> mechanism to TLS when all existing protocols already have a password
>> mechanims.
>   I realize that.  But my concern is not just that we may need to
> consider adding it to TLS for those customers whom believe in that
> mechanism, all be it not necessary, possibly.  Again I still believe
> that a "Common" Protocol interface well featured would go a long ways
> in solving or addressing some short term problems at teh very least. 
> Extensions to that interface for enhancments to existiing or possably
> new protocols, would also project a method of achieving long term
> desires here.  Don't you think this makes some sense?

There is already an existing mechanism that allows compatibility between
versions.  Rather than providing an extension mechanism that will just
encourage fragmentation of the protocol, I'd rather see us achieve
consensus on useful features and include them in future revisions.

>> Even if you think we'll be limited to 40-bit for export forever, do
>> you really believe that any password scheme is going to provide
>> better than 40 bits worth of security for authentication?  If you can
>> remember a password with 40 bits of entropy then you have a better
>> memory than I do.
>   No of course not.  I couldn't remember much more than 10! ;)  But is
> it really necessary to remember.  I can be pluged into the login
> procedure.

The main distinction I've heard between password authentication and
public key crypto authentication is that a password can be carried
in your head.  If you're using a floppy or other hardware token to
transport your password, why not just use it to transport your private

>> As to the lifting of export restrictions, the White House is already
>> talking about raising the limit to 56 bits, and there is legislation
>> pending that would lift export restrictions altogether.  I feel very
>> strongly that an international standard should not be burdened with
>> major features with such substantial security implications for
>> reasons of local governmental policy.
>   56 bits is a total waste of time in my opinion.  It wouldn't take
> much more than 3 seconds to break that!  Without at least 128 bits
> being approved for export international companies will not support
> commerce for long on the net.  In addition, even 128 bit in my humble
> opinion is a bit short of what I would like to see.

I agree with you that 56 bits is a very small step, and provides only
slightly more security than 40.  However, it does indicate that times
may be changing and we should not view current US export policy as set
in stone.

>   With reguard to what you say reguarding local gov. policy, I am not
> quite clear as to what you mean here?  Explain please, ok?

The IETF is an international standards organization.  Should we design
our protocols to conform to US policy?  French policy?  Japanese policy?
I think not.  We should design TLS to be as secure as possible.

You should only break rules of style if you can    | Tom Weinstein
coherently explain what you gain by so doing.      |

Received on Friday, 11 October 1996 14:05:27 UTC