Subject: [TLS] Status of IDEA and single-DES (ticket #64)

From: <[email-masked]>
Date: Tue, 22 Jan 2008 10:41:27 +0200

<wg chair hat on>

We seem to have quite widespread agreement that single-DES and 
IDEA are not algorithms you should use in most circumstances, and 
if you're an implementor, disabling or removing those cipher 
suites wouldn't usually be a bad idea.

We don't seem to have complete agreement on what exactly,
specification-writing-wise, is the most appropriate way to convey
this agreement. Several people have supported simple "MUST NOT";
others have argued that this is a policy decision, and should not 
be hardcoded in the spec.

By my latest count, slightly smaller number of people have supported
a total MUST NOT than some form of "not good idea, but not totally 
prohibited either" recommendation. I believe that changing this to 
MUST NOT would require significantly stronger support, and therefore 
we're going for something else.

I'd therefore like to propose two concrete alternatives for the 
WG to comment:

(1) Remove all mentions of IDEA and single-DES from the TLS 1.2
main specification. Create a separate (1-page) document which lists
the cipher suite numbers, along with some kind of "not really that
good idea usually" advice.

The exact wording of this advice needs to be discussed, but it
could include e.g. SHOULD NOT use, SHOULD NOT implement, SHOULD
remove from existing implementations, and/or SHOULD NOT be enabled
by default. This document would not be on Standards Track (in
other words, either Informational or Historic).

(2) Keep IDEA and single-DES in the TLS 1.2 main specification,
but include a short advice along the lines described above.

If you commented the IDEA/DES discussion earlier, please reply
and indicate which of these alternatives (or none or both) would
be acceptable to you.

Speaking as a WG chair, I would prefer an alternative that allows us
to ship the TLS 1.2 main specification to AD Evaluation ASAP. We've
already missed our milestone by more than a year, and I've received
comments from implementors that they'd like to see this finished soon.

I would also not mind having an alternative that would allow us -- if
we so later decide -- to promote TLS 1.2 to Draft Standard without
producing a new document.

<wg chair hat off>
Personally, I think the first option would reasonably satisfy these
goals, and would keep the spirit of including only "good stuff" 
in the TLS main specification.

Best regards,
Pasi

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Tue, 22 Jan 2008 10:56:20 +0200

(1)

I think a few mandatory-to-implement ciphersuites are a good idea in  
the base spec. However, that spec should not replace IANA in becoming  
the repository for ciphersuites.  Better to skip any mention of them  
than to add cryptographical discussion there.

On Jan 22, 2008, at 10:41 AM, <[email-masked]> <[email-masked] 
 > wrote:

<snip>

---

From: Hovav Shacham <[email-masked]>
Date: Tue, 22 Jan 2008 01:02:46 -0800

> good idea usually" advice.

(1) is my preference out of the two options here.

Cheers --
Hovav.

PS:

> Several people have supported simple "MUST NOT";

I happen to think that the TLS spec is exactly where policy that has  
security implications should be hardcoded.  Any other approach is  
inviting insecurity.

---

From: "tom.petch" <[email-masked]>
Date: Tue, 22 Jan 2008 12:00:00 +0100

(2)  Keep all the information together (until the day it becomes too unwieldy,
say in excess of 100 pages); otherwise people will miss crucial information, not
understanding how to find all the relevant facts (see a recent discussion on the
main IETF list demonstrating that).

Tom Petch

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, January 22, 2008 9:41 AM
Subject: [TLS] Status of IDEA and single-DES (ticket #64)

<wg chair hat on>

<wg chair hat off>

Best regards,
Pasi

---

From: Martin Rex <[email-masked]>
Date: Tue, 22 Jan 2008 15:25:29 +0100 (MET)

> other words, either Informational or Historic).

Fine with me.

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Tue, 22 Jan 2008 09:28:20 -0500

I support preference (1). Exact wording of that separate document - along the lines of: SHOULD NOT implement, SHOULD NOT use, MUST NOT be enabled by default. I'd be even happier with "MUST NOT" in all the three places.

On 1/22/08 3:41 AM, "[email-masked]" <[email-masked]> wrote:

<wg chair hat on>

<wg chair hat off>

Best regards,
Pasi

--
Regards,
Uri

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Jan 2008 09:15:55 -0800

At 10:56 AM +0200 1/22/08, Yoav Nir wrote:
>the base spec. However, that spec should not replace IANA in 
>becoming the repository for ciphersuites.  Better to skip any 
>mention of them than to add cryptographical discussion there.

I agree with this logic.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nelson B Bolyard <[email-masked]>
Date: Tue, 22 Jan 2008 13:02:29 -0800

> but include a short advice along the lines described above.

I strongly prefer that choice.

If we say "MUST NOT" or even merely remove the definitions of those
suites from TLS 1.2, then interoperability problems will certainly
arise.  Servers will be created that reject client hellos that contain
those cipher suite numbers, even if those hellos also include other
cipher suite numbers that are acceptable.

I'd even go so far as to suggest that text be added stating that
compliant TLS 1.2 implementations MUST NOT reject client hellos simply
because those client hellos contain cipher suite numbers that are
deprecated, or undefined in TLS 1.2, or are "MUST NOT" (as in export
cipher suites) for TLS 1.2.  If no acceptable cipher suite is found,
that's a problem but no server should ever reject a client hello simply
because it contains one or more cipher suite numbers that are unpopular.

(Yes, I have seen servers that actually do that.)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Jan 2008 13:35:01 -0800

>(Yes, I have seen servers that actually do that.)

Yeesh. New levels of cluelessness among developers are discovered every day.

If we add the text you want (which seems fine to me), would you then 
prefer #1 over #2?

--Paul Hoffman, Director
--VPN Consortium

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Tue, 22 Jan 2008 16:20:01 -0800

Paul and all,

  I ad the same question Paul.

Regards,

Spokesman for INEGroup LLA. - (Over 277k members/stakeholders strong!)
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is
very often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B;
liability depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS.
div. of Information Network Eng.  INEG. INC.
ABA member in good standing member ID 01257402 E-Mail
[email-masked]
My Phone: 214-244-4827

---

From: <[email-masked]>
Date: Thu, 24 Jan 2008 13:10:52 +0200

> cipher suite numbers that are acceptable.

Well, TLS 1.2 is *not* the master list of cipher suites, so if
servers reject client hellos that contain ciphers not listed
in TLS 1.2 spec, they will also break with clients that implement 
e.g. RFC 2712, 4132, 4162, 4279, 4492, 4785, or 5054.

(And option 1 wasn't proposing merely removing these suites from 
TLS 1.2 spec; it also included creating a new spec to contain
them.)

> compliant TLS 1.2 implementations MUST NOT reject client hellos
> simply because those client hellos contain cipher suite numbers that
> are deprecated, or undefined in TLS 1.2, or are "MUST NOT" (as in
> export cipher suites) for TLS 1.2.  If no acceptable cipher suite is
> found, that's a problem but no server should ever reject a client
> hello simply because it contains one or more cipher suite numbers
> that are unpopular.
> 

I have to agree with Paul's comment about "new levels of cluelessness
among developers" here -- IMHO that behavior isn't compliant with the
spec even with the current text.

However, if you've actually seen that, then perhaps adding some
clarifying text would be in order. How about adding something along 
these lines, to the end of paragraph starting "The CipherSuite list.."
in 7.4.1.2:

   If the list contains cipher suites the server does not recognize,
   support, or wish to use, the server MUST ignore those cipher
   suites, and process the remaining ones as usual.

Best regards,
Pasi