Re: [TLS] draft-sheffer-tls-bcp: DH recommendations

[Yaron Sheffer <[e-mail]>]

Hi Peter,

Thanks for the clarification. Two questions:

- Does any of this brittleness still apply when talking about ECDH (as 
opposed to ECDSA), with fixed parameters?

- Further supporting the brittleness argument... We recently specified 
recipient tests in IKEv2, that apply (and are actually 
security-critical) when either side reuses its DH private key [1]. The 
recipient needs to test that the received point is actually on the 
relevant curve. Are these mandated for ECDHE in TLS? I would have 
expected to see this requirement in [2] (reuse of DH keys is allowed in 
this RFC), but it ain't.

Thanks,
	Yaron

[1] http://tools.ietf.org/html/rfc6989#section-2.3
[2] http://tools.ietf.org/html/rfc4492#section-5.4

On 09/21/2013 11:42 AM, Peter Gutmann wrote:
> Yaron Sheffer <[e-mail]> writes:
>
>> I think we've been through all these arguments (on both sides of the issue)
>> over the last week, with the exception of "ECC brittleness". Can you please
>> clarify what you mean by that?
>
> So with RSA-authenticated DH all you need to do is use a constant-time modexp
> on the server when you sign and pre-encode the PKCS #1 expected result and use
> a constant-time memcmp() on the client when you verify and you're OK.  If you
> did that ten years ago then you're safe against pretty much everything that's
> come along since then.
>
> With ECDLP-based algorithms in contrast there's a whole range of issues you
> need to take into account, the worst of which is the distressing propensity of
> the DLP algorithms to leak the private key if you get even the tiniest detail
> wrong.  Not only do you have to get all of these finicky details exactly
> right, but every now and then someone points out a new issue that you then
> need to retroactively patch into your existing code base.  For example if you
> used the recommended (until not too long ago) way to generate your k for
> (EC)DSA then you'd leak a tiny bit of your private key on each signature
> (again, that nasty propensity of DLP algorithms to leak the private key).
> That's what I meant by ECC, and DLP in general, brittleness.
>
> Peter.
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>