On Tue, Mar 11, 2008 at 01:53:53PM -0700, Garrett D'Amore wrote: > I concur, although I'm not *sure* I'd derail the case. But I do think > that it should be possible for an application to request greater > security than perhaps the administrator has configured. > > Having an administrative default or override is *great*, and perhaps the > idea that this could be delivered ahead of the API (perhaps because > standardization efforts around the socket API are still in progress), is
I wouldn't wait for standardization of C APIs. There's a very feeble effort to do that at the IETF for IPsec APIs; there is no effort at all to do that for TCP MD5 (or at least I'm not aware of any). Waiting here would be waiting forever; not waiting would be to provide leadership. The flip side argument is that if there's no standardization of IPsec architecture changes to accomodate TCP MD5 via the IPsec PAD and SPD databases, then it would seem awful odd to pursue that approach. A brief grep of the relevant TCP MD5 RFCs shows no matches for "SPD" (ignoring case). > totally acceptable. But I think I'd still like to know that there is a > long term plan at least, to offer some application access to this > feature (at least to enable it -- application access to disabling it is > probably of limited value.) Disabling TCP MD5 is not likely to be something apps want to do. TCP MD5 is of limited use and applicability, so apps will generally want to enable, rather than disable it, and there will/should be few such apps. (Let's not get into why TCP MD5 is of limited use and applicability.) > On another front, perhaps someone more familiar can answer this > question: If everyone basically acknowledges that MD5 has some known > weaknesses, and that btw, it isn't acceptable for use in FIPS compliant > products, then *why* haven't I heard about any effort to use one of the > approved SHA algorithms? This is a standards issue. I refer you to the IETF, and the SAAG mailing list archives specifically (see http://sec.ietf.org/). I recall plenty of recent traffic on TCP AO and what not that I've not kept up with. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
