Re: [TLS] Another IRINA bug in TLS

[Watson Ladd <[e-mail]>]

On Thu, May 21, 2015 at 12:51 PM, Dan Brown <[e-mail]> wrote:
> In the Imperfect Forward Secrecy paper, Section 5 Recommendations, the
> medium term recommendation to avoid fixed-prime DHE groups seems to conflict
> with the current direction TLS is taking towards named only groups.

Is that *really* what the recommendation says? It's true that using
the same group repeatedly enables an attacker who does an L(1/3)
calculation to quickly compute all discrete logarithms together. But
instead of making countermeasures to this, it's far easier to ensure
that the price this precomputation is large, by using larger groups.

>
> I gather that TLS is still planning keep DHE around (as a supplement to
> ECDHE).   So, should TLS stick to its current approach of using named DHE
> groups, just with larger key sizes, or should it follow the recommendation
> above of allowing custom DHE groups?
>
> Maybe this is question for CFRG, since it can pertain to multiple WGs?
>
> If TLS opts for the latter, to bring back custom DHE parameters per the
> recommendation above, then it seems that TLS should expand on the simple TLS
> 1.2 ServerDHParams, by including the order of the generator, and probably
> including some kind of seed to a PRF (making them similar to the old custom
> ECDHE parameters).
>
> Note that ECDHE and DHE largely share the issue of fixed parameters are
> affected by a pre-computation across multiple keys.
>
> Choosing a larger key size is the most efficient and simple remedy against
> these pre-computations.

Exactly. No need to proceed further.

>
> Allowing custom groups provides a second defense against the such
> pre-computation, but supporting custom groups creates other problems.  Peers
> need to verify the custom groups, and the groups need to be generated.  The
> computation and communication spent on verifying custom groups could perhaps
> be better spent on using larger fixed groups.

You've just explained why I'm against it, better than I could. So what
actually is the reason you support it?

>
> My preference is to recommend larger, vetted, fixed groups (e.g. at least
> 2048-bit DH and 256-ish-bit ECDHE) just as TLS and CFRG are currently doing,
> but to still keep custom groups (of similar size) as an option, perhaps to
> be added later after some further discussion about the best way to specify
> custom groups.

Why do custom groups help? We've seen how they can hurt, by
complicating implementations, making possible cross-protocol attacks,
and other kinds of nastiness. You're asking that we adopt them so that
an attacker who does a massive calculation gets only one useful
result, instead of having to repeat a calculation they already did a
few times. How many months of extra time does this get us?

>
> I understand that TLS currently has the means to support an escape valve for
> custom groups, but it leaves the syntax entirely up to the peers to decide
> upon. I think a more specific support for custom groups might be a more
> useful escape valve, at least in the medium term.
>
>
>> -----Original Message-----
>> From: TLS [mailto:[e-mail]] On Behalf Of Santiago Zanella-
>> Beguelin
>> Sent: Thursday, May 21, 2015 10:53 AM
>> To: Nikos Mavrogiannopoulos; Florian Weimer
>> Cc: [e-mail]
>> Subject: Re: [TLS] Another IRINA bug in TLS
>>
>> Regarding validation of DHE parameters and how reasonable it is in
> practice, I
>> wanted to make some publicity for miTLS (http://www.mitls.org/).
>>
>> A miTLS client maintains a table of known trusted parameters, including
> the
>> subgroup order for parameters with non-safe primes. When receiving
>> unknown parameters from a server, it tests the primality of p and (p-1)/2
> to
>> check if p is a safe prime (and caches a positive result in the table). If
> the
>> modulus is prime but not safe, miTLS checks if it is in the table of
> trusted
>> parameters and otherwise rejects it. We distribute miTLS with a
> pre-populated
>> table of parameters which we tested thoroughly (and we welcome people to
>> test further). Most of the time we hit an entry in the table.
>>
>> I think a table lookup per key exchange is about as reasonable as it gets.
>>
>> Cheers,
>> --Santiago
>>
>> ________________________________________
>> From: Nikos Mavrogiannopoulos <[e-mail]>
>> Sent: Thursday, May 21, 2015 12:51 PM
>> To: Florian Weimer
>> Cc: Santiago Zanella-Beguelin; [e-mail]
>> Subject: Re: [TLS] Another IRINA bug in TLS
>>
>> On Thu, 2015-05-21 at 13:42 +0200, Florian Weimer wrote:
>> > On 05/21/2015 01:31 PM, Santiago Zanella-Beguelin wrote:
>> >
>> > > Deprecating non-safe DH primes and having clients test primality of p
> and
>> (p-1)/2 goes a long way. It doesn't rule out all weak groups or trapdoors.
>> >
>> > I need something which prevents MITM attacks and can be applied as a
>> > software update without configuration changes, and without extensive
>> > testing because it is relatively risk-free.
>>
>> Well, you assume that the so-called "safe primes" are universally used,
> which is
>> not really the case. Expecting all servers sending these parameters
> wouldn't
>> really work. In addition the check you have isn't complete, you'll also
> need to
>> calculate the order of the generator and verify it is sufficient. I don't
> think that
>> approach is close to being reasonable to be done on every connection.
>>
>> > Rejecting handshakes in clients without additional measures risks that
>> > (a) additional handshakes fail, leading to service outages and (b)
>> > clients will fall back no encryption at all (after manual
>> > intervention, or automatically in case of SMTP with STARTTLS and
>> > opportunistic encryption).
>>
>> The way I tackled the issue in gnutls is to prioritize the ciphersuites of
> the client
>> in that order: ECDHE, RSA, DHE, and perform a size check on the DHE ones.
>>
>> regards,
>> Nikos
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.