Subject: [TLS] I-D Action: draft-ietf-tls-negotiated-ff-dhe-02.txt

From: [email-masked]
Date: Fri, 10 Oct 2014 21:49:48 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the IETF.

        Title           : Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS
        Author          : Daniel Kahn Gillmor
	Filename        : draft-ietf-tls-negotiated-ff-dhe-02.txt
	Pages           : 24
	Date            : 2014-10-10

Abstract:
   Traditional finite-field-based Diffie-Hellman (DH) key exchange
   during the TLS handshake suffers from a number of security,
   interoperability, and efficiency shortcomings.  These shortcomings
   arise from lack of clarity about which DH group parameters TLS
   servers should offer and clients should accept.  This document offers
   a solution to these shortcomings for compatible peers by using a
   section of the TLS "EC Named Curve Registry" to establish common DH
   parameters with known structure and a mechanism for peers to
   negotiate support for these groups.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-negotiated-ff-dhe-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sat, 11 Oct 2014 00:55:07 -0400

>    negotiate support for these groups.

This update pushed the proposed syntactic changes to the ff-dhe draft,
dropping the explicit extension and making reuse of the NamedCurves
registry for finite field groups as well.

I'd appreciate any comments or suggestions, and particularly review
related to the IANA considerations would be great.

The xml2rfc source for the draft can be found (among other places) on
github:

 https://github.com/dkg/tls-negotiated-ff-dhe

patches welcome,

	--dkg

---

From: Henrick Hellström <[email-masked]>
Date: Sat, 25 Oct 2014 18:45:51 +0200

> related to the IANA considerations would be great.

It seems to me the the recommended Client Behavior and Server Behavior 
has to be simplified and strengthened, in order for the standard to meet 
the security objectives.

All relevant attacks here https://secure-resumption.com/ seem to involve 
a MITM server that chooses bad ServerDHParams for the server key 
exchange message.

   * Clearly, a MITM server might simply act as if it doesn't support 
the "elliptic_curves" extension. The server does not include a reply to 
the "elliptic_curves" extension in server_hello, so the client will not 
receive any indication of lack of support, until it receives 
server_key_exchange. At this point, the client might decide to terminate 
the handshake if the ServerDHParams aren't acceptable. Checking an 
arbitrary group by means of a binary compare, is only marginally harder 
than checking a named group.
   * Conversely, a MITM that connects to a legitimate server, will be 
perfectly able to carry out the secure resumption attacks, even if the 
MITM and the legitimate server negotiate using a fixed FFDHE group. (It 
is only the ServerDHParams used in the handshake between the legitimate 
client and the MITM that have to be doctored.)
   * Also, there doesn't seem to be any obvious harm in requiring that a 
compatible server always picks a ServerDHParams group with an estimated 
security equal to the minimum of the server certificate public key and 
the bulk encryption cipher, regardless of the presence or absence of an 
"elliptic_curves" extension in client_hello. If this group is encoded as 
an arbitrary group in ServerDHParams, there is no divergence from 
current standards at the protocol level.

Hence, in order to introduce as little complexity as possible into the 
client behavior and server behavior, as well as actually strengthening 
security by implementing this mechanism, I suggest something along these 
lines:

Client Behavior

Conforming clients MIGHT require that a FFDHE group with appropriate 
security bounds is presented by a specific server. If the use of such 
groups are required by the client, the client SHOULD NOT offer cipher 
suites that might force a compatible server to pick a group the client 
does not implement.

A client that requires the use of FFDHE groups MUST perform a binary 
compare of the ServerDHParams against the FFDHE group with the 
corresponding modulus size, and MUST end the handshake with an 
insufficient_security alert if the parameters do not match.

In order to avoid ambiguities if FFDHE groups are added, replaced or 
deprecated in future revisions of this standard, a compatible client 
SHOULD send an "elliptic_curves" extension in client_hello, to indicate 
support of specific groups.

Server Behavior

When a DHE cipher suite is negotiated, a compatible server SHOULD always 
pick a FFDHE group for ServerDHParams, with a security bound greater 
than the minimum of the server certificate public key and the bulk 
encryption cipher of the negotiated cipher suite. The server SHOULD NOT 
negotiate a DHE cipher suite, unless it implements at least one FFDHE 
group with at least the corresponding security bound.

If an "elliptic_curve" extension is included in client_hello, the server 
MUST NOT negotiate a DHE cipher suite that would require the server to 
pick a FFDHE group not included in the "elliptic_curve" extension sent 
by the client. NOTE: Since FFDHE groups might be replaced or added in 
future revisions of this standard, this check MUST be performed 
regardless if the "elliptic_curve" extension does not include any 
identifiers the server recognizes as FFDHE identifiers.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Oct 2014 20:25:05 +0300

On Sat, Oct 25, 2014 at 06:45:51PM +0200, Henrick Hellström wrote:
> It seems to me the the recommended Client Behavior and Server Behavior has
> to be simplified and strengthened, in order for the standard to meet the
> security objectives.
> 
> All relevant attacks here https://secure-resumption.com/ seem to involve a
> MITM server that chooses bad ServerDHParams for the server key exchange
> message.

I see two problematic cases:
1) NG SKE gets presented as EC(!) SKE.
2) NG SKE gets presented to non-NG client.

1) The message is:

00 02 01 xx 00 01 00 <length of ge> <ge>

When interpretted as elliptic curve, this has curve type of 0, which is
not valid, so handshake can't work.

2) Here it might be a better idea to have group id in generator and have
modulus of 0, instead of generator 0 and modulus being group id.

This is to make buggy software more likely to blow up.

(after swapping the fields, the EC curve type is still 0).

16-bit prime does not make certain infamous TLS library reject the
handshake!

-Ilari

---

From: Henrick Hellström <[email-masked]>
Date: Sat, 25 Oct 2014 20:06:02 +0200

> not valid, so handshake can't work.

I think this should be of no consequence. A client that interprets a DHE 
SKE as an ECDHE SKE, despite having negotiated a DHE cipher suite, is 
broken beyond repair and would be pointless to try to be compatible with.

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Oct 2014 21:14:33 +0300

On Sat, Oct 25, 2014 at 08:06:02PM +0200, Henrick Hellström wrote:
> I think this should be of no consequence. A client that interprets a DHE SKE
> as an ECDHE SKE, despite having negotiated a DHE cipher suite, is broken
> beyond repair and would be pointless to try to be compatible with.

Unfortunately, attacker can make client interpret DHE SKE as ECDHE SKE
(or vice versa). TLS key exchange is just screwed up.

Oh, I also missed interpretting ECDHE SKE as posibly-NG DHE. This always
results in prime of length 256 or above. So if prime length is restricted for
NG DHE, these can't be confused with NG DHE.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sat, 25 Oct 2014 15:51:53 -0400 (EDT)

> has to be simplified and strengthened, in order for the standard to meet

Could you elaborate on which security objectives are you referring to?

> than checking a named group.
[...]
> insufficient_security alert if the parameters do not match.

What is the advantage of that proposal? It is more complex, and a security
protocol should strive for simplicity. I see three disadvantages:
1. More bytes to send in a handshake, especially since we are talking about
large groups (that also results to more memory used by implementations
that have to cache those messages until the handshake is finished).
2. Instead of simple maps to known parameters, checks are needed adding more 
space for errors.
3. There are known attacks against the current ServerKeyExchange format which
remain applicable if we go this path (a sufficiently long DH serverkeyexchange
message can be parsed as an ECDH serverkeyexchage).

Furthermore, I'd like to propose to further simplify the message for ServerDHParams
used by the draft, and convert it to a deliberately incompatible format with the 
ServerDHParams as well ServerECDHParams. That way it can be ensured ensure that there
cannot be any mitm taking advantage of the similarities.

regards,
Nikos

---

From: Watson Ladd <[email-masked]>
Date: Sat, 25 Oct 2014 12:55:58 -0700

> message can be parsed as an ECDH serverkeyexchage).

And 4: session_hash solves the same problem if I understand the
elements of it correctly, and we need it anyway because of this
ambiguity in parsing mentioned above. So do we even need this draft?

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Ilari Liusvaara <[email-masked]>
Date: Sat, 25 Oct 2014 23:16:42 +0300

> ambiguity in parsing mentioned above. So do we even need this draft?

AFAIK, no, it won't, at least not completely.

(TLS 1.3 has this problem fixed, even without session_hash[1]).

[1] Without session_hash TLS 1.3 is broken in other ways without DH
order check (and one can't rely on endpoints to perform such check
even if it is feasible, so session_hash is a good idea there too).

-Ilari

---

From: Watson Ladd <[email-masked]>
Date: Sat, 25 Oct 2014 14:36:09 -0700

> AFAIK, no, it won't, at least not completely.

I'm afraid I didn't realize how what I wrote would be read. It seems
to me that the session_hash doesn't necessarily fix the ambiguity
issue, but does ensure that sending bad groups will achieve nothing
for an attacker. Even if we adopt this draft for DHE, session_hash is
still needed in TLS 1.2. So what does this draft get us, assuming
session_hash is deployed?

---

From: Henrick Hellström <[email-masked]>
Date: Sat, 25 Oct 2014 23:53:07 +0200

Second paragraph of section 6.3 Arbitrary groups:

>    Note that in several known attacks against TLS and SSL
>    [SECURE-RESUMPTION] [CROSS-PROTOCOL] [SSL3-ANALYSIS], a malicious
>    server uses a deliberately broken FFDHE group to impersonate the
>    client to a different server."

> protocol should strive for simplicity.

In my view, the current draft leads to a lot more complex 
implementations, compared to my proposal.

You get complexity for two major reasons:
   * When adding new abilities in a manner that is not backwards 
compatible by design.
   * When balancing security requirements against interoperability 
requirements, without clear indications in the standards how these 
requirements should be balanced.

The problem a client faces, is that if it supports TLS 1.0 through TLS 
1.2, it will have to be prepared to deal with servers sending arbitrary 
FF DHE groups anyway. While I agree the ambiguity of the 
server_key_exchange message is a concern, implementing the draft-02 
doesn't resolve that ambiguity. Implementing TLS 1.3 and dropping 
support for older versions might be solution, but that is not going to 
happen any time soon.

Consequently, I would argue that a recommendation that ECDHE should only 
use named curves, and FF DHE only use standard groups encoded as 
arbitrary groups, would be closer to reality, lead to greater security 
at the expense of less interoperability issues, and make both server 
implementations and client implementations (that require backwards 
compatibility with older peers) *less* complex.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 26 Oct 2014 03:09:33 -0400 (EDT)

----- Original Message -----
> implementations, compared to my proposal.

Ok, I now understand your point. You suggest using the extension but then keeping
the exact same server key exchange message. That was the initial approach of the
draft if I remember well. 

To be honest I don't see that to be a lot more complex, and the complexity
on the same level as supporting ECDH with named groups and arbitrary groups,
which was deemed reasonable for ECDH. Consistency (with ECDH) is also another
reason to keep the code paths separated.

Note also, that the current approach will simplify a lot an implementation that
doesn't want to keep the old DHE key exchange with arbitrary groups (and unlike
the other key exchanges in TLS, DHE was the most problematic compatibility-wise so
I guess many small implementations would be more than happy to drop it).

regards,
Nikos

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Sun, 26 Oct 2014 03:14:08 -0400 (EDT)

----- Original Message -----
> session_hash is deployed?

I think it is a bit unproductive to comment without reading the actual
draft. The issue it solves is unrelated to session hash. It is described
in its introduction at
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe-02#section-1

"Traditional TLS [RFC5246] offers a Diffie-Hellman ephemeral (DHE) key
   exchange mode which provides Perfect Forward Secrecy for the
   connection.  The client offers a ciphersuite in the ClientHello that
   includes DHE, and the server offers the client group parameters g and
   p.  If the client does not consider the group strong enough (e.g. if
   p is too small, or if p is not prime, or there are small subgroups),
   or if it is unable to process it for other reasons, it has no
   recourse but to terminate the connection ..."

regards,
Nikos

---

From: Henrick Hellström <[email-masked]>
Date: Sun, 26 Oct 2014 09:11:09 +0100

> reason to keep the code paths separated.

No, ECDHE is different, because you can't implement RFC 4492 (EC cipher 
suites) fully, unless your implementation supports the hello extensions 
and curve negotiation mechanism, and there exists clients that don't 
support arbitrary explicit curves. In the case of DHE, most clients will 
probably only support explicit groups and not support the extension and 
named groups at all, for several years ahead.

Consequently, a server that e.g. only implements secp256r1 encoded as a 
named curve, would stand a fair chance of being interoperable, if it 
simply refuses to negotiate ECDHE cipher suites unless the client sends 
a supported curve extension with this one included. A server that only 
wants to negotiate the FFDHE 3072 bit group could easily encode it as an 
arbitrary group if the client doesn't send the extension (which would 
still happen most of the time), but if the client *does* send the 
extension, then, under the current draft-02, the server would have to 
propagate this information to the server key exchange encoder somehow 
(be it with maps, switches or if-clauses).

> I guess many small implementations would be more than happy to drop it).

I don't know about compatibility issues, but rather see a security issue 
that SSL 3.0 up to TLS 1.2 didn't explicitly require the DHE parameters 
to have a bit size greater than or equal to the certificate public key. 
I don't know how common it is for clients that offer DHE cipher suites 
to be able to use the server certificate key for signature verification, 
but unable to compute a DHE handshake using integers of a comparable 
size. I doesn't seem reasonable to expect this to be a problem of such 
magnitude, that the standards should keep an acceptance for low(er) 
security (than necessary) in order to keep interoperability with such 
clients.

---

From: Henrick Hellström <[email-masked]>
Date: Mon, 27 Oct 2014 09:46:58 +0100

Another thing about this rule:

>    A compatible TLS server that receives the NamedCurve extension with
>    FFDHE codepoints in it, and which selects an FFDHE ciphersuite MUST
>    select one of the offered groups and indicates the choice of groups
>    to the client by sending a specially-formatted ServerDHParams as
>    described below.

Suppose a client offers both ECDHE and FFDHE cipher suites, and does 
send the NamedCurve extension, but with no identifiers the server 
recognizes as FFDHE groups, but with a few identifiers the server 
doesn't recognize at all.

How is the server supposed to tell if:
   1. The client doesn't support named FFDHE groups at all and expects 
the arbitrary encoding of FFDHE server key exchange messages, or
   2. The client supports only a few named FFDHE groups defined in a 
later revision of the standard that the server hasn't yet implemented, 
meaning the server ideally MUST NOT use the arbitrary encoding of FFDHE 
groups, but rather pick other cipher suites?

This is a dilemma that implementors might decide to circumvent in 
complex and undesirable ways.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 27 Oct 2014 11:25:51 +0100

> the arbitrary encoding of FFDHE server key exchange messages, or

All the server needs to know is the common FFDHE groups they support.
And that it apparent in that case. None.

If they have no common groups the server SHOULD NOT negotiate DHE
according to the current draft, so no dilemma here.

> groups, but rather pick other cipher suites?

I think the situation is similar as above. The intersection of the
supported FFDHE groups is empty, thus according to the
draft-ietf-tls-negotiated-ff-dhe a compliant server should not select
the DHE ciphersuites at all. If he selected DHE ciphersuites, it is a
legacy server that doesn't support the draft. So for the server, the
decisions are straightforward as far as I understand.

A client though will have to decide on whether a legacy server is seen,
or a compliant to ffdhe draft, based on the format of ServerKeyExchange.
That's why I suggested to make them sufficiently distinct.

regards,
Nikos

---

From: Henrick Hellström <[email-masked]>
Date: Mon, 27 Oct 2014 11:58:18 +0100

> according to the current draft, so no dilemma here.

That is NOT what the draft says. The draft does NOT prohibit the server 
to negotiate an FFDHE cipher suite, when negotiating with a 
non-compatible client. All the draft says is that the server shouldn't 
send specially formatted server_key_exchange messages to non-compatible 
clients, which makes sense.-

> I think the situation is similar as above.

Perhaps I wasn't clear. This isn't a second situation. It is just a 
second way the server might interpret the SAME ambiguous situation.

> That's why I suggested to make them sufficiently distinct.

FWIW, the real problem here is RFC 4492. There was no ambiguity in TLS 
1.0, because the ServerKeyExchange could only contain two kinds of 
messages, one with two large integers (a ServerRSAParams) or one with 
three large integers (a ServerDHParams). RFC 4492 introduced the 
ambiguity. Can anyone think of a way to fix it, without forcing Named 
FFDHE compatible servers to negotiate RSA cipher suites instead of DHE 
cipher suites with legacy clients? Is that even a good idea? (That was a 
rhetorical question.)

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 27 Oct 2014 12:07:00 +0100

On Mon, 2014-10-27 at 11:58 +0100, Henrick Hellström wrote:
> non-compatible client.

We may be referring to different versions of the draft. The current
draft says:
"If the extension is present, none of the client's offered groups are
   acceptable by the server, and none of the client's proposed non-FFDHE
   ciphersuites are acceptable to the server, the server SHOULD end the
   connection with a fatal TLS alert of type insufficient_security."

This does explicitly prohibit the server to negotiate an FFDHE cipher
suite if the extension is present.

> cipher suites with legacy clients? Is that even a good idea? (That was a 

A way to fix that for the ffdhe draft would be to introduce a two-byte
type that is on purpose large (eg. values like 0xff 0xfa).

regards,
Nikos

---

From: Henrick Hellström <[email-masked]>
Date: Mon, 27 Oct 2014 12:37:01 +0100

> suite if the extension is present.

OK, I stand corrected, I didn't interpret that paragraph that way. It 
starts with

>    If a compatible TLS server receives a NamedCurves extension from a
>    client that includes any FFDHE groups

...so I interpreted the whole paragraph as referring to extensions the 
server is able to recognize as including BOTH named elliptic curves AND 
named ffdhe groups. If it really says that a Named FFDHE compatible 
server MUST NOT negotiate DHE cipher suites with clients that implement 
RFC 4492, but not the Named FFDHE standard, that should be stated 
explicitly.

It does however strike me as odd that, as a consequence, a named FFDHE 
compatible server, would still be allowed to negotiate DHE cipher suites 
with legacy clients that do not even implement RFC 4492, but not with 
legacy clients that implement DHE in the exact same way, but also 
support a few weak elliptic curves.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 27 Oct 2014 14:10:12 +0200

> type that is on purpose large (eg. values like 0xff 0xfa).

Basically, you want to:
1) ECDHE SKE to not be interpretable as FFDHE SKE.
2) FFDHE SKE to blow up when interpretted as ECDHE SKE.
3) FFDHE SKE to blow up when interpretted as DHE SKE (including legacy software).

If the first byte of FFDHE SKE has to be 00, that takes care of 1) and 2),
because first byte of ECDHE SKE is the curve type, and curve type 0 is
not valid.

3) Is nastier issue. AFAICT, with such misinterpretation, not even session_hash
will save you.

One way (not necressarily good) would be to encode ServerDHParams as
00 01 00 NOT(grpid). If one tries to parse this as DHE, one gets p=0 and length
of g being ~65,000 bytes (pretty certainly overflowing the message).

-Ilari

---

From: Henrick Hellström <[email-masked]>
Date: Mon, 27 Oct 2014 13:52:49 +0100

> of g being ~65,000 bytes (pretty certainly overflowing the message).

IMHO, a much better (and fully backwards compatible) way would be to 
deprecate the two explicit ECCurveTypes. A named_curve will start with 
03 xx xx  <1..2^8-1>, which cannot be parsed as legacy DHE without 
overflowing into the signature section and making the verification fail. 
Conversely, legacy DHE would have to contain a dh_p that is at least 
6144 bits in order for the ServerDHParams to start with 03, which would 
make it impossible for the signature to start at the right position for 
it to be verified by the ServerECDHParams parser.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 27 Oct 2014 14:20:43 -0400

> support a few weak elliptic curves.

hm, yes, i agree that this is a bad outcome, and as of -02 that does
appear to be the consequence of the draft.  Thanks for pointing this
out, Henrick.

To be clear, i think the problem is:

 * a compatible server might see a client send a DHE ciphersuite and the
   NamedCurves extension, but with at least one identified NamedCurve
   that the server doesn't know.

 * In this case, the server cannot distinguish the following two peers:

    A) the client implements this draft, but only implements an unusual
       FFDHE that the server has never heard of.

    B) the client does not implement with this draft and happens to
       implement an elliptic curve that the server has never heard of.

 * The right logic here is that the server SHOULD NOT select DHE for
   client A, but MAY select DHE for client B, as when interoperating
   with any other legacy client implementation.  But the server can't
   distinguish between these cases.

I think there needs to be explicit signalling from the client that it
understands known FFDHE groups, so that a server can distinguish between
these cases.

I see three ways to achieve this goal:

 0) reintroduce an explicit (contentless) ClientHello extension that
    means "i understand FFDHE named groups"

 1) allocate a single codepoint in the named groups registry that means
    "i understand FFDHE named groups" but is not a negotiable group

 2) carve out a range of codepoints in the named groups registry that
    will be used only for FFDHE named groups (and no other codepoints in
    that registry will have FFDHE).  This way, servers can recognize a
    named FFDHE group, even if they don't know what it is.

(0) seems like a simple approach, though it introduces a bit of redundancy
that could cause weirdness -- what does it mean if the ClientHello
extension is not present, but an FFDHE group exists in the NamedCurves
extension, for example?

(1) smells a lot like the SCSV approach we've been trying (and failing)
to avoid using in other contexts, though it happens in NamedCurves,
instead of in the ciphersuite list.  I'd really rather avoid this kind
of hackery.

(2) seems like it might be the simplest approach.  For example, if the
value is within [256,287]) then the NamedCurve is FFDHE.  This wouldn't
be the first time that an IANA registry had range registration
procedures like this, see e.g.  ARP Hardware Types:

https://www.iana.org/assignments/arp-parameters/arp-parameters.xhtml#arp-parameters-2

It does place a smaller permanent cap on the number of FFDHE groups we
might ever name, but i don't think a limit of 32 FFDHE groups (as in the
proposed range above) is particularly troubling.  I expect we want
fewer, stronger groups, not more.

Any thoughts or preferences?

        --dkg

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 27 Oct 2014 18:30:00 +0000

>     named FFDHE group, even if they don't know what it is.

For completeness:

   3)  Like 0), but not contentless.  The extension lists the
       supported FFDHE groups.  The existing supported curves
       extension continues to only signal elliptic curves.

[ Perhaps I missed the discussion where this was already suggested and
  ruled out.  Sorry about that... ]

-- 
	Viktor.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 29 Oct 2014 09:57:18 +0100

>    distinguish between these cases.

I wouldn't distinguish between these two cases. If the goal is to
promote interoperability, the DHE ciphersuites should not be negotiated
by a compliant server if there are no curves advertised by the client.

Otherwise in client B case, if the server proceeds with negotiating DHE,
the issue that the draft tries to solve reappears, i.e., a broken
session because the DH parameters presented to client for some reason
are not acceptable by the client (e.g., a java client which only
supports 1024-bit parameters).

> I see three ways to achieve this goal:

I'd add that:
3) Keep the currently defined behavior (i.e., prefer any other
ciphersuite to DHE if the peers share no common groups).

regards,
Nikos

---

From: Hubert Kario <[email-masked]>
Date: Wed, 29 Oct 2014 12:16:01 +0100

On Sunday 26 October 2014 09:11:09 Henrick Hellström wrote:
> > Note also, that the current approach will simplify a lot an implementation
> > that doesn't want to keep the old DHE key exchange with arbitrary groups
> > (and unlike the other key exchanges in TLS, DHE was the most problematic
> > compatibility-wise so I guess many small implementations would be more
> > than happy to drop it).
> 

That's the case for nearly all implementations of Java. JRE before 1.7 support 
at most 1024 bit DHE, while will support 2048 or 3072 bit RSA just fine.
1.8 only increased the limit to (IIRC) 2048 bit for DHE.

-- 
Regards,
Hubert Kario