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 protected]> wrote: > > 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 protected]> wrote: >> >> 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: >>> 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 protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> >>> On 16/11/16 12:41, Paul Wouters wrote: >>> >>> >>> >>> On Nov 16, 2016, at 10:49, Yoav Nir <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> 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. >>> >>> >>> 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 protected] <mailto:[email protected]> >>> https://www.ietf.org/mailman/listinfo/ipsec >>> <https://www.ietf.org/mailman/listinfo/ipsec> >>> >>> > _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
