Re: Protocol Action: 'Pre-Shared Key Ciphersuites for Transport Layer Security (TLS)' to Proposed Standard

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



 In your previous mail you wrote:

   At 5:02 PM +0200 6/27/05, Francis Dupont wrote:
   >pre-shared secrets
   >are known to be weaker than certificates
   
   That statement is false for many common uses of preshared secrets and 
   certificates. A preshared secret with even 80 bits of randomness is 
   stronger than most certificates used for authentication today. (See 
   RFC 3766 for the math behind this.)
   
=> my argument was not about key length but about the mechanisms
(i.e., computer science, not mathematics). Pre-shared secrets are
by definition at two places: this is enough to make the mechanism
weaker than asymmetric crypto. I can develop about the problem
to communicate the shared secret but in fact what I'd like to mean
is that pre-shared secrets are for good and less good reasons
perceived as weaker than certificates so the document in last call
can be preceived as a security regression.

   >  I remember a similar discussion about IKEv2 but in this case pre-shared
   >secrets were kept for compatibility...
   
   This is also false. The archives of the IPsec Working Group show that 
   there were many other reasons for supporting preshared secrets, 
   including many administrative scenarios.
   
=> I should be more accurate but my purpose was to launch a short discussion:
the compatibility was not a technical one but an operational one.
To summary my feeling is that IKEv1 is deployed at 90% with pre-shared
secrets and IKEv2 had to support them in order to be sold to current
IKEv1 administrators.

BTW there are other good examples where both mechanisms can be used
with a "public opinion advantage" for the asymmetric crypto one.
TKEY (RFC 2930) and SIG(0) (RFC 2931) is the first example which crosses
my mind.

   The two authentication mechanisms have quite different properties and 
   each is appropriate in many settings. Saying one or the other is 
   "known to be weaker" without examining the context, particularly on a 
   general-purpose mailing list, will not help increase the security of 
   the Internet.
   
=> I am not (yet) convinced that to accept the document will help
to decrease the security of the Internet but clearly I'd like to be
reassured/comforted and I am afraid your arguments have not worked...

Regards

Francis.Dupont@xxxxxxxxxxxxxxxx

PS: for instance I'd like to understand why self-signed certificates
were rejected, cf section 1.1 "Applicability statement". This is the
second part of my concern: is the domain of application large enough?

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]