Re: [TLS] Another IRINA bug in TLS

[Karthikeyan Bhargavan <[e-mail]>]

> I think the authors felt the same. But in Section 4 of the paper, they said:

As one of the authors of the paper, let me try to clarify our recommendations a little bit.
First, we only know what is broken, and can only make precise recommendations for avoiding the attacks in the paper.
Figuring out what’s a good long-term alternative is for a community forum like this to decide. 

If we were to make a recommendation for TLS, at least as it is used on the web, it would be as follows, 
in decreasing order of preference:

1) Switch to ECDHE. 
    It is faster, and the kinds of attacks discussed in our paper have not (yet) been shown to be effective for the common curves.
    As usual, we need to be wary of weak curves (160-bit) or curves that may have been generated maliciously.
    We leave it to the EC folks to tell us what are good curves to use.

2) Switch to stronger (>=2048-bit) DHE groups.
    If ECDHE is unavailable, we are happy (today) with >= 2048 groups as suggested in the FF-DHE draft.
    As usual, we have to be wary of how these groups are generated, since there is the possibility of trapdoors being built in.
    Using well known constants such as pi or e as the basis for prime generation (e is used in FF-DHE) is, as far as we know, 
    a safe technique for generating a group with a low probability of a trapdoor.

3) Do not use fixed 1024-bit groups.
    If ECDHE or 2048-bit groups are both infeasible and 1024-bit groups need to be used for legacy reasons, 
    we recommend that servers generate fresh 1024-bit groups regularly to increase the computational cost of an attack.
    When a particular group size becomes computationally reachable, the clock starts ticking on all groups of that size.
    After that point, the use of fixed groups begins to bite, because the cost of breaking each group can be amortised across its users.
    We (and others) believe that 1024-bit groups may have become breakable, but the cost of precomputation for each group is still quite high.
    Let’s make things harder for the adversaries by changing groups so that their precomputations are wasted.
    As usual, we need to take care when generating new groups: e.g. use randomly-generated safe primes.

4) In all cases, do not use groups of size < 1024.
    Groups of size 512- and 768- are broken today. We can do it with academic processing power.
    Get rid of these groups, especially the popular Oakley Group 1 and the 768-bit groups in Java and older versions of IIS.
    Of course, disable *_EXPORT_* immediately.

We don’t know which of the above apply to non-web uses of TLS, but since all major web browsers support ECDHE with p-256 and higher,
the first recommendation should, in our view, already be adequate for the web. I’d be curious to know if it isn’t and why?    
    
Best regards,
Karthik


> 
>    In this section we address the following
>    question: how secure is Diffie-Hellman in broader practice,
>    as used in other protocols that do not suffer from downgrade,
>    and when applied with stronger groups?
> 
>    To answer this question we must first examine how the
>    number field sieve for discrete log scales to 768- and 1024-bit...
> 
>    Unfortunately, our measurements also indicate that it
>    may be very difficult to sunset the use of fixed 1024-bit Diffie-
>    Hellman groups that have long been embedded in standards
>    and implementations.
> 
> I think they are politely saying standard groups should do away with
> anything at 1024-bits or below.
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls