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

[Michael Richardson]

Yaron Sheffer  wrote:
> Once again, we are moving the responsibility over security best
> 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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

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

[Yaron Sheffer]

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" mailto:ynir.i...@gmail.com>> 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 mailto:ynir.i...@gmail.com>> 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 mailto:yaronf.i...@gmail.com>> 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" mailto:yaronf.i...@gmail.com>
>>> >>
wrote:
>>>
>>>
>>>
>>>   On 16/11/16 12:41, Paul Wouters wrote:
>>>
>>>
>>>
>>>   On Nov 16, 2016, at 10:49, Yoav Nir
mailto:ynir.i...@gmail.com>
>>>   >> 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
>>>   IPsec@ietf.org  >
>>>   https://www.ietf.org/mailman/listinfo/ipsec

>>>   >
>>>
>>>
>

___
IPsec mailing list
IPsec@ietf.org 
https://www.ietf.org/mailman/listinfo/ipsec





___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec