Subject: [TLS] Publishing draft-ietf-tls-56-bit-ciphersuites as Historic

From: Yuhong Bao <[email-masked]>
Date: Fri, 25 Mar 2016 10:16:59 -0700

I wonder if it would be possible to publish draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC 6101).
It would start with https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 , but the ciphersuites 0x60 and 0x61 would be added also as they were implemented in OpenSSL.

Yuhong Bao

---

From: Yoav Nir <[email-masked]>
Date: Fri, 25 Mar 2016 22:07:02 +0300

> On 25 Mar 2016, at 8:16 PM, Yuhong Bao <[email-masked]> wrote:
> 

Hi

It would be possible but I’m wondering some things:

1. Are the original authors interested, or are there alternative authors willing to take this on?

2. What is the point?  All of the ciphersuites in there have been deprecated by some diediedie document or another, and no sane document author (here or elsewhere) would include any of these 56-bit ciphers in any profile for TLS that is intended to provide security. So what is the benefit?

Yoav

---

From: Yuhong Bao <[email-masked]>
Date: Fri, 25 Mar 2016 12:10:29 -0700

> 2. What is the point? All of the ciphersuites in there have been deprecated by some diediedie document or another, and no sane document author (here or elsewhere) would include any of these 56-bit…

That is why I called them "historic".

---

From: Hubert Kario <[email-masked]>
Date: Tue, 29 Mar 2016 13:15:52 +0200

On Friday 25 March 2016 22:07:02 Yoav Nir wrote:
> > I wonder if it would be possible to publish
> > draft-ietf-tls-56-bit-ciphersuites as Historic (in the sense of RFC
> > 6101). It would start with
> > https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuites-01 ,
> > but the ciphersuites 0x60 and 0x61 would be added also as they were
> > implemented in OpenSSL.
> > 
> > Yuhong Bao
> 
> Hi
> 
> 2. What is the point?  All of the ciphersuites in there have been
> deprecated by some diediedie document or another, and no sane
> document author (here or elsewhere) would include any of these 56-bit
> ciphers in any profile for TLS that is intended to provide security.
> So what is the benefit?

1. Showing why the code points are reserved.
2. Having official list of code points which must not be enabled (so 
   that scanners can be complete)

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Mar 2016 15:09:16 +0300

> On 29 Mar 2016, at 2:15 PM, Hubert Kario <[email-masked]> wrote:
> 

Right. But this draft does not include RC4, RC2, and a number of other bad IDEAs (pun intended), so it’s not a comprehensive list of things you shouldn’t be doing.

Yoav

---

From: Hubert Kario <[email-masked]>
Date: Tue, 29 Mar 2016 16:42:34 +0200

On Tuesday 29 March 2016 15:09:16 Yoav Nir wrote:
> Right. But this draft does not include RC4, RC2, and a number of other
> bad IDEAs (pun intended), so it’s not a comprehensive list of things
> you shouldn’t be doing.

it's not a die-die-die document. It's a document that will add the IDs 
to https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

0x00,0x62 has no intrinsic meaning. TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA 
has.

What to do with them is second step.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Mar 2016 17:45:25 +0300

> What to do with them is second step.

Oh, sorry. I hadn’t realized those were not in the registry.

Yoav