Actually for the TLS crowd, going to DES is a step up. I presume that the
TLS WG is planning to use DES to replace the RC4 40 bit cipher that was used
for export compliance. Normally we would not profile a weak cipher for use
in export applications. We made an exception for TLS/SSL because it was
already widely deployed and it didn't make sense to have this battle (the
export control vs. strong security) hold up the standardization process for
it.
An interesting issue here is should we remove RC4 40 from TLS as a "price"
for adding DES or should we require that both be removed before the next TLS
document is published as a Proposed or Draft Standard. I would be interested
in hearing people's opinions on this (though given the recipient list on
this message, I have a pretty good idea what I am likely to hear!).
-Jeff (original proposer of the Danver's Doctrine, and I
have the arrows in my back to prove it!)
Adam Back wrote:
> > Title : DES Applicability Statement for Historic Status
> > Author(s) : S. Bradner, W. Simpson
> > Filename : draft-simpson-des-as-01.txt
> > Pages : 8
> > Date : 22-Jun-99
> >
> > 'The PPP DES Encryption Protocol' [RFC-2419], 'The ESP DES-CBC Cipher
> > Algorithm With Explicit IV' [RFC-2405], and 'The ESP DES-CBC
> > Transform' [RFC-1829] have been re-classified to Historic status, and
> > implementation is Not Recommended.
>
> Ok, so DES is history, and it is nice to see an draft suggesting
> various things decomissioned as a result.
>
> However I subscribe to the IETF-TLS list, and rather than
> decomissioning DES, they just *comissioned* it a few months ago by
> adding 3 ciphersuites using DES in response to US government export
> reg changes.
>
> My arguments that adding broken ciphersuites to an IETF standard was
> in direct and obvious violation of RFC 1984 fell on deaf ears, as
> Netscape, microsoft and even openSSL (in the form of Ben Laurie)
> busily rushed and implemented the proposed broken ciphersuites.
>
> Perhaps someone who has Simpson and/or Bradner's address handy could
> draw this to their attention so they can say 'implementation not
> recommended' to these broken ciphersuites in TLS before they even get
> added to the next draft.
>
> (RFC1984 for those who have not read it documents the Danvers Doctrine
> that IETF security standards should not use broken crypto solely for
> political reasons).
>
> I think the RFC 1984/Danvers Doctrine is being rather ignored in
> general, and I think this is a bad thing. For example the 40 bit
> ciphersuites in TLS (as well as the proposed 56 bit ciphersuites) are
> there solely for political reasons; there backwards compatibility
> argument for them is weak because TLS is not directly backwards
> compatible with SSLv3 anyway, as described in appendix E of current
> TLS draft:
>
> : [...] TLS clients who wish to negotiate with SSL 3.0 servers
> : should send client hello messages using the SSL 3.0 record format
> : and client hello structure, sending {3, 1} for the version field to
> : note that they support TLS 1.0. If the server supports only SSL 3.0,
> : it will respond with an SSL 3.0 server hello; if it supports TLS,
> : with a TLS server hello. The negotiation then proceeds as
> : appropriate for the negotiated protocol.
>
> So it would not at all affect backwards compatibility to out-right
> remove all ciphersuites with RSA = 512, and with symmetric key size of
> 40.
>
> That these broken cyphersuites are retained in the TLS protocol is not
> for backwards compatibility, it is for political reasons, and is a
> direct violation of Danver's Doctrine.
>
> I cc'd my last complaint about ignoring RFC 1984 in IETF security
> related drafts (similar text to the above back in February this year)
> on the TLS list to the IETF area security directors; I got no reply.
>
> Cc'd Jeffrey Schiller and Marcus Leech again -- I would really like to
> see some IETF response on this topic -- fielding broken crypto systems
> is a seriously bad idea, once deployed they will take decades to phase
> out for backwards compatibility reasons and for the 'most browsers are
> 40 bit inside out outside US' phenomena which must so delight NSA et
> al.
>
> Seems like Gilmore's $250k to educate people was not that good an
> investment, people who should no better are still ignoring the
> inherent weakness of 56 bit crypto and deploying it in fresh IETF
> drafts.
>
> Some of the IPSEC drafts share the same problem. Gilmore and friends
> free S/WAN project studiously avoids implementing the DES options.
>
> Adam
> --
> print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
> )]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`
