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