On 03/05/16 12:52, Manav Bhatia wrote:
> Hi Stephen,
> 
> On 03/05/16 12:25, Manav Bhatia wrote:
>>>  There
>>> is thus a value in retaining clear text passwords.
>>
>> I don't buy that tbh. There is a significant cost and risk
>> too - passwords are re-used all over the place. Sending
>> any password in clear anytime puts at risk whatever else
>> that password is re-used for. And we know that does
>> happen. (On average passwords used in the web are used in
>> about 8 different places is the last study result that I
>> recall.)
>>
> 
> I am sure you know that the way passwords are used in the web is different
> from how they are employed in securing the routing protocols ! :-)

People being people everywhere, I'm sure the differences aren't
that great;-(

> 
> I know several deployments where clear-text passwords are used to avoid
> routing sessions from randomly coming up. So i dont see how we can remove
> that option.
> 
> 
>> I think this spec would be far better off advising to
>> not continue that bad practice.
>>
> 
> I would instead suggest a one page BCP that discourages people from using
> clear-text password or an April 1 RFC that claims that clear-text passwords
> are most secure since no hacker would ever think that the network could be
> using a simple password !
> 
> I dont think that SBFD spec is the right place to knock sense into people
> who think that using clear text passwords for securing their networks is
> the smartest and the safest thing to do. That imo warrants a new draft.
> Dont you agree?

I'd love to see someone write a draft about sensible things to do
and silly things to do with all of the pre-shared keys used in routing
protocols. If that exists, great! (And can you send a pointer? And
then maybe refer to it from here.)

If that doesn't exist, then adding relevant bits of it as appropriate
seems to me like the best we might get. Or are you planning to write
that?

S.

> 
> Cheers, Manav
> 
> 
> 
>>
>> S.
>>
>>
> 

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to