Subject: [Cfrg] Help with the use of contexts

From: Sean Turner <[email-masked]>
Date: Wed, 4 Jan 2017 16:55:44 -0500

Hi CFRG,

The TLS WG is nearing the end of our journey moving EC-based algorithms for TLS 1.2 (and earlier) from Informational to Standards track [0].  While we were doing that we also added in 25519 and x448 as well as EdDSA.

I’d like to get some input from the CFRG on the use of contexts; the "context label" is a way to provide domain separation between signatures made in different contexts, avoiding cross-protocol attacks.  s10.3 of draft-irtf-cfrg-eddsa includes the following:

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.

This is great advice for new protocols because it’s easy to make all the schemes the same, but for existing protocols like TLS where there’s zero chance of obsoleting the existing signature schemes and defining new signature schemes with contexts it makes you wonder what “opportunistically” means. I.e., would setting a context parameter for Ed448 and no other already defined signature scheme be considered opportunistic?

spt
(as document Shepherd for draft-ietf-tls-rfc4492bis)

[0] https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 16 Jan 2017 18:37:17 +0000

Dear CFRG,

Please chime in asap if you have a view on the issue of signature contexts
in TLS 1.3, as described by Sean below. Otherwise, chairs will make a
possibly ill-informed decision...

Regards

Kenny

On 04/01/2017 21:55, "Cfrg on behalf of Sean Turner"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi CFRG,
>
>The TLS WG is nearing the end of our journey moving EC-based algorithms
>for TLS 1.2 (and earlier) from Informational to Standards track [0].
>While we were doing that we also added in 25519 and x448 as well as EdDSA.
>
>I’d like to get some input from the CFRG on the use of contexts; the
>"context label" is a way to provide domain separation between signatures
>made in different contexts, avoiding cross-protocol attacks.  s10.3 of
>draft-irtf-cfrg-eddsa includes the following:
>
>This is great advice for new protocols because it’s easy to make all the
>schemes the same, but for existing protocols like TLS where there’s zero
>chance of obsoleting the existing signature schemes and defining new
>signature schemes with contexts it makes you wonder what
>“opportunistically” means. I.e., would setting a context parameter for
>Ed448 and no other already defined signature scheme be considered
>opportunistic?
>
>spt
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>https://www.irtf.org/mailman/listinfo/cfrg

---

From: Adam Langley <[email-masked]>
Date: Mon, 16 Jan 2017 10:45:34 -0800

On Wed, Jan 4, 2017 at 1:55 PM, Sean Turner <[email-masked]> wrote:

> for TLS 1.2 (and earlier) from Informational to Standards track [0].  While
> we were doing that we also added in 25519 and x448 as well as EdDSA.
>

Domain separation for signed values is important and TLS already defines
context strings for signature operations:
https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.2

The way that this is constructed (due to me) is generic for any signature
scheme. (Basically just have the context string be NUL-terminated at the
beginning of the signed message.)

So for TLS I believe that the issue is already taken care of. It would also
probably just add pain for implementers if the context string were to be
duplicated as an input to the signature scheme where signature schemes
support it.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: "D. J. Bernstein" <[email-masked]>
Date: 16 Jan 2017 20:09:48 -0000

Adam Langley writes:
> The way that this is constructed (due to me) is generic for any
> signature scheme. (Basically just have the context string be
> NUL-terminated at the beginning of the signed message.)

In other words, there's still a simple sign-a-message layer that uses
the standard signature API, that works with all signature systems, and
that minimizes costs for implementors and auditors. On top of this
there's a universal

   def sign_a_context_and_data(c,d):
     if '\0' in c: raise Exception('NUL not allowed in contexts')
     return sign(c + '\0' + d)

layer used by the protocol (and by any other protocols that want it).
Everyone can see how this works from a spec perspective and from a
software-engineering perspective.

For comparison, trying to modify the interface and specification of
every sign() function creates a transition nightmare, with nobody able
to answer basic questions about how this approach is actually supposed
to work. What's the advantage supposed to be?

I would really like to see this unnecessary complexity eliminated from
CFRG's signature specifications. Please see

   https://www.ietf.org/mail-archive/web/cfrg/current/msg08167.html

for further comments.

---Dan

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 Jan 2017 11:48:38 +0000

On 16/01/17 20:09, D. J. Bernstein wrote:
> CFRG's signature specifications.

I'm relatively neutral on the use or non-use of contexts,
but lean more towards Dan's position that the API changes
involved mean that practically, it's better to not demand
contexts.

However, I really do wish that CFRG specs would not offer
both choices - that will simply lead to repeating this
discussion each time an IETF protocol wants to use the CFRG
spec. And of course, different decisions will be made over
time, leading to slightly more mess than would otherwise
exist. That's not a showstopper thing, but life will be
better if the choice is not offered.

So, I'd support eliminating contexts from CFRG specs and
saying something like "if you want that, and it's not a
bad idea for avoiding cross-protocol attacks, then do it
at a layer above the crypto API."

Cheers,
S.

PS: random idea - I wonder if analysis of wireshark
dissector source code, or some application calling
such code, might be a fine way to spot potential
cross-protocol attacks - anyone know if that's been
tried?

---

From: Watson Ladd <[email-masked]>
Date: Tue, 17 Jan 2017 07:06:45 -0800

On Jan 17, 2017 3:48 AM, "Stephen Farrell" <[email-masked]>
wrote:

Cheers,
S.

What we want is to determine if the intersection of two badly specified
possibly context sensitive languages is empty. This is tricky. If protocols
stuck to regular languages it would be decideable.

---

From: Yoav Nir <[email-masked]>
Date: Tue, 17 Jan 2017 17:56:06 +0200

> On 17 Jan 2017, at 13:48, Stephen Farrell <[email-masked]> wrote:
> 
> 
> 

Me too.

> time,

Not over time. In the next few months the IESG is going to get documents about EdDSA signatures from TLS, IPsecME and curdle for signatures in TLS, IKE, and PKIX respectively.  If the decision is not the same in all of them, I think (hope) that the IESG would ask why.

> leading to slightly more mess than would otherwise

---

From: Dan Brown <[email-masked]>
Date: Tue, 17 Jan 2017 17:24:26 +0000

I agree with Dan Bernstein's suggestion and reasoning below against CFRG's currently contextualization of signature schemes, though I would also understand if CFRG does not want to reverse its decisions.

Further points:

Protocol designers should be responsible to enforce uniqueness of protocol messages (within and between honest protocols), not just for digital signatures but for all forms of authentication.  How much is this to ask? Isn't that kind of reliability their bread-and-butter?  If there hadn't been non-uniqueness, then cross-protocol attacks would have failed, right?

Adding a context to signatures is a complexity that is (1) not guaranteed to help (no formal security definition, no security proof? And no, I do not volunteer), (2) potentially collides with non-contextualized signatures (must signers now also track whether each non-context signature corresponds to some contextual signature?), (3) blames crypto for too much ;)

-----Original Message-----
From: Cfrg [mailto:[email-masked]] On Behalf Of D. J. Bernstein
Sent: Monday, January 16, 2017 3:10 PM
To: [email-masked]
Subject: Re: [Cfrg] Help with the use of contexts

> NUL-terminated at the beginning of the signed message.)

In other words, there's still a simple sign-a-message layer that uses the standard signature API, that works with all signature systems, and that minimizes costs for implementors and auditors. On top of this there's a universal

layer used by the protocol (and by any other protocols that want it).
Everyone can see how this works from a spec perspective and from a software-engineering perspective.

For comparison, trying to modify the interface and specification of every sign() function creates a transition nightmare, with nobody able to answer basic questions about how this approach is actually supposed to work. What's the advantage supposed to be?

I would really like to see this unnecessary complexity eliminated from CFRG's signature specifications. Please see

for further comments.

---Dan

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jan 2017 09:02:26 +0200

> Not over time. In the next few months the IESG is going to get documents about EdDSA signatures from TLS, IPsecME and curdle for signatures in TLS, IKE, and PKIX respectively.  If the decision is n…

So now that RFC 8032 is out and does include both choices, what is our advice to TLS, IPsecME and Curdle?  Contexts or no?

Yoav

---

From: Watson Ladd <[email-masked]>
Date: Sun, 29 Jan 2017 14:33:39 -0800

> So now that RFC 8032 is out and does include both choices, what is our advice to TLS, IPsecME and Curdle?  Contexts or no?

No contexts. Why did we ever include them?

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 30 Jan 2017 01:24:06 +0200

> On 30 Jan 2017, at 0:33, Watson Ladd <[email-masked]> wrote:
> 

Seemed like a good idea at the time. The thread begins here:

https://mailarchive.ietf.org/arch/msg/cfrg/GOPQ6lgJcfrXboexQmgNk_ZIZW8 <https://mailarchive.ietf.org/arch/msg/cfrg/GOPQ6lgJcfrXboexQmgNk_ZIZW8>

Regardless, ISTM that almost nobody is advocating for using contexts now for Ed448 in any of the above applications, or for using Ed25519ctx in there. 

Yoav

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 29 Jan 2017 23:37:34 +0000

On 29/01/17 23:24, Yoav Nir wrote:
> Regardless, ISTM that almost nobody is advocating for using contexts
> now for Ed448 in any of the above applications, or for using
> Ed25519ctx in there.

If cfrg decided to revisit the decision and eliminate contexts,
I don't think anyone would really suffer. (And any sufferer
can always write an RFC too if that's really needed.)

Cheers,
S.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Mon, 30 Jan 2017 11:40:59 +0000

Dear CFRG,

Thanks to those who already expressed their views on this. We should close
this one out in the next few days. The current rough consensus seems to
lean towards "no to contexts in this instance". (The wider question of
whether contexts are a good idea or not is, formally, out of scope here,
but I don't think I can expect y'all to resist discussing it!)

So: does anyone else want to offer an opinion on the question of contexts?
The original request for input from Sean Turner can be found below.

Regards,

Kenny

----

Hi CFRG,

spt