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

From: Kohei Kasamatsu <[email-masked]>
Date: Fri, 25 Jul 2014 07:36:47 +0900

Hi Uta folks,

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.

In fact, as TLS-BCP draft says several stronger cipher suites are
available only with TLS 1.2 and it will take a lot of time for
migration. Alternative algorithms are countermeasure against it.

Furthermore, it is better that TLS-BCP draft deals with vulnerability
taking alternative algorithm into consideration
when vulnerability is found.
So the concept of alternative algorithm is suitable for TLS-BCP draft.

Welcome to your comments and suggestions.

Best,
Kohei KASAMATSU

---

From: Ralph Holz <[email-masked]>
Date: Sat, 26 Jul 2014 11:53:22 +0200

Hi,

> - which are internationally standardized

I assume you are referring to symmetric crypto (we already have
alternatives for pubkey crypto).

Which ones do you have in mind that would fulfill these criteria?

Ralph

-- 
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

---

From: Kohei Kasamatsu <[email-masked]>
Date: Tue, 29 Jul 2014 13:27:21 +0900

Hi Ralph,

> alternatives for pubkey crypto).

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?

> Which ones do you have in mind that would fulfill these criteria?

I want to make these viewpoints concrete and "satisfying 128 bit
security" which your draft says and "patent free" into these criteria.

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 in OSSs and are easily used
- with public document in standardizing organization and estimation
  by trusted organization
- with 128 bit security
- which is patent free

I believe that the following primitives fulfill above criteria.

symmetric key encryption: Camellia, Seed
signature: ECDSA
mode of operations: -
MAC: -

Do you agree with the above criteria and candidates of alternative
algorithms?

[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 standardized in RFC5932, RFC6367, ISO/IEC18033, and ITU-T
    and is recommended in NESSIE and CRYPTREC)
  - with 128 bit security
  - which is patent free

* Seed
  - have different design policy (Feistel Structure) from AES
    (SPN Structure)
  - is implemented in OpenSSL 1.0.2 and NSS 3.15.1 and so on.
  - is standardized in RFC4162 and ISO/IEC18033
    and is recommended in NESSIE and KICS)
  - with 128 bit security
  - which is patent free

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.
  - is standardized in RFC6460 and NIST.
    and is recommended in NESSIE and CRYPTREC
  - with 128 bit security
  - which is patent free

mode of operations: -

* I think that CCM is candidate of alternative modes of operation and
  is widely implemented in embedded device.
  Howeve I think that CCM is not widely implemented in general use.
  For example, CCM is implemented in PolarSSL 1.3.8 and CyaSSL 3.1.0.
  On the other hand, CCM is not implemented in OpenSSL 1.0.2,
  GnuTLS 3.3.5, and NSS 3.15.1 at least.
  (CCM is implemented in crypto layer of OpenSSL 1.0.2 )
  So I think that there is currently no suitable primitive for
  alternative modes of operation. (I assume that the scope of TLS-BCP
  does not include embbeded device.)

MAC: -
* There is only HMAC as alternative algorithm and
  And there is HMAC-SHA-3 as candidate of alternative hash function.

  However, FIPS202 (SHA-3) call for public comments before August 26,
  2014. Hence, there is currently no suitable primitive for
  alternative MAC.

Best,
Kohei KASAMATSU

---

From: Ralph Holz <[email-masked]>
Date: Wed, 30 Jul 2014 12:35:06 +0200

Hi,

> 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.

>   - 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?

>   - 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.

>   And there is HMAC-SHA-3 as candidate of alternative hash function.

Same reason here.

Ralph

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 30 Jul 2014 15:34:09 +0200

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

Same questions.

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:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Jul 2014 06:45:42 -0700

> 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: Leif Johansson <[email-masked]>
Date: Thu, 31 Jul 2014 18:22:56 +0200

> 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 inte…

I agree. The purpose of a BCP is to document the best possible current
behaviour, not create a wish-list.

When at some time in the future alternative algorithms have been shown
to be better and deployable, the BCP will be revised to reflect that.

	Cheers Leif

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 31 Jul 2014 12:52:43 -0400

> When at some time in the future alternative algorithms have been shown to
> be better and deployable, the BCP will be revised to reflect that.

+1

--  
Principal Security Engineer
Akamai Technologies, Cambridge MA
IM: [email-masked] Twitter: RichSalz