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

[Cfrg] RE: [saag] Cryptography Algorithm Choice

At 1:47 PM -0700 8/24/04, Hallam-Baker, Phillip wrote:
> Is there any evidence for that statement? Almost no vendors currently 
 ship VPNs with the default settings of DES. VPNC has never tested DES
 conformance or interoperability, and we have never had a single VPN
 user ask us to do so (or ask us why we didn't). No VPNC member has
 told me that they any customer demands for DES.


Paul, there are many VPN vendors that do not use IPSEC or for that matter
SSL.


Of course.

DES VPNs really do exist, hopefully they are fading away but I
would not bet on it having been completed :-(

Sorry, but it's hard to take that on faith without seeing any evidence of it. And, yes, this is relevant to the discussion at hand because this group might act differently if we believe that weak encryption is commonly used in IETF-created protocols.

And, although I have no hard facts, when I spoke to link-layer encryption vendors 18 months ago, they all said the same thing: there was essentially no current market for DES or anything with keys less than 112 bits of effective strength for anything called a VPN.

Put it this way there are plenty of 40 bit SSL browsers arround and I am
not aware of anyone ever having broken the crypto to actually do something
malicious. Although at this point it is clear that the phishing gangs will
be doing this at some point.

This has nothing to do with VPNs, only with SSL-enabled sites. None of the SSL VPN vendors that I know of allow DES as an acceptable connection algorithm by default. If you are saying that a significant number of users who have SSL VPN systems have turned this on this option, it would be good if you also supplied some evidence for this.

Of course, the algorithms being negotiated in the wild can actually be measured by ISPs who do a bit of port sniffing. If anyone has such numbers, it would greatly help to have them published!

> This ties closely to the request for tracking of the algorithms 
 allowed, suggested, and mandated in IETF standards. Even today, DES
 is the MUST-level algorithm for IKEv1 (the IPsec WG never got around
 to changing it). IKEv1 is a great example of a protocol where you
 cannot determine what security algorithms are being used by looking
 at the RFC.


I agree, I think we need a process and a set of use levels for
crypto algorithms. I think that this is an independent axis from
the standards level consideration. MD5 still makes a fine database
hash.

In your example DES is still a MUST for conformance testing but it
is a SHOULD NOT as far as security goes.

Huh? Where in RFC 2407 do you see that? The RFC is completely clear: MUST support DES, "strongly encouraged" to support TripleDES. The waffly words in the IESG note do not say "SHOULD NOT", and the prediction that "it is very likely that the IETF will deprecate the use of ESP_DES as a mandatory cipher suite in the near future" never came to pass.

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Cfrg mailing list
Cfrg at ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg