Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

[Stephen Farrell]

On 13/10/16 13:27, Yoav Nir wrote:
> Hi, Stephen
> 
>> 
>> - Wouldn't it be good to encourage minimising re-use of public
>> values for multiple key exchanges? As-is, the text sort-of
>> encourages use for "many key exchanges" in section 4.
> 
> I don’t think so. 

Fair enough, though when I said "minimise" I didn't mean
"never re-use." But all you say below is correct, so not
that big a deal, but I do think it'd be better to explicitly
encourage implementers to roll their private values as
often as makes sense in their situation.

S.

> Re-use reduces the computation cost of an IKE
> Responder (or TLS server) without sacrificing security.  There was
> some discussion of this in CFRG, but I see that it didn’t make it
> into RFC 7748, so all I can find is some StackExchange question
> ([1]).
> 
> It does make the static keypair valuable. It is definitely not a good
> idea to store the private key on-disk and keep it forever, but
> generating a new key once in a while and discarding the old key is
> usually a good compromise there.
> 
> Anyway key-pair reuse is established practice. Using constant-time
> implementations is essential to making this practice safe, and the
> Security Considerations sections says just that.
> 
> Yoav
> 
> [1]
> http://crypto.stackexchange.com/questions/11012/reuse-of-a-dh-ecdh-public-key
>



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

[Stephen Farrell]

Thanks Tero and sorry for forgetting:-)

Cheers,
S.

On 13/10/16 13:04, Tero Kivinen wrote:
> Stephen Farrell writes:
>> Stephen Farrell has entered the following ballot position for
>> draft-ietf-ipsecme-safecurves-05: Yes
>>
>> --
>> COMMENT:
>> --
>> - Sorry if I'm forgetting how we handle this in IPsec,
>> but is an implementation of this RFC expected to support
>> both curves? I think it'd be ok to say that 25519 is a
>> MUST for folks doing, this but that 448 is optional.  I'm
>> also fine if we mean that implementing this means you
>> have to support both btw but you don't say (here) that
>> that's the case.
> 
> In IPsec we do not specify any requirement levels in the actual
> algorithm documents. The algorithm documents just allocate the IANA
> numbers and specify how they algorithms are used.
> 
> Then we have separate documents (new versions soon to be in front of
> IESG) specifying the actual mandatory to implement algorithms.
> 
> Whether some implementation supports this new RFC is something that
> does not have well define answer, as people could say they implement
> this RFC if they support one or other, or both curves. Usually people
> are just saying they support algorithm RFC if they support one
> algorithm from there. I.e., vendors usually say they support RFC2451,
> even if they only support 3DES from there, and might not support
> CAST-128, RC5, IDEA and Blowfish.
> 
> Anyways the mandatory to implement ciphers are specified in the
> rfc4307bis [1] and rfc7321bis [2].
> 
> These curves are not mentioned there, so they are still going to be
> MAY. When we are going to update 4307bis again then we are most likely
> going to make them SHOULD+ or even MUST (if there is enough
> implementations actually implementing them at that point).
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/
> [2] https://datatracker.ietf.org/doc/draft-mglt-ipsecme-rfc7321bis/
> 



smime.p7s
Description: S/MIME Cryptographic Signature
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec