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
