Subject: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Apr 2014 11:50:22 -0700

Folks,

Andrei Popov has refreshed his draft on deprecating RC4:

http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02

There was significant WG support for this draft previously and
then the discussion migrated to UTA where it does not seem
to be terminating.

The chairs would like to hear from WG members whether they
support adoption of this draft in TLS. While this is not a formal
call for adoption, if we get strong support we will immediately
move for adoption, so now is a good time to raise any
objections you have.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Fri, 11 Apr 2014 12:17:07 -0700

> move for adoption, so now is a good time to raise any

Let's publish this.  It's good to say that RC4 is bad and shouldn't be
used when it is so clearly bad.

Yoav seemed to be in favour of making a broader statement that covers
other uses of RC4.  I don't see any harm in making the narrower
statement, particularly since it sets a precedent others can rely on.
If someone wanted to write a "don't use RC4 anywhere, ever" draft,
that might be a harder thing to do, but I'd support that as long as it
didn't cause this to become mired in red tape.

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 11 Apr 2014 21:19:10 +0200

> then the discussion migrated to UTA where it does not seem

I'm not sure I've seen all the discussion about this topic, so I
want to at least give my remarks.

I think the goal is that RC4 should not be negiotiated anymore,
unless there is no other option.  I think Microsoft started to
stop sending RC4 in it's initial handshake, but on failure does
send it, which seems to be going for that goal.

There are sites out there where RC4 is the only option of the
ciphers offered by current browsers.  But there are also servers
that pick RC4 if you offer any RC4 cipher even when it's the last
one in your list.  And I think we want to really prevent servers
from picking RC4 when there are other ciphers available that both
are willing to use.

So I would really like to see the other browsers adopt what
Microsoft is already doing, and server to not pick RC4.

The lists of cipers in appendix A is also very short, there are
more ciphers with RC4 that can be used in TLS.

Kurt

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 11 Apr 2014 15:31:37 -0400

> http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02

I would be happy to see RC4 go away, and if this helps push the 'net
across that boundary, I would be happy to see it.

I have two concerns with the current draft, though:

0) XP, WinServer2003, and even weaker ciphers
----------------------------------------------

Windows XP and Windows Server 2003 offer a very limited selection of
ciphersuites:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa380512%28v=vs.85%29.aspx

The only two ciphers that are close to plausible here RC4 and 3DES-CBC.
 The other ones are even weaker.

If we say that such a system shouldn't offer RC4, should they continue
offering the even weaker ciphers as well, like TLS_RSA_WITH_DES_CBC_SHA
or, uh, TLS_RSA_WITH_NULL_SHA ?  Do we have comparable text that
deprecates these other ciphers?

Windows XP was EOL'ed earlier this week, but everyone knows that it is
still in disturbingly widespread use.

Windows Server 2003 is supposed to be in extended support until the
middle of 2015.

Is there any prospect of an SChannel update for these systems that would
make these clients behave better on the modern network?

1) opportunistic TLS in fallback-to-clear contexts
---------------------------------------------------

as broken as RC4 is, it's better than cleartext.  There are contexts in
which TLS is used only when it can be negotiated, and otherwise the same
communication is retried in the clear.  One such example is SMTP mail
delivery.

It would be a net loss in security if this draft caused a mailserver to
fail to negotiate TLS, and then it came back and reconnected to deliver
the same message in the clear.

Some text that thoughtfully acknowledges this context and indicates what
servers and clients should do knowing that old peers exist would
probably be useful.

More generally, and i know i've banged on this drum before, i wish we
had a better idea about how to proactively deprecate weak crypto in
general.  It seems like we always do it in an ad-hoc fashion, and we
roll out new crypto without a thought about how we're going to deal with
its inevitable demise (except maybe by yanking it in some ad-hoc way in
the future).  I've got no good recommendations for how to do this, but i
would love to hear some.

	--dkg

---

From: "Peter Yee" <[email-masked]>
Date: Fri, 11 Apr 2014 13:00:10 -0700

I'm in favor of deprecating RC4 in TLS.  The only plausible arguments I've
heard of are for support of legacy systems.  Given how long it takes new
changes in TLS to be adopted anyhow, we should be deprecating RC4 now and
trying to give legacy systems an impetus to move on to better algorithms.
Given no other guidance there's a lot of inertia that will keep many sites
offering RC4, at least until something catastrophic happens.

                -Peter

From: TLS [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: Friday, April 11, 2014 11:50 AM
To: [email-masked]
Subject: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)

Folks,

to be terminating.

objections you have.

-Ekr

---

From: Andrei Popov <[email-masked]>
Date: Fri, 11 Apr 2014 20:16:27 +0000

Correct, IE no longer sends RC4 in the first connection attempt, in an effort to negotiate something other than RC4 with those servers that prefer RC4, but also have other cipher suites in common with IE. After implementing this, we saw a significant decrease in the percentage of RC4 connections negotiated by IE.

Another thing we did lately (and this applies broader than IE changes) is we prioritized RC4 cipher suites at the bottom of the list (http://support.microsoft.com/kb/2929781/en-us ). The TLS servers that take client priorities into account (there is a surprisingly high percentage of those) are now less likely to pick RC4, when talking to schannel-based clients.

The above measures are just the beginning of the RC4 deprecation process; over time we would like to completely remove RC4 support from schannel.

> The lists of ciphers in appendix A is also very short, there are more ciphers with RC4 that can be used in TLS.

Yes, I'll update the list in the next revision of the I-D.

Cheers,

Andrei

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Kurt Roeckx
Sent: Friday, April 11, 2014 12:19 PM
To: Eric Rescorla
Cc: [email-masked]
Subject: Re: [TLS] Deprecating RC4 (was: draft-ietf-tls-encrypt-then-mac)

On Fri, Apr 11, 2014 at 11:50:22AM -0700, Eric Rescorla wrote:
> There was significant WG support for this draft previously and then 
> the discussion migrated to UTA where it does not seem to be 
> terminating.

I'm not sure I've seen all the discussion about this topic, so I want to at least give my remarks.

I think the goal is that RC4 should not be negiotiated anymore, unless there is no other option.  I think Microsoft started to stop sending RC4 in it's initial handshake, but on failure does send it, which seems to be going for that goal.

There are sites out there where RC4 is the only option of the ciphers offered by current browsers.  But there are also servers that pick RC4 if you offer any RC4 cipher even when it's the last one in your list.  And I think we want to really prevent servers from picking RC4 when there are other ciphers available that both are willing to use.

So I would really like to see the other browsers adopt what Microsoft is already doing, and server to not pick RC4.

The lists of cipers in appendix A is also very short, there are more ciphers with RC4 that can be used in TLS.

Kurt

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

---

From: Stephen Checkoway <[email-masked]>
Date: Fri, 11 Apr 2014 16:34:49 -0400

On Apr 11, 2014, at 2:50 PM, Eric Rescorla <[email-masked]> wrote:

> support adoption of this draft in TLS.

I support adoption.

-- 
Stephen Checkoway

---

From: Yoav Nir <[email-masked]>
Date: Fri, 11 Apr 2014 23:38:55 +0300

Hi, dkg

It’s not clear to me whether the draft is targeted at developers or deployers. If the former, it comes too late to apply to XP and Win2003. If the latter, you can still configure your server to only offer 3DES. While not the best cipher out there, if someone is stuck and cannot upgrade to Win2008, it is (as you say) the only plausible thing.

For people stuck on XP, there’s still Chrome, Firefox, and Opera. If they insist on using software that is all 10 years old, a new RFC can’t apply to them. If you use IE you can’t turn off ciphersuites. Or maybe there’s some secret registry hack, but if you’re technical enough to hack the registry, you’re technical enough to install a more modern browser or OS.

Those other weak ciphers should be gone as well. There is no good reason today to have “export” ciphersuites. NULL can stay, but nobody in their right minds uses that in a server that is supposed to offer confidentiality. Those ciphersuites are like AH in IPsec, a rarity that is useful in a few edge cases.

As for opportunistic encryption, while it’s true that RC4 is better than nothing, anything that can do RC4 can do better things. Even if those "better things" are 3DES-CBC in TLS 1.0.

Yoav

---

From: Geoffrey Keating <[email-masked]>
Date: 11 Apr 2014 14:32:42 -0700

> move for adoption, so now is a good time to raise any

I support adoption of this draft.

I'd like to see other stream ciphers standardised as replacements, but
even if there are none, I would still support the draft.

---

From: Matt Caswell <[email-masked]>
Date: Fri, 11 Apr 2014 22:38:08 +0100

> move for adoption, so now is a good time to raise any

+1 for adoption.

There is no point in waiting for legacy support for RC4 to die out
naturally before deprecating it. The whole point of deprecation is to
encourage its demise.

Matt

---

From: "Jim Schaad" <[email-masked]>
Date: Fri, 11 Apr 2014 16:46:31 -0700

+1 for adoption of the draft in the WG.

Jim

Folks,

-Ekr

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Sun, 13 Apr 2014 11:27:52 +0200

> move for adoption, so now is a good time to raise any
I support adoption of this draft by the TLS WG.

If the SSH people (and/or others) want to join in and a draft with larger scope
than just TLS can be finalized pretty fast, it would be great. Otherwise, I
think it's better to deprecate RC4 in TLS asap, and let the other protocols
follow at their own pace.

Manuel.

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 14 Apr 2014 12:42:52 +0200

I support adoption

Johannes

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 14 Apr 2014 12:03:55 +0100

I sent a mail to the SSH list. Right now it looks
to me like it might be better for TLS and SSH to
handle this separately, however each WG wants to
deal with it. If that changes and you're in the
middle of doing stuff on this, I'll yell.

Cheers,
S.

---

From: Richard Hartmann <[email-masked]>
Date: Mon, 14 Apr 2014 13:11:38 +0200

Strong support.

Richard

Sent by mobile; excuse my brevity.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 14 Apr 2014 15:05:19 +0300

+1

Yoav

Sent from a computer. Brief nonetheless.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 14 Apr 2014 11:01:05 -0400

> support adoption of this draft in TLS.

Yes please!

>  While this is not a formal

'm confused -- why hold a pre-adoption call and then another adoption call?
(not trying to be an ass, really wondering)

W

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 14 Apr 2014 08:06:41 -0700

> (not trying to be an ass, really wondering)

It seemed like there might be a lot of discussion and we were hoping to
let that happen and then if it looked like we were going to adopt it,
have a mostly discussion free consensus call, much like in-person
meetings where we have discussion and then a call for adoption.

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Mon, 14 Apr 2014 23:33:09 +0200 (CEST)

> http://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-02

This document does not provide any rationale for "prohibiting" RC4.

I'm not aware of any information that RC4 is "broken".  As noted in
the security consideration section of rfc6229, the RC4 keystream has
a small bias that might enable statistical plaintext recovery attacks
if the _exact_same_data_ is RC4-encrypted at the _exact_same_positions_
many many times.

There might be (higher layer) protocols that do this all by themselves
(resend the very same data over and over again) potentially including
credentials of a disclosing authentication, and there might be
communication peers that can be enticed to do this (such as web browsers).

-Martin

PS: I recently analyzed a customer problem report with a Java SSL 1.6 client
(JBoss) failing interop with our server.  The client's Finished message
decrypted into garbage with CBC cipher suites.

It could be that there is an interop problem in Java SSL clients
(Sun/Oracle's SSL 1.6 client) with block cipher based cipher suites.
The Sun/Oracle SSL 1.6 client sends RC4_128 first in the list, and if
our server was configured to prefer RC4_128 over AES128_CBC, then
the interop problem would not occur.  The 3DES_EDE_CBC cipher suite
also failed interop.  A quick test with OpenSSL confirmed that the
Sun/Oracle Java client was botching the CBC cipher suite handshakes.

---

From: Martin Thomson <[email-masked]>
Date: Mon, 14 Apr 2014 16:35:07 -0700

> communication peers that can be enticed to do this (such as web browsers).

I'm pretty sure that both instances of "might be" can be replaced by
"are".  Web browsers use HTTP in this way.  Hence the desire to end
RC4 use, at least in that context.

---

From: [email-masked] (Martin Rex)
Date: Tue, 15 Apr 2014 02:51:24 +0200 (CEST)

Martin Thomson wrote:
[ Charset UTF-8 unsupported, converting... ]
> RC4 use, at least in that context.

I don't think so.  A TLS protected communication involves two communication
peers, and web browsers are only a fraction of the communication peers
in existence (less than half).

Web Browsers, in particular those that aggressively execute everything
that is sent to them in one way or another, may want to deprecate RC4-based
cipher suites fairly quickly.  They're free to do so.

But the story is different for TLS peers which are less aggressive about
executing attacker-supplied active content, and it is different for
servers, which do not have the option of a reconnect fallback.

What should be done, similar to previous documents of that kind,
is provide a useful rationale to the readers of the document, so that
they can make a conscious decision and security trade-off between
interoperability with an installed base and a potential risk of
plaintext recovery under specific, and not necessarily regular conditions.

Other examples for rationales:

MD2:    https://tools.ietf.org/html/rfc6149#section-2
MD4:    https://tools.ietf.org/html/rfc6150#section-2
MD5:    https://tools.ietf.org/html/rfc6151#section-2
SSLv2:  https://tools.ietf.org/html/rfc6176#section-2

DES in TLS:       https://tools.ietf.org/html/rfc5469#section-4
DES in Kerberos:  https://tools.ietf.org/html/rfc6649#section-4

Personally, I would consider it irresponsible to publish an
RFC for deprecation of RC4-based TLS cipher suites *WITHOUT*
an adequate rationale / security considerations.

-Martin

---

From: Watson Ladd <[email-masked]>
Date: Mon, 14 Apr 2014 19:11:57 -0700

> servers, which do not have the option of a reconnect fallback.

It really isn't. If you look at the graphs presented in the 2013 RC4
paper (and you did look at this paper, right?), you will see they
ignore two things: the fact that plaintext usually has structure, and
the cross-byte correlations which are known to exist. That's why RC4
is dead: the initial bytes are just icing on the cake for a serious
attacker.

Furthermore, the reason browsers have been unable to drop RC4 entirely
is misconfigured servers that offer only RC4. Moving away from RC4
needs to begin now.

Lastly, at what point do you want us to call RC4 broken? Academic
cryptographers had a spate of results against it 2001-2002,
culminating in wepcracker. When WEP was replaced by WPA, this stopped
being so interesting, and I think 90% of them would have recommend
against continuing to use it at that point. However, I'm sure Fort
Meade has keep looking.

(By the way, TLS was supposed to make everything web browsers do to it
now perfectly safe. That's where it was designed)
> plaintext recovery under specific, and not necessarily regular conditions.

We don't know what those conditions are. The cryptanalysis of RC4 is
by no means over. By no means should TLS 1.3 continue to allow its
use.

> DES in Kerberos:  https://tools.ietf.org/html/rfc6649#section-4

All of which came years or in some cases a decade late. DES cracker
systems existed in 1998. MD5 was broken in 2004, as was MD4.

The IETF has a crypto problem: we are terrible at getting rid of
broken systems, or at responding appropriately. SHA-1 belongs on that
list: collisions in 2^63 time.
> an adequate rationale / security considerations.

Irresponsible why? Perhaps because it isn't convincing. But to me the
existence of 2001's Flueher-McGrew biases makes RC4 unfit for purpose.

Sincerely,
Watson Ladd

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Bill Frantz <[email-masked]>
Date: Mon, 14 Apr 2014 22:50:43 -0700

+1

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, CA 95032

---

From: Hanno Böck <[email-masked]>
Date: Tue, 15 Apr 2014 15:34:35 +0200

On Fri, 11 Apr 2014 11:50:22 -0700

> Andrei Popov has refreshed his draft on deprecating RC4:

+1 from me.

But: I think we should have this discussion more broadly. What
other algorithms exist in the TLS spec that should see deprecation? I
think there is a bunch of cruft that really shouldn't be deployed
anywhere, because we should have learned from heartbleed that code
laying around that nobody uses can be a problem.

E.g. what about deprecating DSA? Quick facts that let me believe it is
ready:
* DSA is only widely supported with 1024 bit and there is wide
  agreement that this is bad (RSA keys with 1024 bit are almost extinct)
* Everyone uses RSA anyway, DSA keys on real world websites are
  basically nonexistent (someone with fast access to one of the latest
  internet-wide scan datasets could check that).
* DSA is very weak if used with bad random numbers, see e.g. latest
  dual ec research, where they got the DSA private keys easily (this
  argument is also true for ecdsa, but I'm aware that deprecating ecdsa
  is probably much more controversial, so I say lets start with the
  easy one and deprecate DSA).
* Removing DSA suites would reduce size of TLS handshake.

I never wrote an RFC before, but if there is reasonable agreement that
DSA removal makes sense I could think of going ahead and writing a
draft similar to the RC4 one on DSA.

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: [email-masked]
GPG: BBB51E42

---

From: Yoav Nir <[email-masked]>
Date: Tue, 15 Apr 2014 16:55:51 +0300

I’m not against deprecating DSA, but there is actually nothing wrong with DSA. Use it with 2048-bit keys and you should be fine modulo implementation bugs.

If you have a bad PRNG, you need to fix the PRNG, because it will bite you some other way.

I can’t think of a single reason to use DSA as opposed to ECDSA, but we don’t generally deprecate things that still work.

Yoav

---

From: Hanno Böck <[email-masked]>
Date: Tue, 15 Apr 2014 16:03:27 +0200

On Tue, 15 Apr 2014 16:55:51 +0300
Yoav Nir <[email-masked]> wrote:

> I’m not against deprecating DSA, but there is actually nothing wrong
> with DSA. Use it with 2048-bit keys and you should be fine modulo
> implementation bugs.
> 

My opinion on that is that we should have multiple lines of defense.
Sure, if the RNG is bad we should fix it. But we all know good RNGs is
a nontrivial problem. So while fixing RNGs is a priority, we also should
have algorithms that don't completely break so badly that they spit out
the public key if the RNG fails.

-- 
Hanno Böck
http://hboeck.de/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 15 Apr 2014 14:15:11 -0400

> the public key if the RNG fails.

https://tools.ietf.org/html/rfc6979 suggests a way to use DSA that
doesn't break as catastrophically if the RNG fails.

	--dkg

---

From: Hanno Böck <[email-masked]>
Date: Tue, 15 Apr 2014 21:02:55 +0200

On Tue, 15 Apr 2014 14:15:11 -0400
Daniel Kahn Gillmor <[email-masked]> wrote:

> > Sure, if the RNG is bad we should fix it. But we all know good RNGs
> > is a nontrivial problem. So while fixing RNGs is a priority, we
> > also should have algorithms that don't completely break so badly
> > that they spit out the public key if the RNG fails.
> 

Interesting, didn't know that.

But basically, the whole discussion about DSA's security is missing the
point. It's probably possible to implement DSA in a secure way. But
what I really want to achieve is getting TLS simpler.
I think there's wide agreement that DSA if done correctly has a
security comparable to RSA. However, in TLS everyone uses RSA, nobody
uses DSA.
And I think unused code is dangerous. Because nobody cares, nobody
tests it, nobody looks at it but it still can bite you when it comes to
security. That I think is a lesson we should've learned from
Heartbleed. And therefore I think we should identify unused parts of
the TLS spec and deprecate it.

-- 
Hanno Böck
http://hboeck.de/

---

From: Tom Ritter <[email-masked]>
Date: Tue, 15 Apr 2014 17:24:50 -0400

> the TLS spec and deprecate it.

I think that's a reasonable approach.  I have no problems with
removing DSA (but keeping ECDSA around).  I also have a strong
preference to saying that any implementation of DSA/ECDSA MUST use
deterministic DSA.

I would love to get NIST* or whatever other standard body we need to
bless it so that people will accept that recommendation.  (And to be
clear, I don't want them to just bless it, I want them to poke and
prod at it and try and figure out if they can come up with any
attacks, and then bless it.)

-tom

* I hope that people's distrust of NIST would not go so far as to say
that an algorithm developed by a community contributor and blessed by
NIST is no longer trustworthy.  If so, the new tool of the NSA would
be to have NIST bless all the secure algorithms leaving us with just
insecure ones ;)

---

From: Alyssa Rowan <[email-masked]>
Date: Wed, 16 Apr 2014 23:36:13 +0100

It looks like RC4 is rapidly heading for the chopping block, with
basically unanimous consensus. Good.

In the meantime...

On 15/04/2014 14:34, Hanno Böck wrote:

> What other algorithms exist in the TLS spec that should see
> deprecation? […] E.g. what about deprecating DSA?

I actually favour, for reasons of complexity and weakness, potentially
deprecating pretty much everything that falls in the following lists,
if of course it isn't already deprecated, subject to discussion:

• Anything with NULL anything
  - An accident waiting to happen (on purpose).

• Anything EXPORT
  - Bad old days. Kill them with fire. TLSv1.1 deprecated them but
    didn't forbid them in TLSv1.0; if they're not already a MUST NOT
    somewhere, I think they should be.

• DES is already deprecated. [RFC5469]
  - What about 3DES now?

• IDEA's already deprecated. [RFC5469]
  - Little traction in the wild, due to the (now-expired) patents.

• Anything using MD5
  - Collided. Kill it off. I'd feel highly uncomfortable keeping this
    around.

• Anything using DSS/DSA certs
  - The Nonce Problem. RFC 6979 fixes this, but...
  - A live DSA certificate, now, in 2014, that isn't ECDSA? Really? ¬_¬

• ECDSA without RFC6979?
  - Because of The Nonce Problem.
  - Remember to avoid timing attacks in RFC6979.
  - I don't know where that stands regarding FIPS-compliance, for those
    that need it: but as far as I'm concerned, if FIPS is incompatible
    with RFC6979, FIPS needs fixing because it's encouraging extremely
    fragile implementations.
  - ECDSA makes me uneasy now. It shares DSA's characteristics of being
    fragile as hell. I can't help but worry it was intentionally
    designed that way.
  - We will need a new scheme soon; EdDSA or a very similar
    Schnorr-style derivative? I'd like EdDSA swapping SHA-256 for
    SHA-3, perhaps? A discussion for the future (and/or CFRG, etc).

• Anything using SHA-1?
  - Already deprecated by NIST, and by CAs and vendors in certificates
    due to ~2^61 being expensive but practical.
  - An attack is harder in a MAC scenario - but it's only a matter of
    time; it's downhill all the way from here.
  - Thoughts?
  - Forbid negotiation in TLSv1.3, maybe, but allow in TLSv1.2 and down?

• DH_anon?
  - Subject to thoughts about possible opportunistic encryption,
    although this definitely isn't the way you _want_ to do that.

• Do we really want to keep DH|ECDH as opposed to DHE|ECDHE? Why?

• RSA without forward security
  - Seems like we're heading broadly in the direction of requiring
    forward-security, which means deprecating plain old RSA in TLSv1.3
    negotiations? Thoughts?

• DHE
  - Given the complexities noted surrounding DHE parameters and lack of
    ability to negotiate them, would we be better off dropping
    conventional DHE for TLSv1.3?
  - Favour ECDHE over secp256r1 and/or Curve25519 (where the latter
    is not forbidden by FIPS-compliance, with 25519 being preference)
    as baseline instead?

I do realise that's a strongly aggressive proposed unused-feature or
not-best-practice cull, largely for reasons of complexity reduction.
Perhaps others will be able to moderate my opinions. :-)

- -- 
/akr

---

From: "Joseph Salowey (jsalowey)" <[email-masked]>
Date: Wed, 16 Apr 2014 23:33:52 +0000

I'm not to crazy about deprecating DSA in the same fashion as RC4.  I'd be fine with leaving DSA/DSS out of TLS 1.3 if there is support for that.  I like the list below, some comments inline:

On Apr 16, 2014, at 3:36 PM, Alyssa Rowan <[email-masked]> wrote:

> Signed PGP part

[Joe] Many cipher suites with NULL encryption have been added in the recent past.   I think we'll need to have more discussion on that.  I don't not currently have data on how widely they are used. 

>     somewhere, I think they should be.

[Joe] yup.  

> • DES is already deprecated. [RFC5469]

[Joe] not sure about this one.  I think the argument in keeping 3DES around is as a fallback to AES.  Not sure I buy into this, especially if we have a better alternative, perhaps CHaCha.  

>   - A live DSA certificate, now, in 2014, that isn't ECDSA? Really? ¬_¬

[Joe] yes to the above.  Perhaps there still is DSS in use, but I really would expect that to move to ECDSA.  

>     SHA-3, perhaps? A discussion for the future (and/or CFRG, etc).

[Joe] I think I'd like to bring ECDH and ECDSA into the core spec in 1.3.  We could make some of these changes as part of that.  

>   - Forbid negotiation in TLSv1.3, maybe, but allow in TLSv1.2 and down?

[Joe] yup

>     although this definitely isn't the way you _want_ to do that.

[Joe]  Why not? 

> • Do we really want to keep DH|ECDH as opposed to DHE|ECDHE? Why?

[Joe] Not sure.  

>     forward-security, which means deprecating plain old RSA in TLSv1.3

[Joe] I didn't see much objection to removing plain old RSA in the call for consensus. 

>     is not forbidden by FIPS-compliance, with 25519 being preference)

[Joe]  So, at this point I'd rather see 1.3 have a way to negotiate parameters than deprecate DHE entirely.  I'm not sure that I have a really good reason to keep DHE around other than I'm more comfortable with it.

---

From: Watson Ladd <[email-masked]>
Date: Wed, 16 Apr 2014 20:24:44 -0700

Dear all,
I support most of the removal ideas. I would like to note in
particular that 3DES has a 64-bit block, which limits the transferable
data to 2^32 blocks, and so as a backup to AES it is painful. (We
would also need to fix the EtM problem with it: a lot of work that we
don't have to do). I think DHE will fall before ECDHE, but they are
similar enough

ECDSA is a complicated story. Yes, it makes unnecessary use of a
random number generator during signing. It is much safer to add 32
bytes to the secret key, hash that with the message, take that key,
stretch to twice as long as the group order with the hash function.
The inversion of k serves no purpose now that Schnorr's patent has
expired. It cannot be batched.

However, it is still very secure. I would like to see more performant
alternatives develop, but from a security perspective it's fine. FIPS
can do it however they can, and non-FIPS people will do it the right
way. I don't think removal is the right decision at this juncture.

Sincerely,
Watson Ladd

---

From: Alyssa Rowan <[email-masked]>
Date: Thu, 17 Apr 2014 09:13:33 +0100

I don't have much time today, but really briefly, to cover this point:

On 17 April 2014 00:33:52 BST, "Joseph Salowey (jsalowey)" <[email-masked]> wrote:

>> [akr] • DH_anon?

Here's (very briefly) why not:

• Alice: "I'm fine with RSA, ECDSA or DH_anon…"
• Mallory: . o O ( A-ha! Alice is probably being opportunistic and won't catch me! )
• "Bob" (Mallory): "What a coincidence, I'm fine with DH_anon too! :D"
• /mitm'd. :(

- --
/akr

---

From: Johannes Merkle <[email-masked]>
Date: Thu, 17 Apr 2014 16:36:33 +0200

> way. I don't think removal is the right decision at this juncture.

I second that. There are ECDSA implementations out there using sound RNG/PRNG, which are not easily modified. E.g. FIPS
certified HW devices.
-- 
Johannes

---

From: Brian Sniffen <[email-masked]>
Date: Thu, 17 Apr 2014 11:15:59 -0500

Alyssa Rowan <[email-masked]> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>

Agreed, mod Martin's proposal that I understand to ask for a reasonable
path by which we strongly deprecate RC4 on clients, then after a client
generation ban RC4 on clients and deprecate for servers.

>   - An accident waiting to happen (on purpose).

We have seen between 300 and 400 customers configure eNULL or aNULL
ciphers using OpenSSL cipher strings like "HIGH:-MEDIUM:-LOW".  None
intended it when asked.

Agreed without comment on EXPORT, DES, IDEA, MD5, DSS/DSA.

3DES is currently the one cipher supported by old clients and new
servers.  Its block size is too small, but we need to do more to provide
a path out for people currently stuck using it.

ECDSA and SHA-1 must both live until ECDSA/RFC6979 or EdDSA (and SHA-2
or SHA-3) are in common use; it doesn't do anyone any favors to churn
that faster than new implementations can become common.  What's the
right time-line for that?

>     forward-security, which means deprecating plain old RSA in TLSv1.3

This will drive performance-sensitive providers of bulk, non-secret data
to stick with TLS 1.2 for years.  That may be okay.

-Brian

-- 
Brian Sniffen
Information Security
Akamai Technologies

---

From: Bill Frantz <[email-masked]>
Date: Sat, 19 Apr 2014 08:55:23 -0700

There are two use cases to keep in mind here:

There are environments which need authentication and replay 
protection but can not use secrecy. Amateur radio communications 
comes to mind where the FCC regulations forbid encoding a 
message with the intent of obscuring its meaning.

Now the risks of having secrecy compromised in the many palaces 
we want to have it out weigh the advantages of supporting this 
small part of of the use space, but at least we should think for 
a moment about the choice.

The other use case to always keep in mind is limited performance 
devices. With the Internet of Things, we will continue to see 
new 8 bit, and possibly even 4 bit processors as manufactures 
drive in the direction of the small, low power, and cheap. These 
devices will be much safer if they have authentication and 
replay protection. While secrecy is probably not as important, 
it might also be vital in certain applications of these devices.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | Truth and love must prevail  | Periwinkle
(408)356-8506      | over lies and hate.          | 16345 
Englewood Ave
www.pwpconsult.com |               - Vaclav Havel | Los Gatos, 
CA 95032

---

From: Watson Ladd <[email-masked]>
Date: Sat, 19 Apr 2014 10:44:28 -0700

On Sat, Apr 19, 2014 at 8:55 AM, Bill Frantz <[email-masked]> wrote:
> There are environments which need authentication and replay protection but
> can not use secrecy. Amateur radio communications comes to mind where the
> FCC regulations forbid encoding a message with the intent of obscuring its
> meaning.
>
> Now the risks of having secrecy compromised in the many palaces we want to
> have it out weigh the advantages of supporting this small part of of the use
> space, but at least we should think for a moment about the choice.

Authenticated only channels are occasionally nice, we can do them, but
most users don't need them, and most implementations don't keep them
separate enough to avoid mistakes.

>
>
> The other use case to always keep in mind is limited performance devices.
> With the Internet of Things, we will continue to see new 8 bit, and possibly
> even 4 bit processors as manufactures drive in the direction of the small,
> low power, and cheap. These devices will be much safer if they have
> authentication and replay protection. While secrecy is probably not as
> important, it might also be vital in certain applications of these devices.

So AES-CCM fixes one issue (the wire PDU), but we really, really, need
a hash for the handshake. These devices also might not even have
random number generators that aren't deterministic or a counter to
avoid replays. There's a lot to be done: benchmarking, thinking hard
about protocol problems that might cause issues, determining what we
can and cannot provide.

>From some cursory research, hash functions are the real issue here.
AES is byte-oriented, but Keccak is slow as molasses at big capacities
sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR
benchmark data?

JW Bos has some ideas about reusing AES in a hash construction of
double the size.

With ECC life can get interesting. Drop the idea of RSA and DHE over
F_p: too slow. 8 bit saturated arithmetic is probably the best.
Timings are pretty slow: lots of verifications are a terrible idea.
With PSK you don't need any of this, but I think that some embedded
CPUs have the horsepower to do ECC, even at 8 bits. Make sure that
this happens rarely, i.e. mostly static keys so results can be cached,
and I think we are good. Due to memory pressure ladders are great.

I've never seen a 4 bit micro. Anyone got details on what they are
like and can do?
Sincerely,
Watson Ladd

> (408)356-8506      | over lies and hate.          | 16345 Englewood Ave
> www.pwpconsult.com |               - Vaclav Havel | Los Gatos, CA 95032
>
>

---

From: Samuel Neves <[email-masked]>
Date: Sat, 19 Apr 2014 20:52:56 +0100

> sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR

The XBX team's report on SHA-3 finalists [1] might be of use here. It argues that memory, rather than CPU cycles, is the
primary concern on 8-bit CPUs, and ends up recommending Keccak for the Atmel ATmega 1284P.

[1] http://csrc.nist.gov/groups/ST/hash/sha-3/Round3/March2012/documents/papers/WENZEL_BENNER_paper.pdf

---

From: Bill Frantz <[email-masked]>
Date: Sat, 19 Apr 2014 16:17:00 -0700

>about protocol problems that might cause issues, determining what we

One way to address the random number problem is to use the 
protocol that most web sites used with SSL. In that protocol, 
the client generated the random number and encrypted it with the 
server's public key. With the Internet of Things (IoT), having 
the controller end, which usually has a UI and lots of 
opportunity to generate good, unguessable numbers, generate the 
random number and the "thing" accept it might work well. A way 
to be agnostic about which was the client and which was the 
server is a protocol where if either end had good unguessable 
numbers, the resulting connection was secure would be nice. 
Getting perfect forward security in this environment might be hard.

>sans SIMD. SHA-256 and friends all use 32 bit addition. Anyone got AVR

We should think about the performance requirements here. If I am 
instructing my Nest thermostat to warm up the house because i'm 
coming home, several seconds is more than acceptable. If I am 
building a light show for the bulbs in my living room, probably 
1/10 of a second is acceptable, and 1/100 of a second is 
certainly good enough.

>...

Hmmm, my first read had ECC as Error Correction Codes but the 
paragraph reads a lot better if I read Elliptic Curve 
Cryptography. :-)

When we look at these processors, although the slower the clock, 
the less power required, there is a limit. If we run the clock 
much below 1 MHz, we have reached the point of seriously 
diminishing returns. 100 MHz is much more realistic. Since 
Elliptic Curve Cryptography gives more security/cycle than 
discrete logs, it is a very attractive technology.

>I've never seen a 4 bit micro. Anyone got details on what they are

Look up the Intel 4004 for an early example. I don't know we 
will see the 4 bit wide ALUs again, but the drive for low cost, 
low power, and cheap is certainly still alive and well.

Cheers - Bill

-----------------------------------------------------------------------
Bill Frantz        | "The only thing we have to   | Periwinkle
(408)356-8506      | fear is fear itself." - FDR  | 16345 
Englewood Ave
www.pwpconsult.com | Inaugural address, 3/4/1933  | Los Gatos, 
CA 95032