Subject: [TLS] Status of IDEA

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Dec 2007 09:34:00 -0800

In the current draft of TLS 1.2, IDEA is marked as MUST NOT. Some in
the WG felt that it should be a SHOULD NOT. The minutes read:

   Pasi asked if it was really OK to make IDEA a MUST NOT do at the 
   current codepoint
           Russ Housley didn't like the idea
           Paul Hoffman said that listing untested algorithms 
           causes developers to use them
           Stefan Santesson said we should leave a holder in
           Straw poll: SHOULD NOT and MUST NOT got roughly equal support
           Will take to the list

Please use this thread for discussion of this topic.

-Ekr

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

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Dec 2007 10:29:59 -0800

The experience in the IPsec WG for algorithms that are listed but not 
mandated in the base spec was that many developers did a first pass 
at implementing them, but rarely tested their implementations. This 
could easily lead to serious security issues that would go unnoticed.

I do not understand what "SHOULD NOT" for IDEA would mean. "Don't do 
it unless you really want to"? "Don't do it unless the other side 
only can do IDEA and not any of the mandatory-to-implement ciphers 
which it did not implement"? Having IDEA and DES and RC2 MUST NOT 
makes it completely clear to implementers what they are allowed to do.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 20 Dec 2007 14:10:56 -0500

I agree with Paul. Meaning of  "SHOULD NOT" is confusing, to say the least. Our intention seems clear: we do not want people to put IDEA in their TLS implementations. IMHO, let the standard say "MUST NOT".

If there are exceptions convincing enough that this group is likely to consider them - spell them out.

On 12/20/07 1:29 PM, "Paul Hoffman" <[email-masked]> wrote:

--Paul Hoffman, Director
--VPN Consortium

--
Regards,
Uri

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 20 Dec 2007 12:30:28 -0800 (PST)

I agree. One of the (many) lessons learned from IKE is that vanity
algorithms just cause problems.

  Whether there's a compelling need for IDEA or not, saying "SHOULD NOT"
is wrong. If there's a compelling need then "MAY" seems appropriate; if
there's no compelling need then "MUST NOT" is nice and unambiguous.

  Dan.

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Dec 2007 16:06:06 -0500

The code point for IDEA are already assigned.  I understand that some 
implementations support it.  I'm most comfortable with MAY support 
IDEA, and I can live with SHOULD NOT support IDEA.  If we are going 
to completely deprecate IDEA in TLS, we need to give notice to 
implementors.  The SHOULD NOT gives the notice so that it can go away 
(not be mentioned at all) in the next version.

Russ

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Dec 2007 13:10:53 -0800

At Thu, 20 Dec 2007 16:06:06 -0500,
Russ Housley wrote:
> implementors.

Well, this won't affect TLS < 1.2 at all, right? So given that AES
is MUST implement, why do they need warning?

>  The SHOULD NOT gives the notice so that it can go away 

So, TLS practice has not been not to not mention, but rather to 
list the code points with MUST NOT labels. That's what we do with,
for instance, DES40.

-Ekr

---

From: Rodney Thayer <[email-masked]>
Date: Thu, 20 Dec 2007 13:33:21 -0800

Default builds of OpenSSL (including some shipped with the Mac,
for example) supported IDEA.  So I think 'some notice' is appropriate.
I think that making it a "MAY" and making a note in the spec that
the wg intends to deprecate it completely in a future version would
be the thing to do.

I don't think there are any current implementations in the wild
that 'need' IDEA.  Anyone got evidence that claim is wrong?

Russ Housley wrote:
> implementations support it.  I'm most comfortable with MAY support IDEA,
> and I can live with SHOULD NOT support IDEA.  If we are going to
> completely deprecate IDEA in TLS, we need to give notice to

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Dec 2007 16:39:42 -0500

Eric:

TLS 1.1 lists the IDEA cipher suites with no real label.  The text 
says that they are included for completeness.  I take that to be 
equivalent to MAY implement.

I think that jumping from MAY implement to MUST NOT implement without 
a severe security concern is unfair to the implementors.

TLS 1.1 contains the following text:

   Warning: The ability to send Version 2.0 client hello messages will be
        phased out with all due haste.  Implementors SHOULD make every
        effort to move forward as quickly as possible.  Version 3.0
        provides better mechanisms for moving to newer versions.

I'm suggesting something similar for ciphersuites.  List the ones 
that will become MUST NOT in the future and tell people that is the 
intent.  I think the will-become-MUST-NOT ciphersuites should be MAY 
implement (the same status as in TLS 1.1) in this version of the 
document, but I can live with SHOULD NOT implement.

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Dec 2007 13:49:42 -0800

>equivalent to MAY implement.

That sounds right.

>I think that jumping from MAY implement to MUST NOT implement 
>without a severe security concern is unfair to the implementors.

In what way? They lose nothing by removing the ciphersuite from their 
1.2 implementation, and they can leave it in their 1.0 and 1.1 
implementation at no cost.

>intent.

That is a possibility, but it is not clear who benefits from that. 
Given that TLS 1.2 has mandatory-to-implement suites that we all 
agree on, what is the benefit of listing ones as MAY that there is 
less than full confidence in?

>I think the will-become-MUST-NOT ciphersuites should be MAY 

See my previous message: SHOULD NOT makes no logical sense for 
interoperability, which is what we should be concerned with.

--Paul Hoffman, Director
--VPN Consortium

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Dec 2007 13:58:09 -0800

At Thu, 20 Dec 2007 16:39:42 -0500,
> equivalent to MAY implement.

Agreed.

> a severe security concern is unfair to the implementors.

I don't really get that. Again, they can continue to use it for
TLS 1.1. I mean, does anyone actually use it? 

> document, but I can live with SHOULD NOT implement.

So, I think this is a different case in that there really used to be
servers which would break if you didn't send the v2 hello and so
we really wanted to encourage this transition. I don't think IDEA is really
that similar.

-Ekr

---

From: "Kyle Hamilton" <[email-masked]>
Date: Thu, 20 Dec 2007 14:05:50 -0800

My largest issue with the way TLS is done is that it encodes policy as
"MUST NOT" statements.  The concept of applying a patent policy as a
MUST NOT is ridiculous -- there's more than enough room in a
conformant implementation to avoid using IDEA if patent constraints
exist.

I can see a clause stating that "implementations MUST NOT enable
non-canonical ciphers by default", but I can't see a clause absolutely
forbidding something based on patent constraints.

(Why has there not been an extension mechanism defined for research
and development work other than "hoping it doesn't conflict in the
future"?)

-Kyle H

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Dec 2007 14:19:14 -0800

At Thu, 20 Dec 2007 14:05:50 -0800,
> conformant implementation to avoid using IDEA if patent constraints

This doesn't have anything to do with patents. It's purely an issue
of security and the fact that we don't really understand the security
of IDEA (yes, that's partly because it's unused due to patent
constraints) and that we now have algorithms that we're much
more comfortable with.

-Ekr

---

From: Russ Housley <[email-masked]>
Date: Thu, 20 Dec 2007 17:23:06 -0500

Eric & Paul:

I guess I see the fundamental difference in our thinking.  Do we want 
the ciphersuite processing to be specific to a TLS version?  If you 
want IDEA, then negotiate TLS 1.1.  By this line of thought, 
negotiate TLS 1.0 to use DES40.  My feeling is that when we deprecate 
an algorithm, we do not want it to be used in any of the versions 
that are supported by the implementation.  This is the reason that I 
advocate a polite egress...

Russ

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Dec 2007 14:31:20 -0800

At 5:23 PM -0500 12/20/07, Russ Housley wrote:
>I guess I see the fundamental difference in our thinking.  Do we 
>want the ciphersuite processing to be specific to a TLS version?  If 
>you want IDEA, then negotiate TLS 1.1.  By this line of thought, 
>negotiate TLS 1.0 to use DES40.  My feeling is that when we 
>deprecate an algorithm, we do not want it to be used in any of the 
>versions that are supported by the implementation.  This is the 
>reason that I advocate a polite egress...

This is fundamentally different from the way that TLS has been 
updated in the past. If the WG wants to adopt the "this set of 
ciphersuites is for all versions of TLS" approach, it does indeed 
make sense to have phased approach such as "MAY in this version, but 
we intend to make this MUST NOT in the future".

However, that "algorithms for all versions" approach is not what the 
TLS WG is discussing at the moment. We are discussing the algorithm 
requirements that apply to TLS 1.2 only. The proposal to do 
algorithms for all versions is a new one.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Dan Harkins" <[email-masked]>
Date: Thu, 20 Dec 2007 14:32:59 -0800 (PST)

Russ,

  It's kind of hard for version X of a protocol to mandate behavior
in shipping product that support version less-than-X of the same
protocol. I think we're stuck with ciphersuite processing being
specific to version.

  Your approach seems "nicer" but impractical.

  Give a guy writing code the opportunity to parse "SHOULD NOT" and
he's gonna think, well I have 10 other things I have to do this week
so instead of removing IDEA from my TLS 1.2 implementation I'll just
commit it and get on to the other things on my plate. Polite egress
will be politely ignored and eventually we'll run into the same
situation of a hard and fast stop on use of a ciphersuite. That being
the case why not just get it over with now-- you MUST NOT use IDEA
with TLS 1.2.

  Dan.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Dec 2007 14:32:40 -0800

At Thu, 20 Dec 2007 17:23:06 -0500,
> advocate a polite egress...

I think we've already crossed this bridge. Here's RFC 4346:

   When SSLv3 and TLS 1.0 were designed, the United States restricted
   the export of cryptographic software containing certain strong
   encryption algorithms.  A series of cipher suites were designed to
   operate at reduced key lengths in order to comply with those
   regulations.  Due to advances in computer performance, these
   algorithms are now unacceptably weak, and export restrictions have
   since been loosened.  TLS 1.1 implementations MUST NOT negotiate
   these cipher suites in TLS 1.1 mode.  However, for backward
   compatibility they may be offered in the ClientHello for use with TLS
   1.0 or SSLv3-only servers.  TLS 1.1 clients MUST check that the
   server did not choose one of these cipher suites during the
   handshake.  These ciphersuites are listed below for informational
   purposes and to reserve the numbers.

Not saying that's right, but there it is...

-Ekr

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Thu, 20 Dec 2007 17:45:31 -0800

Can we just drop mention of ciphersites that no one uses?  

They would still be in the IANA registry.  Isn't this what is usually
done, removing unused features, as a standard progresses.  

> -----Original Message-----
> From: Paul Hoffman [mailto:[email-masked]] 
> Sent: Thursday, December 20, 2007 2:31 PM
> To: Russ Housley; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [TLS] Status of IDEA
> 
> negotiate 
> >TLS 1.0 to use DES40.  My feeling is that when we deprecate an 
> >algorithm, we do not want it to be used in any of the 
> versions that are 
> >supported by the implementation.  This is the reason that I 
> advocate a 
> >polite egress...
> 
> This is fundamentally different from the way that TLS has 
> been updated in the past. If the WG wants to adopt the "this 
> set of ciphersuites is for all versions of TLS" approach, it 
> does indeed make sense to have phased approach such as "MAY 
> in this version, but we intend to make this MUST NOT in the future".
> 
> However, that "algorithms for all versions" approach is not 
> what the TLS WG is discussing at the moment. We are 
> discussing the algorithm requirements that apply to TLS 1.2 
> only. The proposal to do algorithms for all versions is a new one.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
>

---

From: [email-masked] (Peter Gutmann)
Date: Fri, 21 Dec 2007 15:51:03 +1300

Russ Housley <[email-masked]> writes:

>I'm suggesting something similar for ciphersuites.

Given that that text has been present in the spec for more than *ten years*
(!!), perhaps the cipher equivalent should give an end-of-life date otherwise
we'll still be having this debate in 2017.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 20 Dec 2007 19:24:35 -0800

At Thu, 20 Dec 2007 17:45:31 -0800,
> done, removing unused features, as a standard progresses.  

The TLS practice has been to list them in the document to reserve
the code point but forbid their use.

-Ekr

---

From: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 20 Dec 2007 22:18:23 -0800

Eric and all,

  For the record, I much prefer normally MUST NOT to SHOULD NOT.

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: "Jeffrey A. Williams" <[email-masked]>
Date: Thu, 20 Dec 2007 22:19:56 -0800

Paul and all,

  Very much agreed and well argued, Paul.

Regards,

---

From: Brad Hards <[email-masked]>
Date: Fri, 21 Dec 2007 12:50:03 +1100

> constraints) and that we now have algorithms that we're much
That vaguely sounds like "should not" (as opposed to "SHOULD NOT") to me - not 
advised, but nothing actually known to be wrong with it. 

If we actually knew of a problem, then IDEA would be "MUST NOT".

Brad

---

From: <[email-masked]>
Date: Fri, 21 Dec 2007 12:32:10 +0200

Eric Rescorla wrote:

> > They would still be in the IANA registry.  Isn't this what 
> > is usually done, removing unused features, as a standard 
> > progresses.  
> 

I think Joe's suggestion makes sense: just remove the IDEA
ciphersuites from this document. (This way, the base spec
contains only things we consider a good idea to implement.)

We don't need to forbid their use, and there's no need to 
mark the code points reserved in *this* document (the IANA
registry is anyway the official source on what code points 
have been allocated).

Best regards,
Pasi

---

From: <[email-masked]>
Date: Fri, 21 Dec 2007 12:37:21 +0200

The ciphersuites deprecated in RFC4346 are slightly different case,
because they required special key processing in the TLS handshake
protocol (key calculation for those "export" ciphersuites worked
slightly differently). And that special key calculation procedure
was removed in TLS 1.1.

IDEA and single-DES don't require anything special here, so
they can be version-agnostic.

Best regards,
Pasi

> From: ext Eric Rescorla [mailto:[email-masked]] 
> Sent: 21 December, 2007 00:33
> To: Russ Housley
> Cc: [email-masked]; [email-masked]
> > deprecate

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 21 Dec 2007 12:40:17 +0100

> contains only things we consider a good idea to implement.)

And the DES ciphersuites?

I would support removing IDEA from the document, or marking it as MUST
NOT, or whatever it takes to make people not consider implementing it.

/Simon

---

From: Mohamad Badra <[email-masked]>
Date: Fri, 21 Dec 2007 13:14:40 +0100

> NOT, or whatever it takes to make people not consider implementing it.

Why don't we allocate values with first byte decimal 192 (0xC0) and then 
add an "informational section on IDEA ciphersuites" to the document?

Best regards,
-- 
Mohamad Badra
CNRS - LIMOS Laboratory

---

From: Chris Newman <[email-masked]>
Date: Fri, 21 Dec 2007 10:27:59 -0800

I support "MUST NOT enable IDEA for TLS 1.2."

Real world security requires a lot more than just a theoretically secure 
protocol, it requires a simple implementation with minimal code complexity and 
well tested code paths.  It requires a configuration mere mortals can 
understand and it does the right thing even if those mere mortals have no 
understanding what a cipher suite is or the security properties of IDEA.

One thing people get is version numbers.  They will assume TLS 1.1 is more 
secure than TLS 1.0.  They will assume TLS 1.2 is more secure than TLS 1.1. 
The more we make that true, the more secure real-world systems will be.

Options make security systems less secure in practice, and rarely used options 
can make security systems much less secure in practice.  IDEA is clearly a 
rarely used option.  If negotiating TLS 1.2 means IDEA is never used, then TLS 
1.2 is more secure (at least by the "lines of code where vulnerabilities can 
lurk" measure) than TLS 1.1.

I support maximizing both the theoretical and real-world security of software 
that chooses to be TLS 1.2 compliant.

                - Chris

---

From: Hovav Shacham <[email-masked]>
Date: Mon, 31 Dec 2007 14:47:46 -0800

> If we actually knew of a problem, then IDEA would be "MUST NOT".

Weighing in late, I support "MUST NOT."  The conservative  
interpretation of an absence of extensive studies of a block cipher  
is that the security of that cipher cannot be relied upon.  And there  
is no reason now to prefer IDEA to AES.  I think "MUST NOT" will do  
the best job of steering implementations towards known-secure cipher  
suites.

Cheers --
Hovav.