Subject: [TLS] Consensus Call on MTI Algorithms

From: Joseph Salowey <[email-masked]>
Date: Wed, 1 Apr 2015 11:12:19 -0700

We did not get a chance to talk about MTI algorithms in Dallas, but the
chairs would like to judge consensus for the algorithms discussed in the
interim.  The CFRG has closed or will close soon on ChaCha20 and curve
25519 recommendations so they are included.  We will be calling for
acceptance to bring drafts on these into the working group shortly.

Keep in mind that mandatory to implement (MTI) is not mandatory to use and
that it is expected that there will be profiles for specific environments.

Below is the proposed algorithm list that had consensus at the Seattle
Interim. Please reply on the TLS mailing list indicating whether or not you
agree with the consensus.  If not, please indicate why.  This consensus
call will close on April, 23, 2015.

o Symmetric:
        MUST AES-GCM 128
        SHOULD ChaCha20-Poly1305

o Hash:
        MUST SHA-256

o Key Agreement: ECDH
        MUST P-256
        SHOULD 25519

o Signature:
        MUST ECDSA P-256
        MUST RSA

Thanks,

J&S

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Wed, 1 Apr 2015 18:33:48 +0000

Yes.

> We did not get a chance to talk about MTI algorithms in Dallas, but the chairs
> would like to judge consensus for the algorithms discussed in the interim.
> The CFRG has closed or will close soon on ChaCha20 and curve 25519
> recommendations so they are included.  We will be calling for acceptance to
> bring drafts on these into the working group shortly.
> 
> agree with the consensus.  If not, please indicate why.  This consensus call
> will close on April, 23, 2015.
> 
> o Symmetric:
>         MUST AES-GCM 128
>         SHOULD ChaCha20-Poly1305
> 
> o Hash:
>         MUST SHA-256
> 
> o Key Agreement: ECDH
>         MUST P-256
>         SHOULD 25519
> 
> o Signature:
>         MUST ECDSA P-256
>         MUST RSA
> 
> Thanks,
> 
> J&S

---

From: Dave Garrett <[email-masked]>
Date: Wed, 1 Apr 2015 14:43:20 -0400

>         SHOULD ChaCha20-Poly1305

Some of us would rather have both be MTI in order to force the cipher ecosystem to not be entirely reliant on AES. (there was discussion prior on-list) I don't think a SHOULD is unacceptable, though.

>         MUST SHA-256

Can we add an official MUST NOT for MD5? I assume this is generally wanted.

>         SHOULD 25519

I think Curve25519 should be a MUST at this point. I think TLS 1.3 should have an MTI curve that can pass the safety guidelines on safecurves.cr.yp.to, as this topic does get brought up from time to time. (P256 probably should be MTI too) The entire point of the CFRG drama is to get better standardized curves to replace things, so I think it's reasonable to require support.

>         MUST RSA

Any consideration for whatever CFRG wants to add here? (I don't have an opinion on the subject; just asking)

That said, the current proposal is straightforward and not unreasonable. However, I argue that adoption of relatively new standards with TLS 1.3 should not be considered optional.

Dave

---

From: Russ Housley <[email-masked]>
Date: Wed, 1 Apr 2015 14:52:50 -0400

This seems fine to me for the roughly 128-bit strength.

Russ

---

From: "Dan Harkins" <[email-masked]>
Date: Wed, 1 Apr 2015 12:18:17 -0700 (PDT)

> call will close on April, 23, 2015.

  I agree with this consensus on MTI algorithms.

  Dan.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 01 Apr 2015 21:24:58 +0200

Hi,

>         MUST RSA

+1 for MUST on ChaCha and Cuve25519.

Aaron

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 1 Apr 2015 21:47:58 +0200

> that it is expected that there will be profiles for specific environments.

I'm confused why we need a mandatory to implement when profiles
might decide to use something different.

Kurt

---

From: Brian Smith <[email-masked]>
Date: Wed, 1 Apr 2015 09:56:46 -1000

>         SHOULD ChaCha20-Poly1305

Like others, I think that ChaCha20-Poly1305 should be MUST. It uses
256-bit keys and so it better protects against future quantum and
square-root attacks compared to AES-GCM 128. Also, it is easy to make
a constant-time implementation of ChaCha20-Poly1305 that runs on a
wide variety of hardware, but it is not to easy to do so for AES or
GCM on many times of hardware.

Accordingly, I suggest instead that ChaCha20-Poly1305 MUST be
implemented unless AES-128 GCM *and* AES-256 GCM are implemented in a
constant time manner.

>         MUST SHA-256

AFAICT, it is not necessary to specify a mandatory-to-implement hash
function separately from the mandatory-to-implement cipher suites and
mandatory-to-implement signature algorithms, because the hash function
to use is always a function of the cipher suite or signature algorithm
in TLS 1.2 and later.

>         MUST RSA

"RSA" is ambiguous. For RSA, please specify which padding scheme(s)
and which parameters must be supported. I would recommend "MUST
implement RSA PKCS#1 using the same digest function used in the PRF of
the selected cipher suite."

Similarly, "MUST ECDSA P-256" should be changed to "MUST ECDSA P-256
using the same digest function used in the PRF of the selected cipher
suite."

If the requirements for mandatory-to-implement signature algorithms
are intended to also apply to certificates and certificate
verification, then ECDSA P-384 and SHA-384 MUST be implemented. The
reason is that CAs often choose algorithms for signing certificates.

Cheers,
Brian

---

From: Dave Garrett <[email-masked]>
Date: Wed, 1 Apr 2015 16:18:45 -0400

> might decide to use something different.

When defining a protocol, it should at least be written in a way that is guaranteed to work if followed to the letter.

At minimum, when an implementor that uses something else gets an interoperability failure, we can say "I told you so" and point to the fact that compliant implementations can easily be configured in a way that will work.

Dave

---

From: Stephen Checkoway <[email-masked]>
Date: Wed, 1 Apr 2015 16:41:07 -0400

>         SHOULD 25519

Like several others, I think ChaCha20-Poly1305 and X25519 should be a MUST.

>         MUST RSA

Are we going to consider whatever the CFRG eventually comes up with?

-- 
Stephen Checkoway

---

From: Sean Turner <[email-masked]>
Date: Wed, 1 Apr 2015 17:35:30 -0400

>         SHOULD ChaCha20-Poly1305

Nobody 2119-me-to-death, but I paraphrase SHOULD as: this is a MUST unless you have a really, really, really, really good reason to not do it.

spt

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Apr 2015 00:56:38 +0300

I support this.

I think it’s kind of funny to make ChaCha20-Poly1305 a SHOULD-level requirement, when (a) there is no ciphersuite that uses this algorithm in the registry, and (b) the WG has not accepted any document that proposes such a ciphersuite. But it’s just funny, not bad. I’m sure we will adopt the document soon.

Yoav

> On Apr 1, 2015, at 9:12 PM, Joseph Salowey <[email-masked]> wrote:
> 
> We did not get a chance to talk about MTI algorithms in Dallas, but the chairs would like to judge consensus for the algorithms discussed in the interim.  The CFRG has closed or will close soon on ChaCha20 and curve 25519 recommendations so they are included.  We will be calling for acceptance to bring drafts on these into the working group shortly.
> 
> Keep in mind that mandatory to implement (MTI) is not mandatory to use and that it is expected that there will be profiles for specific environments.
> 
> Below is the proposed algorithm list that had consensus at the Seattle Interim. Please reply on the TLS mailing list indicating whether or not you agree with the consensus.  If not, please indicate why.  This consensus call will close on April, 23, 2015.  
> 
> o Symmetric:
>         MUST AES-GCM 128
>         SHOULD ChaCha20-Poly1305
> 
> o Hash:
>         MUST SHA-256
> 
> o Key Agreement: ECDH
>         MUST P-256
>         SHOULD 25519
> 
> o Signature:
>         MUST ECDSA P-256
>         MUST RSA
> 
> Thanks,
> 
> J&S
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 01 Apr 2015 17:46:40 -0700

The TLS BCP (http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-11, soon 
to be published), recommends two cipher suites based on AES-256-GCM and 
SHA-384. Doesn't it make sense to have them as SHOULD, for the sake of 
continuity and also for those people who actually desire a higher level 
of bit-strength?

Also, just wondering: is ECDSA popular enough today to be a MUST? For 
example, is the CAB Forum pushing its members to deploy such certificates?

Thanks,
	Yaron

On 04/01/2015 02:56 PM, Yoav Nir wrote:
> I support this.
>
> I think it’s kind of funny to make ChaCha20-Poly1305 a SHOULD-level
> requirement, when (a) there is no ciphersuite that uses this algorithm
> in the registry, and (b) the WG has not accepted any document that
> proposes such a ciphersuite. But it’s just funny, not bad. I’m sure we
> will adopt the document soon.
>
> Yoav
>
>> On Apr 1, 2015, at 9:12 PM, Joseph Salowey <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> We did not get a chance to talk about MTI algorithms in Dallas, but
>> the chairs would like to judge consensus for the algorithms discussed
>> in the interim.  The CFRG has closed or will close soon on ChaCha20
>> and curve 25519 recommendations so they are included.  We will be
>> calling for acceptance to bring drafts on these into the working group
>> shortly.
>>
>> Keep in mind that mandatory to implement (MTI) is not mandatory to use
>> and that it is expected that there will be profiles for specific
>> environments.
>>
>> Interim. Please reply on the TLS mailing list indicating whether or
>> not you agree with the consensus.  If not, please indicate why.  This
>> consensus call will close on April, 23, 2015.
>>
>> o Symmetric:
>>         MUST AES-GCM 128
>>         SHOULD ChaCha20-Poly1305
>>
>> o Hash:
>>         MUST SHA-256
>>
>> o Key Agreement: ECDH
>>         MUST P-256
>>         SHOULD 25519
>>
>> o Signature:
>>         MUST ECDSA P-256
>>         MUST RSA
>>
>> Thanks,
>>
>> J&S
>> [email-masked] <mailto:[email-masked]>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 1 Apr 2015 18:14:26 -0700

On 1 April 2015 at 17:46, Yaron Sheffer <[email-masked]> wrote:
> AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD,

I don't see much point.  All involved likely know if they need
something that strong, which is way down there in the "we might need
it someday" category [1].

[1] http://www.keylength.com/en/3/

---

From: Watson Ladd <[email-masked]>
Date: Wed, 1 Apr 2015 22:32:19 -0700

On Wed, Apr 1, 2015 at 11:12 AM, Joseph Salowey <[email-masked]> wrote:
> interim.  The CFRG has closed or will close soon on ChaCha20 and curve 25519

I disagree with this consensus. Many devices have hardware accelerated
AES, but not GCM. As it stands we don't have an efficient performer on
these devices: AES+HMAC is probably the best option on these devices.

I also don't like the idea of making non-interoperable profiles for
different environments.

Sincerely,
Watson Ladd

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

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 02 Apr 2015 11:06:59 +0200

Hi Yaron,

> example, is the CAB Forum pushing its members to deploy such certificates?

As far as I know most commercial CAs still are not willing/able to issue
ECDSA certificates. Maybe ECDSA will go under in history entirely in a
couple of years w.r.t. Certificates?

Aaron

---

From: Rob Stradling <[email-masked]>
Date: Thu, 02 Apr 2015 10:11:58 +0100

On 02/04/15 01:46, Yaron Sheffer wrote:
<snip>
> Also, just wondering: is ECDSA popular enough today to be a MUST?

All of the certificates used by CloudFlare's "Universal SSL" are ECDSA 
certificates issued by Comodo.

When CloudFlare announced "Universal SSL" six months ago, they said:
   "Yesterday, there were about 2 million sites active on the Internet 
that supported encrypted connections. By the end of the day today, we'll 
have doubled that."

Before "Universal SSL", Netcraft's SSL Survey found only ~80 ECDSA 
publicly-trusted ECDSA certs.  But now, simply because of "Universal 
SSL", I would definitely say that ECDSA is "popular enough today to be a 
MUST".

> For example, is the CAB Forum pushing its members to deploy such certificates?

Pushing?  Not that I've noticed.

[1] https://blog.cloudflare.com/introducing-universal-ssl/

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 02 Apr 2015 04:50:30 -0700

> [1] http://www.keylength.com/en/3/

The TLS BCP is IETF consensus, not just one person's opinion. If people 
deploy stuff based on our recommendations, we should ensure that it is 
still available to them when they migrate to TLS 1.3.

Thanks,
	Yaron

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 02 Apr 2015 13:48:07 +0100

> still available to them when they migrate to TLS 1.3.

But isn't it likely we revise the TLS BCP once TLS1.3 is done and
implementations start to become common? We can make sure things
all add up at that point in time, and are in-whack with what people
are deploying, but we don't necessarily need to do so now I think.

S.

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 02 Apr 2015 05:52:36 -0700

> are deploying, but we don't necessarily need to do so now I think.

It entirely likely. But even then, I am not sure we'll be able to 
convince people who went to AES-256 (presumably, for "compliance" 
reasons) to move to ChaCha. And certainly not to AES-128...

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 2 Apr 2015 13:36:54 +0000

You mandated AES-GCM with 128-bit key. Would it be a burden to add 256-bit key support for the algorithm you have to have anyway? 

Why not add AES-GCM-256 as SHOULD? 

--
Regards,
Uri Blumenthal                            Voice: (781) 981-1638
Cyber Systems and Technology   Fax:   (781) 981-0186
MIT Lincoln Laboratory                Cell:  (339) 223-5363
244 Wood Street, Lexington, MA 02420-9185       

Web:  http://www.ll.mit.edu/CST/
MIT LL Root CA:  <https://www.ll.mit.edu/labcertificateauthority.html>

---

From: Russ Housley <[email-masked]>
Date: Thu, 2 Apr 2015 09:55:03 -0400

Yaron:

> The TLS BCP (http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-11, soon to be published), recommends two cipher suites based on AES-256-GCM and SHA-384. Doesn't it make sense to have them as SHOULD, for the sake of continuity and also for those people who actually desire a higher level of bit-strength?

Thanks for highlighting this dependency.  I support your recommendation.

Russ

---

From: Hubert Kario <[email-masked]>
Date: Thu, 02 Apr 2015 19:03:49 +0200

> call will close on April, 23, 2015.

Yes

-- 
Regards,
Hubert Kario
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: Hanno Böck <[email-masked]>
Date: Thu, 2 Apr 2015 19:16:57 +0200

Hello,

I have a number of issues with these algs, but I think these touch some
fundamentals. Given that TLS 1.3 should get "things right" for a long
timeframe I think we shouldn't shrink back from bigger decisions
however.

On Wed, 1 Apr 2015 11:12:19 -0700

>         SHOULD ChaCha20-Poly1305

GCM:
I have the feeling word of mouth in the crypto community is that nobody
really likes GCM. The only reason it gained so much popularity is
because it was "the only thing left" in TLS after CBC (in the
MtE variant) and RC4 got under attack.
I would like to discuss if this word of mouth is based on hard and if we
come to the conclusion that GCM is not a particularly good cipher mode
then I ask: Why should it be part of TLS 1.3 at all?

Especially I hear again and again people have concerns that it's close
to impossible to implement GCM timing-safe if there is no hw
instruction support.

That leaves the question what is better. One could of course say "go
with chacha/poly as the default", because it seems to be popular.
Arguments against: AES has widely hardware support and it's a
well-respected standard.
Other options: AES-CBC with EtM (Peter Gutmann just claimed here he
thinks its less brittle than GCM) or other block modes (OCB?).

>         MUST SHA-256
Fine with that.

>         SHOULD 25519

It's a bit similar to the issue above: It seems nobody really likes the
NIST curves. Claims that it's almost impossible to implement them
timing-safe. Even NIST doesn't seem to like the curves that much any
more and they want to move on.
And we had this painful discussion on 25519 now for such a long time
and most crypto people seem to like it.
Did we do that just to make it the second-best option?

If there is agreement that curve25519 is superior to the nist curves
then why keep the latter?

(There's of course also this "issue" with the NIST curves and their
random numbers of unknown origin, but it seems right now majority
opinion is that it is highly unlikely this is a sign of a backdoor.)

>         MUST RSA

It pretty much follows from above: If we agree people don't like
the NIST curves very much and every one likes curve25519 then ecdsa
with p256 should go away.
However there's even a stronger argument: ECDSA isn't that popular
either. (RNG failures.)

I'd like to add that RSA should preferrably be RSA-PSS (if we're
talking about the connection handshake sigs - for the certificate sigs
this is a different issue, for backwards compatibilty reasons it seems
hard to require pss here).

Conclusion: There seem to be a number of options in this MTI list that
are algorithms that many crypto experts think aren't that good. I don't
like that. I want TLS 1.3 to be based on algorithms people think are
the best of their kind.

(And add to that that I'm in full support of everyone saying that we
should also try to not have too many options - just causing confusion,
more attack surface and more complexity. One or two algs each and be
done with it.)

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

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

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Thu, 2 Apr 2015 17:27:31 +0000

Well, I for one do like GCM (the fact that more platforms now provide hardware acceleration makes me like it even more :), and I like NIST curves (and already have the code to deal with them). 

I guess those who dislike either one (or both) are just more vocal. 

P.S. I also like OCB, especially considering the license Phil Rogaway granted OpenSSL (or was it to TLS protocol at large? :). 

----- Original Message -----
From: Hanno Böck [mailto:[email-masked]]
Sent: Thursday, April 02, 2015 01:16 PM
To: [email-masked] <[email-masked]>
Subject: Re: [TLS] Consensus Call on MTI Algorithms

Hello,

GCM:

Fine with that.

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

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 2 Apr 2015 17:40:24 +0000

> I guess those who dislike either one (or both) are just more vocal.

That is usually how it goes.  For ANY topic in the world.

> P.S. I also like OCB, especially considering the license Phil Rogaway granted
> OpenSSL (or was it to TLS protocol at large? :).

It was first OpenSSL, then he recently stated his intent to freely license for to use in TLS.

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 13:36:23 -0500

> reasons) to move to ChaCha. And certainly not to AES-128...

Must-implement != must-deploy.

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 13:48:50 -0500

On Wed, Apr 01, 2015 at 11:12:19AM -0700, Joseph Salowey wrote:
> [...]

I'd like to have at least two required algorithms for each class, at
least for the 128-bit security level.  The rationale is: to make it easy
to switch one off if it becomes a problem.

We've already had to disable broken algorithms in a hurry in several
Internet protocols including TLS.  We should learn the lesson: we should
aim to have at least one left.

In all cases recall that required-to-implement != required-to-enable.

>         SHOULD ChaCha20-Poly1305

I would like at least two modes for AES to be required: one AEAD
(probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC).

I would like one non-AES cipher to be required.  ChaCha20-Poly1305 works
for me.

Total: three required algorithms.  Here I want three because I'm not
sure that GCM is easy enough to implement and use safely in all
environments (see Watson L.'s comments on this), and because I'd like
two ciphers just in case.

>         MUST SHA-256

I would like two hash functions to be required.  I don't have a strong
preference as to the second hash function, but I like SHA-3.

>         SHOULD 25519

By the rationale above I would like both of these to be required.

>         MUST RSA

Ditto.  We won't have the luxury of waiting until CFRG blesses an ECC
signature scheme other than ECDSA, but when they do... we should add
that to the list.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 13:53:59 -0500

On Wed, Apr 01, 2015 at 05:35:30PM -0400, Sean Turner wrote:
> Nobody 2119-me-to-death, but I paraphrase SHOULD as: this is a MUST
> unless you have a really, really, really, really good reason to not do
> it.

The same is really true of the MUST, because if AES-128-GCM dies on the
cryptanalysis table, well, we'll all want to turn it off and start
ripping it out of the implementations as soon as possible.

We really need *two* mandatory-to-implement algorithms for each class at
the 128-bit security level.

Your interpretation of SHOULD is a bit stronger than what RFC2119 says.
We shouldn't play RFC2119 interpretation games.  We should say what we
want.  We *should* want what I said above (already repeating myself).

Nico
--

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 2 Apr 2015 18:59:11 +0000

It's reasonably easy to add ciphers.  Especially since most TLS 1.3 implementations will be built on a 1.[012] codebase. 

It is nearly impossible to remove ciphers.

Because of this, I am strongly in favor of JUST TWO.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 13:35:16 -0500

> are deploying, but we don't necessarily need to do so now I think.

First, there will be no flag day.  Operators will need implementations
that support TLS 1.1 and 1.2 for a while yet.  So they should get
support for ciphersuites that used to be recommended.

Second, these are symmetric ciphers we're talking about.  Switching from
one set in 1.1 and 1.2 on the one hand, and 1.3 on the other, is an
operational non-issue.  Deprecating RSA, say, would be a much bigger
deal operationally.

Nico
--

---

From: Christian Huitema <[email-masked]>
Date: Thu, 2 Apr 2015 19:04:27 +0000

> Must-implement != must-deploy.

Not really true. If you implement something and the code is never used, then you cannot really trust that code. This is the old paradigm of the fire exit. If you never used it before the fire, you are surprised to see it rusted or blocked by debris the day there is a fire. If you implement something, you need at a minimum the equivalent of fire-drills to test that it actually works.

-- Christian Huitema

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 14:09:07 -0500

On Thu, Apr 02, 2015 at 06:59:11PM +0000, Salz, Rich wrote:
> It's reasonably easy to add ciphers.  Especially since most TLS 1.3
> implementations will be built on a 1.[012] codebase. 
> 

If *all* clients and servers implement the same required N>1 algorithms,
then removing one is possible when you still have at least one of those
remaining.  Things get dicey when you're out of required algorithms and
you need to prefer less-universal recommended algorithms, or if not all
implementations adhere to the requirements.

Now, if requiring 3 algorithms turns out to be a joke because some
implementors will ignore one, and others another, then 3 would be a very
bad number indeed; 4 would be worse.  We do have to consider how likely
this is; 3 will be more costly than 2, no doubt, and that may be enough.

> Because of this, I am strongly in favor of JUST TWO.

I can get on board with two, but then I'd want AES-128-GCM and
ChaCha20-Poly1305.  I think having two very different algorithms is a
big plus.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 2 Apr 2015 22:19:17 +0300

> On Apr 2, 2015, at 9:36 PM, Nico Williams <[email-masked]> wrote:
> 

Hi, Nico.

That’s a nice catch-phrase, but what does it mean? Suppose I am implementing a TLS library specifically for the IoT space. Being a standards-compliant implementation, my library and all its users will of course conform to the profile in draft-ietf-dice-profile. That means TLS_PSK_WITH_AES_128_CCM_8. Given this, why must I implement AES-GCM? Why should I implement ChaCha? I and any other IoT implementer will argue that the devices don’t have the memory for code that will never run. 

Sure, if I’m writing an OpenSSL, then I can implement everything and allow users to configure whatever algorithm they want. But I really don’t get what this phrase means in this context.

Yoav

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 02 Apr 2015 21:28:27 +0200

Hi,

Hmm.

I'd agree that an alternative to AES-GCM (still AES based) would be nice
-- I have this AES-OCB draft still floating around, if anybody is
interested. IBM is currently working through IPR stuff as far as I
understand. :)

Suggestion:
MUST    - AES-GCM, ChaCha20/Poly1305
SHOULD  - AES-CCM or AES-OCB

Thinking about ECDH, why even make the NIST curve mandatory to
implement? Just go with 25519 & maybe (!) a secondary non-NIST curve.

What about Ed448 as a second alternative (SHOULD) for signatures?

Aaron

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 14:44:18 -0500

On Thu, Apr 02, 2015 at 10:19:17PM +0300, Yoav Nir wrote:
> That’s a nice catch-phrase, but what does it mean? Suppose I am

I should have completed the thought :/  And I probably misunderstood
your point about compliance.

What I'd meant to say is that if external-to-the-IETF "compliance" rules
have anything to say on the matter, no problem:

 - external rules can demand additional algorithms
 - external rules can demand that some algorithms be disabled that we
   require to implement

External rules could refer to: IoT realities, protocol-specific profiles
of TLS, laws and regulations of various countries, corporate policies,
...

My catch-phrase was about the latter.

> implementing a TLS library specifically for the IoT space. Being a
> standards-compliant implementation, my library and all its users will
> of course conform to the profile in draft-ietf-dice-profile. That
> means TLS_PSK_WITH_AES_128_CCM_8. Given this, why must I implement
> AES-GCM? Why should I implement ChaCha? I and any other IoT
> implementer will argue that the devices don’t have the memory for code
> that will never run. 

This is a bit of a semantics game.  Is an implementation of TLS that
doesn't implement any of the required algorithms still TLS?  Can we have
profiles that specify different sets of required/recommended algorithms?

The answers don't really matter.  Suppose that you are implementing such
a library, you don't implement the required algorithms, and that you
call the result something like YoavTLS, or FooLangTLS ("TLS for the Foo
programming language").  Will the IETF police drag you to the IETF jail
for doing that?  No.

These requirements are really for general purpose TLS implementations.
IoT is a bit of a special case for many reasons, not just their limited
hardware capabilities.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Thu, 2 Apr 2015 16:12:35 -0400

> programming language").  Will the IETF police drag you to the IETF jail

Fortunately for you, the IETF police are only armed with water balloons made out of an over-engineered rubber that doesn't break on impact, and whilst the IETF jail was agreed to be on an island in the middle of nowhere that nobody can really get to, it has never been constructed because they've been arguing over the color to paint the roof for the past 30 years. :p

Serious answer: Just write a separate IoT TLS spec that just contains modifications for whatever isn't viable because you're creating a system not designed to necessarily interoperate with the general Internet. General TLS implementations could implement it as well, or not, depending on needs.

Dave

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 15:34:14 -0500

On Thu, Apr 02, 2015 at 04:12:35PM -0400, Dave Garrett wrote:
> Fortunately for you, the IETF police are only armed with water
> balloons made out of an over-engineered rubber that doesn't break on
> impact, and whilst the IETF jail was agreed to be on an island in the

[Not to be a total nitpicker or anything, but a water balloon that
 doesn't break probably hurts a lot more than one that does!]

> middle of nowhere that nobody can really get to, it has never been
> constructed because they've been arguing over the color to paint the
> roof for the past 30 years. :p

Also: it's just a bikeshed.  Amnesty International would have one out in
a heartbeat.

> Serious answer: Just write a separate IoT TLS spec that just contains
> modifications for whatever isn't viable because you're creating a
> system not designed to necessarily interoperate with the general
> Internet. General TLS implementations could implement it as well, or
> not, depending on needs.

Sure, that'd be nice (because different manufacturers of IoT devices
will want to know what to implement as a common denominator).

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 2 Apr 2015 13:34:55 -0700

Indeed:
https://tools.ietf.org/html/draft-ietf-dice-profile-10
-Ekr

On Thu, Apr 2, 2015 at 1:12 PM, Dave Garrett <[email-masked]> wrote:

> Fortunately for you, the IETF police are only armed with water balloons
> made out of an over-engineered rubber that doesn't break on impact, and
> whilst the IETF jail was agreed to be on an island in the middle of nowhere
> that nobody can really get to, it has never been constructed because
> they've been arguing over the color to paint the roof for the past 30
> years. :p
>
> modifications for whatever isn't viable because you're creating a system
> not designed to necessarily interoperate with the general Internet. General
> TLS implementations could implement it as well, or not, depending on needs.
>
>
> Dave
>

---

From: Dave Garrett <[email-masked]>
Date: Thu, 2 Apr 2015 16:55:33 -0400

>  doesn't break probably hurts a lot more than one that does!]

Nah, very stretchy. Just mildly annoying. But they're too expensive anyway, so it's not like you'll ever see one.

> Also: it's just a bikeshed.  Amnesty International would have one out in

Also, there's no enforcement. It's basically just an island vacation.

</joke>

> https://tools.ietf.org/html/draft-ietf-dice-profile-10

The existing TLS 1.3 spec already says:
"In the absence of an application profile standard specifying otherwise, a TLS-compliant application MUST implement the cipher suite [...]"

Maybe just describe the issue in more detail, possibly even cite some profile(s) that could be considered? I don't think there's really any disagreement here on what MTI means in this scenario, but a more thorough explanation that this section is over-ridable for specialized cases wouldn't hurt.

Dave

---

From: Yoav Nir <[email-masked]>
Date: Fri, 3 Apr 2015 00:28:09 +0300

> On Apr 2, 2015, at 11:12 PM, Dave Garrett <[email-masked]> wrote:
> 
> 

I thought the whole point of IoT (as opposed to proprietary protocols) was that it *did* interact with the Internet. But that aside, “the web” as represented by the HTTP/2 document made its own profile. For applications other than “the web”, UTA made their BCP document. For the IoT DICE made their profile. 

So everyone has their own MTI algorithms, some of them contradictory to what we are proposing to recommend. So who takes their MUSTs and SHOULDs from TLS as opposed to their own niche document?

Yoav

---

From: Nico Williams <[email-masked]>
Date: Thu, 2 Apr 2015 16:43:42 -0500

On Fri, Apr 03, 2015 at 12:28:09AM +0300, Yoav Nir wrote:
> I thought the whole point of IoT (as opposed to proprietary protocols)
> was that it *did* interact with the Internet. But that aside, “the
> web” as represented by the HTTP/2 document made its own profile. For
> applications other than “the web”, UTA made their BCP document. For
> the IoT DICE made their profile. 

I'm not entirely sure that I want my things interacting with the web.  I
may want to interact with my things across the Internet.

IoT needs something of a definition, yeah?

> So everyone has their own MTI algorithms, some of them contradictory
> to what we are proposing to recommend. So who takes their MUSTs and
> SHOULDs from TLS as opposed to their own niche document?

IoT seems rather special.  Ignoring IoT, how many profiles of TLS do you
think we'd need for the protocols and non-IoT devices we have now?

IoT's definition, scope, requirements, ... -- we're going to need to
pin these down.  As for *this* thread, I think we should factor IoT out.

Nico
--

---

From: Dave Garrett <[email-masked]>
Date: Thu, 2 Apr 2015 18:05:11 -0400

On Thursday, April 02, 2015 05:28:09 pm Yoav Nir wrote:
> But that aside, “the web” as represented by the HTTP/2 document made its own profile. For applications other than “the web”, UTA made their BCP document. For the IoT DICE made their profile. 
> 

HTTP/2 & 1.1 will be using the MTIs in the TLS 1.3 spec. The additional requirements on TLS in the HTTP/2 spec are explicitly restricted to TLS 1.2 use. (TLS 1.0 & 1.1 being prohibited) The only requirement on TLS 1.3+ use is mandatory usage of SNI.

Dave

---

From: James Cloos <[email-masked]>
Date: Thu, 02 Apr 2015 18:22:59 -0400

For symmetric, chacha20-poly1305 ought to be MUST, and the MUST AES
should be at (about) the same security level, ie AES256.

Even on slow hardware the speed difference between aes128 and aes256 is
not enough to make 128 mandatory and 256 optional, rather than vice-versa.

On a pi b+, openssl's implementation of 256 is about 7/8ths as fast as 128.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 3 Apr 2015 08:52:10 +0000

Hanno =?UTF-8?B?QsO2Y2s=?= <[email-masked]> writes:

>Other options: AES-CBC with EtM (Peter Gutmann just claimed here he thinks
>its less brittle than GCM) or other block modes (OCB?).

I've always liked OCB, and the removal of encumbrance for TLS implementations
finally makes it available for use there.  GCM is just too brittle, a minor
implementation flaw (as has already occurred in things like tarsnap and JCE)
leads to a complete loss of security, while the same flaw using CBC (and
presumably OCB) leads to mostly theoretical weaknesses.  GCM (or at least its
underlying primitive, CTR) is RC4 all over again, and we're already seeing
some of the same mistakes that killed RC4 use appearing in GCM deployments.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 3 Apr 2015 09:14:21 +0000

Nico Williams <[email-masked]> writes:

>Sure, that'd be nice (because different manufacturers of IoT devices will
>want to know what to implement as a common denominator).

The IoT environment doesn't work the way some people seem to think it does.
IoT devices can be divided into two classes, those that can't run TLS and
those that can.  The class "those that can't run TLS" is a lot larger than you
think, because a typical target might for example have 15% of an ARM7 TDMI and
18K RAM available, and restrictions like the fact that no operation can tie up
the CPU for more than 2ms before it's killed by the system watchdog.

So for "TLS" on these devices you've got a large class of systems that have to
run some homebrew protocol invented by an embedded systems guy who's read the
first three chapters of Applied Cryptography (this became particularly
problematic when smart meters started to become widespread and regulators
imposed requirements for certificate-based signed messaging and updates onto
CPUs like TI MSP430s, Motorola ColdFires, and ARM Cortex-Ms, some clocked as
high as 16MHz and with as much as 32kB of RAM (for everything, not just the
crypto).  The solution with smart meters was to cut corners as much as
possible in order to make things fit, skipping certificate verification,
assuming hardcoded public keys, and various other measures that are destined
to become entertaining Black Hat or Defcon presentations in the future).

For the other class, those that can run TLS, the reason for running it isn't
to talk to another device running TLS (you use your homebrew protocol for
that), it's so they can be controlled via a web interface.  For these devices
the profile is "whatever we need to implement to talk to a web browser/smart
phone/web control/AJAX/whatever".  That is the entire device profile.  Since
the underlying hardware can't handle this, you get approaches like the ones
I've talked about in the past, 1024-bit keys for everything (perfectly OK for
embedded device security, I've been waiting for the negotiated-ff-dhe draft to
be approved so I can push out one that extends it to specify 1024- and 1280-
bit parameter sets), pre-encoded cert chains memcpy()'d out into TLS streams
(the device has zero PKI functionality because there isn't room), and so on,
just whatever you can get away with and have the other side still talk to you
(I've seen some truly ingenious solutions applied to systems that have to talk
to web browsers but just can't handle the high resource requirements for TLS).

If you want to do an IoT TLS profile (what would have been called an embedded
device TLS profile before IoT became a buzzword) you need to look at how TLS
is used in the embedded world, and for what purposes.  Simply dreaming up
something and calling it an IoT profile won't work, because vendors are
already working with de facto profiles of "whatever we need to do to get
things working".

Peter.

---

From: Aaron Zauner <[email-masked]>
Date: Fri, 03 Apr 2015 12:51:53 +0200

Hi,

> some of the same mistakes that killed RC4 use appearing in GCM deployments.

I think CBC-ETM or OCB would be quite a good fit when native
instructions for AES aren't supported on a given platform. Of course
ChaCha20/Poly1305 gives us a very nice AEAD construction for these as
well. But then we're down to one algorithm for all common platforms that
don't have AESNI. I'd like to see a second MTI cipher for these devices
which, these days, are everywhere (not talking about IoT but rather
smartphones, tons of smartphones and some netbook-like computers). And
I'm not just saying this because I have a draft for AES-OCB, if we end
up with e.g. CBC-ETM or another cipher entirely that's fine as well.

IPRs on OCB:
https://datatracker.ietf.org/ipr/search/?draft=&rfc=7253&submit=rfc&holder=&patent=&group=&doctitle=&iprtitle=

IBM folks are telling me they're working on something similar as
rogaway's statement regarding TLS. Let's see with what they come up with.

Aaron

---

From: Watson Ladd <[email-masked]>
Date: Fri, 3 Apr 2015 06:55:32 -0700

> aim to have at least one left.

Is that really what happened with RC4 and the MAC construction?  Or
was it nearly a decade of ignoring widely reported weaknesses?

> In all cases recall that required-to-implement != required-to-enable.

All sites with RC4 enabled and preferred implement and offer
AES128-SHA in the handshake. The absence of alternatives in
implementations isn't what is keeping RC4 alive.

> (probably GCM) and one AEAD-by-generic-construction (e.g., using HMAC).

OCB is a better fit constrained devices. CCM requires two passes.

> I would like one non-AES cipher to be required.  ChaCha20-Poly1305 works

What does this requirement translate to in practice? It doesn't
necessarily mean that we can switch, as there is no requirement to use
the other ciphers, or even offer them. We seem to have quietly
admitted to opening up a zoo of ciphers, where every profile picks a
different one. How do these proposals actually improve security?

What we need to do is ensure that bad ciphers aren't used. The
exercise of ensuring that we have alternatives only matters if we have
an answer to the question of how migration works.

Sincerely,
Watson Ladd

---

From: Dave Garrett <[email-masked]>
Date: Fri, 3 Apr 2015 11:10:40 -0400

> OCB is a better fit constrained devices. CCM requires two passes.

So, at this point in the discussion, this is sounding like what might get closer to agreement:

o Symmetric:
        MUST AES-OCB 128 (or 256?)
        MUST ChaCha20-Poly1305
        OPTIONAL AES-GCM 128, but MUST if supporting TLS 1.2

This is essentially 2 MTI for TLS 1.3, with a required amendment to the TLS 1.2 spec to add an AEAD MTI. Without this, when falling back a version there'd be a higher likelihood of having to downgrade to CBC. (current draft has a SHOULD for using AEAD with TLS 1.2, if available)

The question is, however: is the WG willing to specify two new MTI? Not having one that's currently in widespread use might slow adoption. Then again, ChaChaPoly is getting out there from Google's pushing of it. Or, all 3 could just be MUSTs.

Dave

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 Apr 2015 08:14:40 -0700

>         OPTIONAL AES-GCM 128, but MUST if supporting TLS 1.2

I would not be in favor of this. I prefer the proposal that the chairs
originally made
based on the interim.

-Ekr

This is essentially 2 MTI for TLS 1.3, with a required amendment to the TLS
> 1.2 spec to add an AEAD MTI. Without this, when falling back a version
> there'd be a higher likelihood of having to downgrade to CBC. (current
> draft has a SHOULD for using AEAD with TLS 1.2, if available)
>
> The question is, however: is the WG willing to specify two new MTI? Not
> having one that's currently in widespread use might slow adoption. Then
> again, ChaChaPoly is getting out there from Google's pushing of it. Or, all
> 3 could just be MUSTs.
>
>
> Dave
>

---

From: Russ Housley <[email-masked]>
Date: Fri, 3 Apr 2015 14:09:02 -0400

>        MUST AES-OCB 128 (or 256?)

The patent uncertainty prevents me from supporting this approach.  I'd need to see IPR disclosures from all three patent holders before revisiting  this as a MTI algorithm.

I am not opposed to assigning a code point for AES-OCB at any key size now.

Russ

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 06 Apr 2015 16:08:50 -0400

On Fri 2015-04-03 05:14:21 -0400, Peter Gutmann wrote:
> embedded device security

While this profile may be "perfectly OK for embedded device security",
once the device is presented to the Internet and to peers like "web
browser/smart phone", there's a pretty nasty UI/UX issue: the browser
and the smartphone normally don't have any idea that they're talking to
a constrained device that doesn't warrant/deserve a high standard of
security.

Put another way: if we make our browsers willing to accept lower
security for our IoT devices, how do we get them to require higher
security for confidential messaging applications or banking transactions
or video chat?

Without a clear UI/UX story to solve this distinction for normal users,
a simple assertion that weaker crypto is "perfectly OK" for some class
of device puts all the rest of the network at risk.

   --dkg