[TLS] Resolving the Ed448 context issue in RFC4492bis

Yoav Nir <ynir.ietf@gmail.com> Wed, 16 November 2016 01:49 UTC

From: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
Message-Id: <B3CDC6C9-E4C5-4EE5-989B-55FACA3F5C3A@gmail.com>
Date: Wed, 16 Nov 2016 10:49:47 +0900
To: "<tls@ietf.org>" <tls@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk>
Subject: [TLS] Resolving the Ed448 context issue in RFC4492bis
Precedence: list

Hi, all

As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new parameter to the signature function: a context string. Setting this string to a different value for each application (where application could be "PKIX", "TLS", "IKE") leads to different results and thus a signature made in one context does not validate in another context. This reduces the attack surface for attacks involving signing oracles.

The CFRG draft suggests that "contexts SHOULD NOT be used opportunistically, as that kind of use is very error-prone.  If contexts are used, one SHOULD require all signature schemes available for use in that purpose support contexts". As I don't think this WG is ready to deprecate RSA, DSA, and ECDSA in one fell swoop, I think we should not use contexts. 

So I suggest to add the following sentence at the end of the fifth paragraph section 5.10 ("All EdDSA computations MUST be performed...") of the rfc4492bis draft:

   The context parameter for Ed448 MUST be set to the empty string.


Comments?

Yoav

[TLS] Resolving the Ed448 context issue in RFC449… Yoav Nir