Subject: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2016 10:49:46 +0900

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 paragraph at the end of section 2 of the eddsa draft:

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

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Wed, 16 Nov 2016 12:41:19 +0900

> On Nov 16, 2016, at 10:49, Yoav Nir <[email-masked]> wrote:
> 

I agree. Context seems useful for generic crypto but not for something that is already strongly bound by an IETF transport protocol.

Additionally, we have a similar problem too when allowing the same key in IKEv1 and IKEv2 where the key has different security properties.

Paul

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 16 Nov 2016 13:35:09 +0900

> Additionally, we have a similar problem too when allowing the same key in IKEv1 and IKEv2 where the key has different security properties.

I don't think there's any cost to having a non-empty context string, 
e.g. "IKEv2", and there's potentially value. TLS cross-protocol attacks 
show that signatures can be abused even when embedded in a transport 
protocol.

The fact that we have the same problem elsewhere is no reason to 
propagate it further.

Thanks,
	Yaron

---

From: Daniel Migault <[email-masked]>
Date: Tue, 15 Nov 2016 23:47:35 -0500

i would like the same policy - context or no context - applied to both
EdDSA algo. ctx prevents cross protocol attacks but may encourage bad
practice.

Yours,
Daniel

On Nov 16, 2016 1:35 PM, "Yaron Sheffer" <[email-masked]> wrote:

On 16/11/16 12:41, Paul Wouters wrote:

> I agree. Context seems useful for generic crypto but not for something
> that is already strongly bound by an IETF transport protocol.
>
> Additionally, we have a similar problem too when allowing the same key in
> IKEv1 and IKEv2 where the key has different security properties.
>
> Paul
>

I don't think there's any cost to having a non-empty context string, e.g.
"IKEv2", and there's potentially value. TLS cross-protocol attacks show
that signatures can be abused even when embedded in a transport protocol.

The fact that we have the same problem elsewhere is no reason to propagate
it further.

Thanks,
        Yaron

_______________________________________________
IPsec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ipsec

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 16 Nov 2016 13:58:54 +0900

If you mean the same policy for IPsec and TLS, I fully agree.

Context prevents cross-protocol attacks, and I wouldn't worry about 
"encouraging bad behavior". Users will behave badly whether we encourage 
them or not :-)

Thanks,
	Yaron

On 16/11/16 13:47, Daniel Migault wrote:
> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>
>
>             On Nov 16, 2016, at 10:49, Yoav Nir <[email-masked]
>             <mailto:[email-masked]>> wrote:
>
>         I agree. Context seems useful for generic crypto but not for
>         something that is already strongly bound by an IETF transport
>         protocol.
>
>         Additionally, we have a similar problem too when allowing the
>         same key in IKEv1 and IKEv2 where the key has different security
>         properties.
>
>         Paul
>
>
>     e.g. "IKEv2", and there's potentially value. TLS cross-protocol
>     attacks show that signatures can be abused even when embedded in a
>     transport protocol.
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/ipsec>
>
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2016 15:32:25 +0900

No, I think he means Ed448 and Ed25519. 

Adding context to Ed25519 (so using Ed25519ctx) requires using a different function than the one available in several implementations such as libsodium.

If we choose the no context option it doesn’t matter: Ed25519ctx with empty context == Ed25519ctx

Yoav

> On 16 Nov 2016, at 13:58, Yaron Sheffer <[email-masked]> wrote:
> 
> Context prevents cross-protocol attacks, and I wouldn't worry about "encouraging bad behavior". Users will behave badly whether we encourage them or not :-)
> 
> Thanks,
> 	Yaron
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 16 Nov 2016 15:33:46 +0900

But yes, I agree that IPsec, TLS and Curdle should come to the same conclusion either way.

And I think that in light of existing deployment, Ed25519ctx *with* context is a very hard sell.

Yoav

> On 16 Nov 2016, at 15:32, Yoav Nir <[email-masked]> wrote:
>

---

From: Daniel Migault <[email-masked]>
Date: Wed, 16 Nov 2016 01:56:17 -0500

Given the discussions on curdle. the trend is to use an empty context with
a clear security recommendation of using dedicated keys for each usage.
Yours
Daniel

On Nov 16, 2016 3:34 PM, "Yoav Nir" <[email-masked]> wrote:

But yes, I agree that IPsec, TLS and Curdle should come to the same
conclusion either way.

And I think that in light of existing deployment, Ed25519ctx *with* context
is a very hard sell.

Yoav

> Adding context to Ed25519 (so using Ed25519ctx) requires using a
different function than the one available in several implementations such
as libsodium.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 16 Nov 2016 17:01:43 +0900

Once again, we are moving the responsibility over security best 
practices from vendors into users. We should know better by now.

Thanks,
	Yaron

On 16/11/16 15:56, Daniel Migault wrote:
> Given the discussions on curdle. the trend is to use an empty context
> with a clear security recommendation of using dedicated keys for each usage.
> Yours
> Daniel
>
>
> On Nov 16, 2016 3:34 PM, "Yoav Nir" <[email-masked]
>     > On 16 Nov 2016, at 15:32, Yoav Nir <[email-masked]
>     different function than the one available in several implementations
>     such as libsodium.
>     >
>     >> On 16 Nov 2016, at 13:58, Yaron Sheffer <[email-masked]
>     >> Context prevents cross-protocol attacks, and I wouldn't worry
>     about "encouraging bad behavior". Users will behave badly whether we
>     encourage them or not :-)
>     >>
>     >> Thanks,
>     >>      Yaron
>     >>
>     <mailto:[email-masked]>
>     >>> <mailto:[email-masked] <mailto:[email-masked]>>>
>     wrote:
>     >>>
>     >>>
>     >>>
>     >>>           On Nov 16, 2016, at 10:49, Yoav Nir
>     <[email-masked] <mailto:[email-masked]>
>     >>>           <mailto:[email-masked]
>     <mailto:[email-masked]>>> wrote:
>     >>>
>     >>>   [email-masked] <mailto:[email-masked]> <mailto:[email-masked]
>     <mailto:[email-masked]>>
>     >>>   <https://www.ietf.org/mailman/listinfo/ipsec
>     <https://www.ietf.org/mailman/listinfo/ipsec>>
>     >>>
>     >>>
>     >
>

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Nov 2016 10:36:56 +0900

> practices from vendors into users. We should know better by now.

yeah, I still don't really understand this.
Why can't we put a security context into a new algorithm.

Yoav explained to me offline that the argument against doing is, is that
users might think they are safe to re-use keys, and might start doing that.
But it isn't safe to do that with old RSA, ECDSA, DSA, etc. methods, and they
might be surprised.  okay, I follow this logic... but... either they listen,
or they don't.  

Isn't this "solved" by putting the security context in, and simply not
talking about it?    We still tell users not to share keys, which is what we
plan to do anyway.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-