Subject: [TLS] Another IRINA bug in TLS

From: Watson Ladd <[email-masked]>
Date: Wed, 20 May 2015 10:05:25 -0400

https://weakdh.org/

Transcript hashing will solve this problem. In the meantime, you want
to turn off DH_EXPORT. There are also implications for false start.
Chrome has already announced countermeasures. I'm pretty sure this
won't be the last issue of this nature.

Sincerely,
Watson Ladd

---

From: Tom Ritter <[email-masked]>
Date: Wed, 20 May 2015 09:48:44 -0500

On 20 May 2015 at 09:05, Watson Ladd <[email-masked]> wrote:
> https://weakdh.org/
>
> Transcript hashing will solve this problem.

Will it?  (Or at least, I'm not sure where you intend to include the
transcript hash, in which case - maybe.)

I think the issue is the same as the Section 4.4 here:
https://www.schneier.com/paper-ssl-revised.pdf - the underlying cause
being that the ephemeral parameters' signature doesn't include enough
context.   In Schneier's, the algorithm needed to be included (it
still isn't, in TLS 1.2 - we just (hope) we have stricter checking on
the data in implementations).

In this one, the signature could be argued to be needed to go over the
ciphersuite (to say "Don't use these parameters except with this
ciphersuite"), maybe more data (to say "Only uses these parameters if
you've sent me this transcript"), or even arguably no change at all:
don't sign things you don't intend to use.  (Not that that last one is
good IMO.)

If you mean hash the transcript into the master secret (e.g. the
extended master secret draft) - I don't think that's a fix.  The
client will hash all of its handshake messages into its master secret
- but the client is talking to _me_ the attacker.  I copy-and-paste
the server's ephemeral parameters, and the signature, but I can derive
the same MS as the client and happily talk to the client, decrypting
and passing the data back along to the server who I'm talking to in a
different connection.

-tom

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 20 May 2015 17:59:26 +0300

> Transcript hashing will solve this problem.

AFAICT, extended_master_secret won't save you from this.

The problem is screwed up server key PoP, and EMS will not fix that
(TLS 1.3 does).

Also, this is not the first attack arising from the way server key
PoP is done...

BTW: Client key PoP is not screwed, so attacker can't forward client
certs...

> In the meantime, you want to turn off DH_EXPORT.

Only works on serverside...

> There are also implications for false start.

I have regarded using false start with non-named groups (and
thus without key checks) as a bad idea.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 May 2015 17:02:50 +0200

On Wed, 2015-05-20 at 10:05 -0400, Watson Ladd wrote:
> to turn off DH_EXPORT. 

The interesting thing is that there are no DHE_EXPORT ciphersuites.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 20 May 2015 17:19:56 +0200

Hi,

> The interesting thing is that there are no DHE_EXPORT ciphersuites.

I was also wondering about that. IANA has no entries for DHE_EXPORT*. As
far as I can tell there isn't even information on the searchable web on
that. If you google DHE_EXPORT it'll point you to this very paper and
that's about it.

Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 20 May 2015 11:57:51 -0400 (EDT)

----- Original Message -----
> that. If you google DHE_EXPORT it'll point you to this very paper and

They are most probably using sloppy language and mean the DHE ciphersuites
with parameters of 512 bits or less.

regards,
Nikos

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 20 May 2015 16:15:06 +0000

OpenSSL and logjam, fyi: http://openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/  Includes explanation of why "export" is important.
--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Watson Ladd <[email-masked]>
Date: Wed, 20 May 2015 12:23:25 -0400

> that. If you google DHE_EXPORT it'll point you to this very paper and

This is what I get for writing before coffee.

They do mean DHE_EXPORT to refer to dhe_rsa_export and dhe_dss_export,
as "defined" in RFC 2246. These are ciphersuite values.

Tom Ritter's comments are correct: synchronization isn't going to work
here, and we should either disable insecure ciphers entirely or ensure
that signatures of keys indicate the context. Clients need to do more
validation of DH parameters.

Finally, as DJB pointed out on twitter so long as insecure options
need to be removed. Not disabled, removed. That way bugs like this
one, or other negotiation bugs, cannot lead to insecure ciphers being
used.

Sincerely,
Watson Ladd

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

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Wed, 20 May 2015 16:58:06 +0000

Indeed, we are lazy and didn't want to write things like TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in full.

The extended master secret extension won't prevent the attack because the downgrade happens within the handshake and before key confirmation.

If the signature in the ServerKeyExchange message covered a hash of the transcript so far (including the ciphersuite that the server chose), downgrading to "DHE_EXPORT" would no longer be possible.

To be fair, it's not an "INRIA bug". It's joint work with U. Penn, U. Michigan, Johns Hopkins, and Microsoft Research (funded in part by the Microsoft Research-Inria joint centre in Paris).

Cheers,
--Santiago
________________________________________
From: TLS <[email-masked]> on behalf of Watson Ladd <[email-masked]>
Sent: Wednesday, May 20, 2015 3:05 PM
To: [email-masked]
Subject: [TLS] Another IRINA bug in TLS

https://weakdh.org/

Sincerely,
Watson Ladd

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: [email-masked] (Martin Rex)
Date: Wed, 20 May 2015 21:43:25 +0200 (CEST)

> the data in implementations).

Correct.  For some unclear reason, the original signature over the
ServerKeyExchange handshake message was ill-designed, in that it
does not cover all prior handshake messages (ClientHello,ServerHello,
ServerCertificate), but only the ClientHello.random & ServerHello.random
besides the Servers parameters.

Now the issue of weak ephemeral Diffie-Helman keys has been raised
here before (14-May-2007):

  http://www.ietf.org/mail-archive/web/tls/current/msg01647.html

and a few other occasions.  The last time that I remember the behaviour
of the installed base (not refusing short or bogus DH parameters)
being described as a problem was in the description of the 
Triple-Handshake-Attack (return of renego).

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 May 2015 06:10:08 +0000

>The interesting thing is that there are no DHE_EXPORT ciphersuites.

No, the interesting thing (or more accurately the MASSIVE SCREAMING WTF) is
that there are widely-deployed web server and browser implementations out
there that will still use 512-bit keys.  Not custom embedded environments
where you're using TLS as a privacy screen and anything that counters basic
packet sniffing is just fine, but production public-internet web servers and
browsers.  The point to make isn't "fancy security mechanism X would have
prevented this" but "why are these things still using crypto at the level of
RC4_40_WITH_MD5" in 2015?

Peter.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 21 May 2015 09:29:04 +0200

> Indeed, we are lazy and didn't want to write things like TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in full.

Are you sure you refer to TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in that
paper for the attack? I doubt this ciphersuite is supported by any
browser at all, and for sure this ciphersuite is not supported by any
web site (it requires an export DSA certificate, and there are none on
the internet).

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 21 May 2015 09:46:44 +0200

> as "defined" in RFC 2246. These are ciphersuite values.

I stand corrected. It is an interesting attack, but it is very
surprising to see ghosts like these ciphersuites present in real
servers.

regards,
Nikos

---

From: Yuhong Bao <[email-masked]>
Date: Thu, 21 May 2015 00:49:10 -0700

AFAIK neither IE or Netscape ever supported DHE_RSA_EXPORT either, and when the EXPORT1024 suites was created they did not bother with DHE_RSA suites either.

----------------------------------------
> From: [email-masked]
> To: [email-masked]
> Date: Thu, 21 May 2015 09:29:04 +0200
> CC: [email-masked]
> Subject: Re: [TLS] Another IRINA bug in TLS
>

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Thu, 21 May 2015 00:53:29 -0700

From the protocol point of view, this is yet another instance of the “cross-protocol attack” [1.2]
as we note in the longer version of the paper. The DHE_EXPORT signature can be used 
with DHE, enabling the attack.

[1] D. Wagner and B. Schneier. Analysis of the SSL 3.0 protocol. In 2nd Usenix Workshop on Electronic Commerce, 1996. 
[2] N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, and B. Preneel. A cross-protocol attack on the TLS protocol. In ACM CCS, pages 62–72, 2012.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 21 May 2015 10:01:58 +0200

On 05/21/2015 08:10 AM, Peter Gutmann wrote:
> there that will still use 512-bit keys.

But removing that support is going to be tricky.  If the server has only
export-grade DH parameters (but does not actually support export cipher
suites), and it is willing to negotiate DHE cipher suites, you end up
with an interop failure, although you could well negotiate a reasonable
secure connection without a forward secrecy cipher suite.

Maybe we need SCSVs which express constraints on the size of the DH
prime?  If the server cannot match the constraints due to its
configuration, then it would not use forward secrecy.  That would give
(me at least) much more confidence for large-scale roll-out.

It would be a pity if, as a result of fixing this, more email is sent
over the wire completely in the clear.

-- 
Florian Weimer / Red Hat Product Security

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 21 May 2015 10:09:59 +0200

> (me at least) much more confidence for large-scale roll-out.

I think it would make sense to push for adoption of:
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09

However, that would not solve the incompatibility issue with old
servers. For that to happen, either the whole DHE ciphersuite space has
to be reassigned to new numbers, or move the DHE ciphersuites to the end
of the client's list.

regards,
Nikos

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 09:59:33 +0000

> Are you sure you refer to TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA in that paper for the attack?

That was just an example, and you're right that's an uncommon ciphersuite. 
We did find many HTTPS servers supporting TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA.

Cheers,
--Santiago

________________________________________
From: Nikos Mavrogiannopoulos <[email-masked]>
Sent: Thursday, May 21, 2015 8:29 AM
To: Santiago Zanella-Beguelin
Cc: [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

regards,
Nikos

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 May 2015 10:02:19 +0000

>We did find many HTTPS servers supporting TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA.

Just to make sure that's not a typo, you're saying you *did* (not didn't) find
many servers supporting 40-bit DES as a cipher?  Wow.  How many approximately,
are we talking tens, thousands, millions?

Peter.

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Thu, 21 May 2015 12:10:07 +0200

> are we talking tens, thousands, millions?

For reference, in my 530K sample (Biased towards Alexa top million sites)  
there are 60000 servers (11.38%) that have that specific cipher suite  
enabled, as of Monday this week.

-- 
Sincerely,
Yngve N. Pettersen

Using Opera's mail client: http://www.opera.com/mail/

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 May 2015 10:16:28 +0000

>enabled, as of Monday this week.

Hmm, so what's the next escalation level beyond the previous "GIANT SCREAMING
WTF"?  Perhaps a twelve-storey WTF with a magnificent entrance hall, carpeting
throughout, 24-hour portage, and an enormous sign on the roof, saying 'This Is
a Major [0] WTF'?

Peter.

[0] Or perhaps General Sir Anthony Cecil Hogmanay Melchett.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 21 May 2015 13:32:44 +0300

> On May 21, 2015, at 1:16 PM, Peter Gutmann <[email-masked]> wrote:
> 
> WTF”?  

If the website turned out to be a bank or an HMO?

---

From: Antoine Delignat-Lavaud <[email-masked]>
Date: Thu, 21 May 2015 13:04:38 +0200

> AFAICT, extended_master_secret won't save you from this.

This is correct. Unfortunately, the realization that the signature on 
the ServerKeyExchange message suffers from the same weakness (it only 
covers nonce instead of current session-hash) as the master key 
derivation came a bit late into the session-hash draft standardization 
(however, browser vendors were given ample time to address this issue).

It is worth noting that Nikos had previously proposed to extend the 
context coverage of the SKE signature to prevent a cross-ciphersuite attack.

It is not clear at this point whether draft-ietf-tls-session-hash can be 
extended to replace nonces with the current session-hash in the SKE 
signature without causing standardization issues.

Antoine

---

From: Florian Weimer <[email-masked]>
Date: Thu, 21 May 2015 13:09:26 +0200

> https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-09

Interesting.  But do we want to encourage the use of additional magic
primes?

> However, that would not solve the incompatibility issue with old

You mean, if the client rejects handshakes with defective primes, it
will not be able to connect to servers which use them?

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 21 May 2015 13:15:09 +0200

> Interesting.  But do we want to encourage the use of additional magic

We do the same with elliptic curves. We agreed on some groups and use
these for simplicity. With arbitrary groups, a client cannot verify the
quality of the parameters of the provided group by the server. It can
only check its size which is an insufficient test if a client wants to
enforce a particular security level.

> will not be able to connect to servers which use them?

The use case that will fail, is if there is a server which is configured
to prefer DHE ciphersuites, and is setup with 512-bit primes, then no
client will be able to connect to it, unless it disables DHE.

regards,
Nikos

---

From: Florian Weimer <[email-masked]>
Date: Thu, 21 May 2015 13:20:30 +0200

On 05/21/2015 01:15 PM, Nikos Mavrogiannopoulos wrote:

> We do the same with elliptic curves.

I think the situation with curves is markedly different because
individual curves can have quite different properties.  With safe DH
primes of similar size, one is presumably as good as the other.

> We agreed on some groups and use
> quality of the parameters of the provided group by the server.

It could still run a primality check on (p - 1) / 2.

> It can only check its size which is an insufficient test if a client wants to

On the other hand, a broken server might leak key material by other
means, and if that happens, there is nothing a client can do about that.

> client will be able to connect to it, unless it disables DHE.

Yes, this is a tough scenario to solve.

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 11:31:04 +0000

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.

________________________________________
From: TLS <[email-masked]> on behalf of Florian Weimer <[email-masked]>
Sent: Thursday, May 21, 2015 12:20 PM
To: Nikos Mavrogiannopoulos
Cc: [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

---

From: Florian Weimer <[email-masked]>
Date: Thu, 21 May 2015 13:42:16 +0200

> 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.

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).

I'm not sure if it is feasible to produce a risk-free software update
for this issue.  But, say, rejecting DH primes smaller than 1024 bits is
not, at least not along with other compensating measures.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 21 May 2015 13:51:44 +0200

> 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.

> or automatically in case of SMTP with STARTTLS and opportunistic

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

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 12:06:59 +0000

No typo. Yngve's numbers are in line with ours: 44k for Alexa top 1M websites, and 1.75M for full IPv4 on port 443.

That ciphersuite won't be negotiated by any modern client, but one can downgrade the handshake to use the weak DHE parameters that the server selects with it.

--Santiago
________________________________________
From: Peter Gutmann <[email-masked]>
Sent: Thursday, May 21, 2015 11:02 AM
To: Santiago Zanella-Beguelin; Nikos Mavrogiannopoulos
Cc: [email-masked]
Subject: RE: [TLS] Another IRINA bug in TLS

Peter.

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 12:27:07 +0000

> 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.

Yes, non-safe primes should be first deprecated.

> 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.

Checking the order of the generator for safe primes is ridiculously
cheap: just an interval check. That's not the case for non-safe
primes, where it would cost you a fixed-base exponentiation. This
assuming you somehow know the subgroup order, which is not sent in the
TLS handshake. 

I think it would be reasonable for clients to test if a DH prime is
safe by running a few rounds of primality tests.

________________________________________
From: Nikos Mavrogiannopoulos <[email-masked]>
Sent: Thursday, May 21, 2015 12:51 PM
To: Florian Weimer
Cc: Santiago Zanella-Beguelin; [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 21 May 2015 15:27:38 +0200

Hi,

> Yes, non-safe primes should be first deprecated.

I'm curious: what are instances where unsafe primes are still used,
generated and distributed for use in TLS? Hence where do we need to
deprecate?

Thanks,
Aaron

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 13:42:07 +0000

Non-safe primes can be generated using OpenSSL dhparam with the -dsaparam flag, e.g. openssl dhparam -dsaparam 2048

They are still very common. In a recent full IPv4 scan on port 443, we found 1.7M hosts using non-safe primes against 8.42M using safe primes.

By far, the most common non-safe prime appears to come from hosts using Amazon EC2; around 321K hosts authenticating with browser-trusted certificates use it.

________________________________________
From: Aaron Zauner <[email-masked]>
Sent: Thursday, May 21, 2015 2:27 PM
To: Santiago Zanella-Beguelin
Cc: Nikos Mavrogiannopoulos; Florian Weimer; [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

Hi,

Thanks,
Aaron

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Thu, 21 May 2015 15:48:15 +0200

> generated and distributed for use in TLS? Hence where do we need to

The "safe primes" is only a name. There are safe primes for DH that are
not in the "safe primes" category. The primes used in DSA are such ones.

regards,
Nikos

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 21 May 2015 15:54:08 +0200

> not in the "safe primes" category. The primes used in DSA are such ones.

Ok, let's assume "safe primes" means sophie germain primes in this
thread. :)

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 21 May 2015 15:56:27 +0200

> By far, the most common non-safe prime appears to come from hosts using Amazon EC2; around 321K hosts authenticating with browser-trusted certificates use it.

I'm not sure these are all due to people using openssl(1) with the
"-dsaparam" option, that's a huge number. My question was actually if
people are aware that implementations produce these primes per default.

Aaron

---

From: Watson Ladd <[email-masked]>
Date: Thu, 21 May 2015 09:59:46 -0400

> not in the "safe primes" category. The primes used in DSA are such ones.

Why does it even matter? If everyone disabled ciphersuites that never
should have been used in the first place, we wouldn't be having this
conversation. Instead we're planning yet another patch.

We've decided that when responding to security issues, we'll throw on
more options, even when other alternatives exist, with the goal of
never scheduling depreciation. This increases implementation burden,
slows adoption, and ultimately harms security. Notice how we've kept
CBC mode alive by adopting RFC whatever it was, instead of instructing
everyone to move to AES-GCM, which has been out for 7 or so years. At
the same time we've not fixed known problems: logjam is only the
nastiest variation of problems caused by the signature on DH
parameters not indicating the ciphersuite.

Our thinking needs to be geared towards ending these problems.

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 14:29:13 +0000

Nitpicking: the Sophie Germain prime is (p-1)/2. We're stuck with the somewhat misleading name "safe prime" for p. 

________________________________________
From: Aaron Zauner <[email-masked]>
Sent: Thursday, May 21, 2015 2:54 PM
To: Nikos Mavrogiannopoulos
Cc: Santiago Zanella-Beguelin; Florian Weimer; [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

Aaron

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 14:36:08 +0000

> "-dsaparam" option, that's a huge number. 

I'm sure they are not all using OpenSSL. 
Other popular groups with a non-safe prime come from RFC 5114 (http://tools.ietf.org/html/rfc5114#section-2).

> My question was actually if people are aware that implementations
> produce these primes per default.

Java does: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/4fcbddfd97f0/src/share/classes/sun/security/provider/ParameterCache.java

Cheers,
--Santiago

Sent: Thursday, May 21, 2015 2:56 PM

Aaron

---

From: Dave Garrett <[email-masked]>
Date: Thu, 21 May 2015 10:36:56 -0400

> testing because it is relatively risk-free.

I also want a pony.

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Thu, 21 May 2015 14:52:47 +0000

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

regards,
Nikos

---

From: Dan Brown <[email-masked]>
Date: Thu, 21 May 2015 16:51:18 +0000

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.  

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.  

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.

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.  

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:[email-masked]] On Behalf Of Santiago Zanella-
> Beguelin
> Sent: Thursday, May 21, 2015 10:53 AM
> To: Nikos Mavrogiannopoulos; Florian Weimer
> Cc: [email-masked]
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
> 
> > > 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.
> >
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.
> 
> > 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
>

---

From: Watson Ladd <[email-masked]>
Date: Thu, 21 May 2015 13:57:54 -0400

> 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.

> Choosing a larger key size is the most efficient and simple remedy against

Exactly. No need to proceed further.

> 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?

> be added later after some further discussion about the best way to specify

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?

---

From: Dan Brown <[email-masked]>
Date: Thu, 21 May 2015 20:45:04 +0000

> From: Watson Ladd [mailto:[email-masked]]
>
> > 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.

[DB] That's how I read their medium term recommendation.  I agree with them, 
and you, that larger groups should be the first defense (they call it short 
term).  I guess that by "medium term", they mean to apply it in addition to 
the short term, perhaps at a later date.  I think such countermeasures should 
be optional.

It probably does make sense to postpone this discussion, with other priorities 
taking precedence.

This paper seems to demonstrate that this well-known fact of pre-computation, 
which perhaps should have been anticipated, could potentially have real-world 
consequences.  Past deployments of 1024-bit DH (and smaller) seem not to have 
anticipated this risk adequately.  So, it does illustrate this issue here 
well.

>
> >
> > Choosing a larger key size is the most efficient and simple remedy
> > against these pre-computations.
>

[DB] The imperfect forward secrecy paper cites Semaev's example of DHE groups 
with easier-than-average discrete logs as a reason to not rely entirely 
fixed-prime groups.  The current I-D FFDHE uses e to provide a 
nothing-up-my-sleeve NUMS property, so it seems like a concern that has been 
considered already. It seems to me almost certain that the current I-D does 
indeed achieve NUMS property, much like the Brainpool curves do for ECC.  So, 
this particular risk seems minute, but it can be hard to shake off suspicions.

> > 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.
>
[DB] Well, as I said it's only a second line of defense. I would only support 
it as an option for those who can afford the extra cost: the reasons to use 
this are not enough to mandate this countermeasure.

Here's an unlikely situation in which it may help thwart mass surveillance 
(rather than help a targeted individual or session).

The trend in factoring and FFDLP algorithms is that new algorithms are only 
faster than old algorithms above some key size.  In other words, a plot of the 
new FFDLP algorithm's runtime against keysize rises sharply then flattens out, 
eventually undercutting the older algorithms.  If this trend continues, then a 
future (or secret) attack may be flatter than the current best known FFDLP 
algorithms, in which case the gain from larger keysize is not as much as 
expected by looking at the published FFDLP algorithms.  (Of course, the best 
countermeasure to this small risk would be ECDHE!) If all goes well, this 
flatter attack will never (has never) happen(ed).   But if it does happen, and 
everybody used the same larger group, their extra effort may not have helped a 
non-targeted user as much as if everybody used smaller different groups.

The risk mitigations provided by increased group size versus diversification 
of groups are rather different in quality, and are thus hard to compare.  But 
for users more interested in avoiding mass-surveillance rather than targeted 
attacks, might prefer to spend their spare computational power accordingly.

> >
> > 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.

[DB] Yes, custom groups have led to attacks, but that seems to be more due to 
some fumbles about ambiguously encoding them.  I hope that once the dust 
settles a bit, and TLS puts more effort into *DHE, instead of RSA key 
exchange, such ambiguity can be resolved.  In other words, any proposal for 
custom groups should be done quite carefully.

> 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?
>

[DB] Everybody sharing a group creates a large incentive and single target for 
an attacker.  If the computational power of the attacker tops out at some 
value (i.e. at some max bit-op per dollar), and we've chosen a group size just 
below this top power attack, then the difference is whether that attacker can 
compromise a small targeted set of users of one group, versus a 
mass-surveilance of nearly all users.  To make it concrete, for a group whose 
size tops out the attack at two months, then it buys a non-targeted 
(mass-surveiled) user a number of months equal to the number of groups that 
have been used.

Again, I emphasize, that this would only be a second line of defense: the 
first line is choosing the right size of group.

---

From: Jeffrey Walton <[email-masked]>
Date: Thu, 21 May 2015 17:54:58 -0400

> the short term, perhaps at a later date.  I think such countermeasures should

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

    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.

---

From: Nico Williams <[email-masked]>
Date: Thu, 21 May 2015 17:06:57 -0500

> anything at 1024-bits or below.

I think that's right.  ECC here, so we should respond by moving to ECC.

---

From: Kurt Roeckx <[email-masked]>
Date: Fri, 22 May 2015 19:56:19 +0200

> practice, I wanted to make some publicity for miTLS

I was unable to get it to build (using free software).

> rejects it.

When is it non-safe but trusted?

> We distribute miTLS with a pre-populated table of

I assume that's a table lookup in case it hasn't seen that prime
yet?  But I understand that they're recommending everybody to
generate their own prime.

Kurt

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Fri, 22 May 2015 22:36:57 +0200

> 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

---

From: Tony Arcieri <[email-masked]>
Date: Fri, 22 May 2015 14:12:51 -0700

On Fri, May 22, 2015 at 1:36 PM, Karthikeyan Bhargavan <
[email-masked]> wrote:

> 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.

+1 on this. The CFRG has already specified Curve25519 and Ed448-Goldilocks
for use in this case:

https://tools.ietf.org/html/draft-irtf-cfrg-curves-02

Finite field D-H is slower and more problematic. I know people want it as a
fallback in the event there's some sort of terrible breakage in ECC, but if
that does happen, why not temporarily abandon forward secrecy until the
problem can be addressed instead of switching to finite field D-H?

Otherwise, all it's doing is making TLS more complicated and vulnerable to
these sorts of downgrade attacks.

-- 
Tony Arcieri

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Fri, 22 May 2015 23:35:51 +0000

Hi Kurt,

> I was unable to get it to build (using free software).

I've just succeeded building mTLS-0.8.1 using Mono 3.10.0.0. I haven't tried
Mono 4 or .NET core (MIT license). You can send me a private mail if you want me
to help you troubleshoot.

> > If the modulus is prime but not safe, miTLS

When it is in the table of trusted parameters, and hence we know the subgroup order
(the prime q in DSA terminology). Just to avoid misunderstandings, we clarified
the formal meaning of "non-safe" earlier in this thread.

> yet?  

It's a table lookup when it *has* seen the prime before.

> But I understand that they're recommending everybody to generate their own
> prime.

I believe large >=2048 bits fixed primes, like the ones proposed in the
negotiated-ff-dhe draft, are fine for the time being. See Karthik's message on
this same thread which better clarifies what our recommendations are.

--Santiago

________________________________________
From: Kurt Roeckx <[email-masked]>
Sent: Friday, May 22, 2015 6:56 PM
To: Santiago Zanella-Beguelin
Cc: Nikos Mavrogiannopoulos; Florian Weimer; [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 23 May 2015 12:16:09 +0200

> enabled, as of Monday this week.

Hubert Kario's latest results on
https://securitypitfalls.wordpress.com/2015/03/29/march-2015-scan-results/
show:
EXP-EDH-RSA-DES-CBC-SHA 22110     4.5043%

Kurt

---

From: Kurt Roeckx <[email-masked]>
Date: Sat, 23 May 2015 14:11:52 +0200

On Fri, May 22, 2015 at 10:36:57PM +0200, Karthikeyan Bhargavan wrote:
> Figuring out what's a good long-term alternative is for a community forum like this to decide. 
> 

The weakdh.org site currently says:
| If you run a server...
| 
| If you have a web or mail server, you should disable support for
| export cipher suites and generate a unique 2048-bit Diffie-Hellman
| group.

Should that be changed to "and use a 2048-bit Diffie-Hellman
group"?

Kurt

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Sat, 23 May 2015 13:10:47 +0000

> Should that be changed to "and use a 2048-bit Diffie-Hellman

It should. We'll soon update the website and the report to clarify this.

________________________________________
From: TLS <[email-masked]> on behalf of Kurt Roeckx <[email-masked]>
Sent: Saturday, May 23, 2015 1:11 PM
To: Karthikeyan Bhargavan
Cc: [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

Kurt

---

From: Tanja Lange <[email-masked]>
Date: Sun, 24 May 2015 13:20:39 +0200

Hi,
> the formal meaning of "non-safe" earlier in this thread.
Do you have an easy pointer to the table? I've poked around a bit in 
the online interface but couldn't get to it. Where did you get the
DSA parameters from? RFC 5114?

Thanks
	Tanja

---

From: Santiago Zanella-Beguelin <[email-masked]>
Date: Sun, 24 May 2015 12:27:00 +0000

Hi Tanja,

miTLS-0.8.1 (http://www.mitls.org/downloads/miTLS-0.8.1.tgz) comes with a table (data/dh/dhparams-db.bin) with just one entry for the 2432-bit group used by default. In case you wonder, that group comes from an early version of the negotiated-ff-dhe draft and uses a safe prime.

We have a larger table that includes several common DSA parameters. We got the q values from many sources, including RFCs and factorization with GMP-ECM and CADO-NFS. Our plan is to include that table and utilities to maintain it in the next release of miTLS, but I'm also working on making it available independently.

________________________________________
From: Tanja Lange <[email-masked]>
Sent: Sunday, May 24, 2015 12:20 PM
To: Santiago Zanella-Beguelin
Cc: Kurt Roeckx; Florian Weimer; [email-masked]
Subject: Re: [TLS] Another IRINA bug in TLS

Hi,

Thanks
        Tanja

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 May 2015 13:19:16 +0200

On Friday 22 May 2015 14:12:51 Tony Arcieri wrote:
> >     As usual, we need to be wary of weak curves (160-bit) or curves that
> > 
> > may have been generated maliciously.
> > 

There is a second side to this coin.

Implementing ECDH (just like most ECC), is much harder that DH or RSA.
As such, for old software that receives just minimal maintenance it is easier 
to add support for advertising support for (big) FF-DHE than to add ECDHE.

-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 May 2015 14:02:40 +0200

> EXP-EDH-RSA-DES-CBC-SHA 22110     4.5043%

hmm, that is a bit big difference...

If I ignore the "trust" bit in results I'm still getting just:
EXP-EDH-RSA-DES-CBC-SHA 41804     6.2565

From 668168 sample.

But then there is something which matches rather well the percentage:
EDH-RSA-DES-CBC-SHA     75939     11.3653
(note the lack of "EXP-")
-- 
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 25 May 2015 14:26:52 +0200

> EXP-EDH-RSA-DES-CBC-SHA 41804     6.2565

At weakdh.org, we use numbers from the ZMap scans (https://scans.io/)

In March 2015, the number of servers supporting for TLS_DHE_*_EXPORT_* were:

Alexa Top 1M:      45 K hosts out of 539K HTTPS hosts (4.9%)
Browser-trusted : 706K hosts out of 14.3M HTTPS hosts with browser trusted certs (8.4%)

We think the numbers should have gone down some, partly due to servers turning off *_EXPORT_*
in the wake of FREAK (but sadly, not nearly enough servers reacted to FREAK).

Best,
Karthik

> Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic_______________________________________________
> TLS mailing list
> [email-masked]

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 25 May 2015 14:27:55 +0200

Argh, percentages revesed:

Alexa Top 1M:      45 K hosts out of 539K HTTPS hosts (8.4%)
Browser-trusted : 706K hosts out of 14.3M HTTPS hosts with browser trusted certs (4.9%)

---

From: Hubert Kario <[email-masked]>
Date: Mon, 25 May 2015 14:54:39 +0200

> Alexa Top 1M:      45 K hosts out of 539K HTTPS hosts (8.4%)

which would align with the "ignored trust bit" (3k difference), as cipherscan 
is using a scanning method which will under-report servers with broken cipher 
selection (intolerance to big client hello's, RC4 ciphers low in order, etc.).

Those broken servers can account for up to 11k or 8.8k hosts (when ignoring 
trust) depending on how you count.

Anyway, I've started a new scan yesterday, we'll see how quickly 
administrators reacted.

My scans are also on https://scans.io (look for Fedora Project), if you're 
interested in raw data.

But AFAIK, Yngve's aren't and those are the ones we were commenting about.

> > We think the numbers should have gone down some, partly due to servers
> > turning off *_EXPORT_* in the wake of FREAK (but sadly, not nearly enough
> > servers reacted to FREAK).
> > 
> > Best,
> > Karthik
> > 
> >> From 668168 sample.
> >>