RE: [Cfrg] RE: [saag] Cryptography Algorithm Choice

["bill" <bill at strahm.net>]

As I recall - Win2K was roundly blasted by critics for falling back to
DES when it tried to connect to a machine that would only enable DES
(Export version)

I know for a FACT that I tested DES IPsec in interoperation at the VPN
interop in 1999.

These things aren't that old (I saw the NIC that I worked on at Fry's
tonight when I was there) so I guess you have your evidence now Paul

Bill

> -----Original Message-----
> From: cfrg-bounces at ietf.org [mailto:cfrg-bounces at ietf.org] On 
> Behalf Of Paul Hoffman / VPNC
> Sent: Tuesday, August 24, 2004 2:10 PM
> To: cfrg at ietf.org; saag at mit.edu
> Subject: [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
> 
> 



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