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 protected]
<mailto:[email protected]>> 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
> On 16 Nov 2016, at 15:32, Yoav Nir <[email protected]
<mailto:[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]
<mailto:[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]>
>>> <mailto:[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]>
>>> <mailto:[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]> <mailto:[email protected]
<mailto:[email protected]>>
>>> https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>
>>> <https://www.ietf.org/mailman/listinfo/ipsec
<https://www.ietf.org/mailman/listinfo/ipsec>>
>>>
>>>
>
_______________________________________________
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
