Subject: Re: [Uta] Comment on TLS BCP for alternative algorithm

From: Kohei Kasamatsu <[email-masked]>
Date: Tue, 05 Aug 2014 18:56:14 +0900

Hi,

> I appreciate your concerns here, but I can only agree with it to some
> degree, and inclusion in this version of the BCP is probably not a good
> idea. Maybe adding a subsection on alternative algorithms in case of a
> crypto break-through (e.g. on AES) is an option, but even here I am
> skeptical.
>
> Adding equivalent alternatives in the BCP without that understanding
> would be agains the intention of the BCP, IMO.

I understood that you disagree with inclusion of alternative algorithms
in the BCP because adding equivalent alternatives in the BCP be against
the intention of the BCP.

I believe that intension of your draft is to encourage to deploy
secure algorithms that are widely implemented because of recent attacks
[I-D.sheffer-uta-tls-attacks] from the following part of
introduction and recommendations of TLS1.2 (*1) and Brainpool curves
(*2) in your draft.

--
A companion document [I-D.sheffer-uta-tls-attacks] provides
detailed information about these attacks.

Because of these attacks, those who implement and deploy TLS and DTLS
need updated guidance on how TLS can be used securely.  Note that
this document provides guidance for deployed services, as well as
software implementations.  In fact, this document calls for the
deployment of algorithms that are widely implemented but not yet
widely deployed.
--

*1 TLS1.2 is supported by 37% of sites as Ivan's data
(http://www.ietf.org/mail-archive/web/uta/current/msg00439.html)

*2 Brainpool curves are implemented in OpenSSL 1.0.2 and are not
implemented in OpenSSL 1.0.1 and is not supported by IE, Google Chrome,
and Firefox.

Furthemore, TLS-BCP shows problems of dependence on single primitive and
alternative algorithms are countermeasure against it.
I believe that the countermeasure is suitable for your draft because it
enables TLS-BCP draft to deals with vulnerability taking alternative
algorithm into consideration.

> Is it implemented in IE? Is it supported by Chrome? If the answer to one
> of these questions is No, it should not be included in the BCP. Same
> goes for Seed. I have no data here - anyone?

As Aaron says, Camellia is included to be supported by Firefox and
SEED is not included to be supported by Firefox, IE, and Chrome.

However, it is enough to recommend the deployment in your draft based on
implementations of Brainpool curves.

>> singnature:
>> * ECDSA
>>    - is based on ECDLP (the security of RSA is based on
>>      integer factring.)
>>    - is implemented in OpenSSL 1.0.2, GnuTLS 3.3.5, NSS 3.15.1 and so on.
>
> Same questions.

As Aaron says, ECDSA is widely implemented as of today.

Best,
Kohei KASAMATSU

(2014/07/30 19:35), Ralph Holz wrote:
> Hi,
> 
>> I am referring to symmetric key encryption, signature, mode of
>> operations for constructing AEAD, and MAC.
>> (as you pointed out, we already have alternatives for public key encryption)
>>
>> Do you agree with the necessity of alternative algorithms?
> 
> I appreciate your concerns here, but I can only agree with it to some
> degree, and inclusion in this version of the BCP is probably not a good
> idea. Maybe adding a subsection on alternative algorithms in case of a
> crypto break-through (e.g. on AES) is an option, but even here I am
> skeptical.
> 
> Adding equivalent alternatives in the BCP without that understanding
> would be agains the intention of the BCP, IMO.
> 
> As for the algorithms, I have some doubts:
> 
>> [Rationale]
>> symmetric key encryption:
>> * Camellia
>>    - have different design policy (Feistel Structure) from AES
>>      (SPN Structure)
>>    - is implemented in OpenSSL 1.0.2, GnuTLS 3.3.5, NSS 3.15.1 and so on.
> 
> Is it implemented in IE? Is it supported by Chrome? If the answer to one
> of these questions is No, it should not be included in the BCP. Same
> goes for Seed. I have no data here - anyone?
> 
>> singnature:
>> * ECDSA
>>    - is based on ECDLP (the security of RSA is based on
>>      integer factring.)
>>    - is implemented in OpenSSL 1.0.2, GnuTLS 3.3.5, NSS 3.15.1 and so on.
> 
> Same questions.
> 
>> mode of operations: -
> 
> [CCM]
> 
> I see no reason to include this here - support seems to be lacking.
> 
>> MAC: -
>> * There is only HMAC as alternative algorithm and
>>    And there is HMAC-SHA-3 as candidate of alternative hash function.
> 
> Same reason here.
> 
> Ralph
>

---

From: Kohei Kasamatsu <[email-masked]>
Date: Tue, 05 Aug 2014 19:06:05 +0900

Hi,

Thank you very much for your information on Camellia, SEED, and ECDSA.

> There are some security issues
> for implementers - I'm no ECC security expert so I can only refer to
> this excellent article by Prof.
> Bernstein:http://blog.cr.yp.to/20140323-ecdsa.html

I do not know a lot about cache-timing attacks, but I think that a 
setting of the paper by Naomi Benger et al. is different from TLS-BCP 
draft. (the paper: secp256k1, TLS-BCP: brainpoolp256r1, secp256r1)

What do you think about it?

Best,
Kohei KASMATSU

(2014/07/30 22:34), Aaron Zauner wrote:
> Hi *,
> Ralph Holz wrote:
> Both are not implemented by Microsoft SChannel to the best of my
> knowledge (http://technet.microsoft.com/en-us/library/dn786419.aspx) -
> i.e. Internet Explorer does not support them. CAMELLIA is no longer
> included to be supported by Firefox (it is supported by NSS though).
>
> singnature:
> * ECDSA
> ECDSA is widely implemented as of today. There are some security issues
> for implementers - I'm no ECC security expert so I can only refer to
> this excellent article by Prof.
> Bernstein:http://blog.cr.yp.to/20140323-ecdsa.html
>
>
> Aaron
>
>
>
>
> On Wed, Jul 30, 2014 at 12:35 PM, Ralph Holz <[email-masked]> wrote:
>
>> Hi,
>>
>> Ralph Holz
>> I8 - Network Architectures and Services
>> Technische Universit��t M��nchen
>> http://www.net.in.tum.de/de/mitarbeiter/holz/
>> Phone +49.89.289.18043
>> PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF
>>
>> _______________________________________________
>> Uta mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/uta
>>
>

---

From: Kohei Kasamatsu <[email-masked]>
Date: Tue, 05 Aug 2014 19:19:44 +0900

> Based on long experience in the IETF, this seems like the opposite of
> a BCP. Protocols that have had multiple mandatory-to-implement
> algorithms "in case there was a crypto failure" have led to
> interoperability failures and confusion for users.

You mean that if protocols have multiple mandatory-to-implement (MTI)
algorithms some of these MTI algorithms are not implemented and it
causes interoperability failures?

> Clearly, TLS needs to have crypto agility in case of crypto failures,
> but the current BCP does not prevent that.

Why cannot "current" BCP prevent that?

Best,
Kohei KASAMATSU

(2014/07/30 22:45), Paul Hoffman wrote:
> On Jul 24, 2014, at 3:36 PM, Kohei Kasamatsu
<[email-masked]> wrote:
>
>> I strongly believe that BCP needs to include alternative algorithms
>> - with different design policy from algorithm which your I-D recommends
>> - which are widely implemented
>> - which are internationally standardized
>>
>> Because when protocols depend on single primitive and vulnerability
>> related to the primitive is found it takes a lot of time to migrate from
>> insecure primitive to secure one.
>
> Based on long experience in the IETF, this seems like the opposite of
a BCP. Protocols that have had multiple mandatory-to-implement
algorithms "in case there was a crypto failure" have led to
interoperability failures and confusion for users. Clearly, TLS needs to
have crypto agility in case of crypto failures, but the current BCP does
not prevent that. But "alternative algorithms" has been shown to have
negative effects.
> --Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Aug 2014 07:17:22 -0700

> causes interoperability failures?

Exactly.
> Why cannot "current" BCP prevent that?

Because you cannot force developers to implement algorithms that they do not want to. You cannot force developers to implement algorithms they have barely heard of, such as those that are have good support in basically only one nation or basically only in system environment (hardware or software).

--Paul Hoffman

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 05 Aug 2014 22:38:40 +0200

Hi Kohei,

> What do you think about it?
That's true. I've mixed up these two SEC2 curves in my mind.

Aaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 06 Aug 2014 00:41:27 +0300

> ECDSA is widely implemented as oftoday.  There are some security issues
> this excellent article by Prof. Bernstein:
> http://blog.cr.yp.to/20140323-ecdsa.html

ECDSA is not mentioned in the draft (except in passing while quoting 
something else) for a good reason: ECDSA certificates barely exist. So I 
don't think ECDSA is even remotely relevant for a BCP today.

The curve discussion in the draft is about ECDH. The consensus that I am 
hearing (or heard, a few months ago) is that we want to move away from 
NIST curves because people suspect SUNS - something up NIST's sleeve. 
And Brainpool seemed to offer the only standardized alternative, even 
though it is not widely implemented. Since TLS allows to negotiate ECDH 
parameter, the draft says: "Clients and servers SHOULD prefer verifiably 
random curves (specifically Brainpool P-256, brainpoolp256r1 [RFC7027]), 
and fall back to the commonly used NIST P-256 (secp256r1) curve [RFC4492]."

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 Aug 2014 20:27:19 -0700

On Aug 5, 2014, at 2:41 PM, Yaron Sheffer <[email-masked]> wrote:

> The curve discussion in the draft is about ECDH. The consensus that I am hearing (or heard, a few months ago) is that we want to move away from NIST curves because people suspect SUNS - something up NIST's sleeve.

I have not heard that from anyone. What I have heard is that, because NIST cannot show its work, we will never know if there was something up their sleeve. That's an important difference, but still has the same results.

> And Brainpool seemed to offer the only standardized alternative, even though it is not widely implemented. Since TLS allows to negotiate ECDH parameter, the draft says: "Clients and servers SHOULD prefer verifiably random curves (specifically Brainpool P-256, brainpoolp256r1 [RFC7027]), and fall back to the commonly used NIST P-256 (secp256r1) curve [RFC4492]."

Which, of course, has nothing to do with either "Best" or "Current". The Best Current Practice continues to be the NIST curves. The next likely Best Current Practice will be one of the curves recommended by the CFRG, and Brainpool is not on that list.

--Paul Hoffman

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2014 11:00:20 +0200

> Which, of course, has nothing to do with either "Best" or "Current". The Best Current Practice continues to be the NIST curves. The next likely Best Current Practice will be one of the curves recom…

My personal opinion:

If CFRG came out with a recommendation and if TLS-wg adopted that
recommendation and if those curves were deployable using current
implementations of TLS, _then_ the UTA wg could talk about adopting
those curves as part of a BCP.

As chair:

It is ok for the BCP to be silent on some topics - there may simply
be no clear best current practice in all situations.

Better for us to rev the BCP as things become clear than to leave
the Internet community wo guidance for a long time. Perfect is the
enemy of the good.

	Cheers Leif

---

From: Yaron Sheffer <[email-masked]>
Date: Thu, 07 Aug 2014 12:32:52 +0300

Hi Leif,

We cannot be silent about what EC group to use for ECDH, because ECDH is 
kind of essential to our recommendations.

But I guess we jumped the gun by recommending Brainpool as the primary 
curve. I would like to remove this recommendation, and retain the NIST 
curve - which is all we have now. What do you think?

Thanks,
	Yaron

---

From: Leif Johansson <[email-masked]>
Date: Thu, 07 Aug 2014 11:38:11 +0200

> kind of essential to our recommendations.

Good point.

> curve - which is all we have now. What do you think?

As an individual I think thats fine. As I said: better to rev the BCP
as new information develops.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 07 Aug 2014 11:29:59 +0100

> as new information develops.

Same here. As a different individual:-)

S.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 7 Aug 2014 16:21:08 +0300

On Thu, Aug 07, 2014 at 12:32:52PM +0300, Yaron Sheffer wrote:
> curve. I would like to remove this recommendation, and retain the NIST curve
> - which is all we have now. What do you think?

The problem with Brainpool is that they use randomly generated primes,
which means terrible performance (NIST/NSA[1] at least tried to make
something that is efficient, even if in the end it turned out not to be
even near optimal).

The practical consequence is that Brainpool is not used in practice, and
since TLS only properly supports NIST/NSA and Brainpool, NIST/NSA it is.

This situation isn't expected to change before CFRG recomendations come
out (which we are apparently not going to wait for).

[1] Generating those curves is credited to NSA.

-Ilari

---

From: Kohei Kasamatsu <[email-masked]>
Date: Mon, 11 Aug 2014 17:27:24 +0900

> Exactly.

Thank you very much for your comments.
I also think that we need to deal with problem you pointed out.

Not all want crypto agility because it involves costs.
However, the reverse is also true as you agreed.

I think that we can solve the concern and recommend cipher suites for
crypto agility by specifying rational and minimal set of cipher suites
with alternative algorithms as "optional"

It prevents developers who need crypto agility from preparing insecure
algorithms.

> Because you cannot force developers to implement algorithms that they
> do not want to. You cannot force developers to implement algorithms
> they have barely heard of, such as those that are have good support
> in basically only one nation or basically only in system environment >
(hardware or software).

I proposed candidates for alternative algorithms which require criteria
including wide implementations and public documents in standardizing
organizations and estimations by trusted organizations.

So I believe that it is not fact that developers do not want to
implement these candidates and have barely heard of them.

-- 
Kohei KASAMATSU

NTT Software Corporation
TEL: +81 45 212 7908 FAX: +81 45 212 9800
E-mail: [email-masked]

---

From: Kohei Kasamatsu <[email-masked]>
Date: Mon, 11 Aug 2014 17:32:11 +0900

Hi Aaron,

> That's true. I've mixed up these two SEC2 curves in my mind.

A part of my claim may be misunderstood as Yaron pointed out.
TLS-BCP does not recommend ECDSA.

However, I think that it does not have an impact on your agreement
because ECDSA based on the same as curves of ECDH is used in TLS and a
lot of TLS protocols use secp256r1 (, secp384r1, and secp521r1)
as far as I checked it.

Best,
Kohei KASAMATSU

---

From: Yaron Sheffer <[email-masked]>
Date: Mon, 11 Aug 2014 11:44:53 +0300

Hi Kohei,

Personally I support the idea of alternative (or "standby") ciphers, see 
http://tools.ietf.org/html/draft-mcgrew-standby-cipher-00. However there 
was very little interest in this idea when we brought it up at CFRG.

IMHO for inclusion in the BCP there should be wide consensus about both 
the need for standby ciphers (and there is none, as far as I can tell) 
as well as the individual algorithms.

Thanks,
	Yaron

---

From: Leif Johansson <[email-masked]>
Date: Mon, 11 Aug 2014 11:33:45 +0200

> as well as the individual algorithms.

I think that is a fair assessment. Our focus now should be on getting a
first version of the BCP out as soon as possible.

	Cheers Leif

---

From: Kohei Kasamatsu <[email-masked]>
Date: Thu, 28 Aug 2014 17:37:45 +0900

Hi Yaron and Leif,

I also need a consensus about adding standby ciphers into TLS-BCP.
And I understood that UTA WG focuses on getting a first version of the
BCP out as soon as possible.

In first, I want to point out it seems that very little interest in the
idea of standby cipher that you pointed out is not fact.
I heard from David that there are some interests in idea of standby ciphers.

My concern is that when vulnerability related to the primitive is found
it takes a lot of time to migrate from insecure primitive to secure one.
In fact, it is seemed to me that it takes a lot of time to migrate to
TLS1.2. (My proposal that TLS-BCP recommends standby ciphers is one of
the solutions for a delay of migration.)

What do you think about my concern?

For example, shall we consider the procedure for review of algorithms in
TLS-BCP and update of TLS-BCP in order to deal with the following events?

1. Operations of new algorithms in TLS implementations are so increasing
that we cannot ignore it.

2. Vulnerability of TLS is found.

Best,
Kohei KASAMATSU

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 28 Aug 2014 11:27:13 +0100

Hiya,

Having had this discussion a few times over the last
couple of years my take on it is:

- there is some but not huge interest a backup cipher
  for AES and the interest-level varies by protocol
  as do the set of possible backups

- we are very unlikely to get an easy consensus on which
  to pick, or how to pick (has been tried in both SAAG
  and CFRG without success), as a generic backup

- picking a cipher is not a UTA thing, and not the same
  as picking a TLS ciphersuite, which can be a UTA thing

- while Camellia ciphersuites exist, chacha20 ciphersuites
  seem like they are also getting traction as an
  alternative to AES when one doesn't have AES h/w, but
  its too soon to tell maybe - if that happened, then there
  is also a reason to support chacha20 in addition to it
  being a backup to AES. And 2 reasons are way better
  than one here.

I conclude that UTA should not be in the business of
trying to decide which cipher might be a good backup
for AES.

And since TLS ciphersuites are in flux, with RC4 on
the way out and (apparently) chacha20 on the rise,
this isn't the right time for UTA to pick another
ciphersuite as a backup in case of problems with AES.

Cheers,
S.

---

From: Leif Johansson <[email-masked]>
Date: Fri, 29 Aug 2014 08:00:58 +0200

> ciphersuite as a backup in case of problems with AES.

Thank you Stephen. I agree with your observations and this last point in
particular makes me believe this is out of scope for the BCP draft.

Since there are few (if any) voices in support of backup suites in UTA
the WG seem to agree with you too.

	Cheers Leif