[Cfrg] RE: [saag] Cryptography Algorithm Choice

["Hallam-Baker, Phillip" <pbaker at verisign.com>]

> 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. DES VPNs really do exist, hopefully they are fading away but I
would not bet on it having been completed :-(

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. 

At the moment ask the customer their credit card number works too well.


> 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. 


> That would only work if someone went back and re-wrote every RFC that 
> uses security algorithms. A much better mechanism is a human-edited 
> registry (hopefully a real database, not an Old Skool text file) that 
> contains this information. Such a registry should be the job of the 
> IETF Secretariat and/or IANA.

We can hope, but I can't imagine that this is going to happen. The 
processes are just too sclerotic.

I suggest that we approach the subject a different way. We deal with 
the legacy base in a one off process, then get future specs to do 
something that is self maintaining.


Either way, machine or manual we have to get the statement down to
a checkbox level.

One of the ideas of CFRG was to be able to take these alg discussions
outside the WG process precisely so that we can avoid the issues you
raise.

I would like the NEWTRACK folk to give us a credible list of what
the real standards status of various RFCs are. Then for each of those
we should look to see whether there is a crypto algorithm involved
at any level and if so what the security considerations of the
algorithm selection are and what the constraints are for changing it.

Then we should write up a doc that sets out 1) the information above
and 2) what the recommended and acceptable algorithms are for each
protocol.

There should only be one place that people have to go to find out 
this info.



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