Subject: [TLS] Negotiated Finite Field Diffie-Hellman shared secret calculation

From: Andrey Jivsov <[email-masked]>
Date: Tue, 19 Feb 2019 16:10:24 -0800

Greetings.

it's unclear to me how is the shared secret g^xy calculated for groups
in https://tools.ietf.org/html/rfc7919 .

If you recall, the TLS 1.1 uses this method the
https://tools.ietf.org/html/rfc4346#section-8.1.2 , causing some
interoperability problems that are hard to fix.

The RFC 7919 doesn't specify what to do here.

So, the question is, assuming that ffdhe2048 is negotiated,

- is g^xy padded to 256 bytes (more sound method) or
- the leading zero bytes of g^xy must be stripped (legacy method, used
for historic reasons)?

Thank you.

---

From: David Benjamin <[email-masked]>
Date: Wed, 20 Feb 2019 12:29:09 -0600

(We haven't actually implemented RFC 7919 and have no plans to, so I'm just
going by the document.)

RFC 7919 doesn't say anything, so I think the only reasonable
interpretation is to continue with the legacy option for TLS 1.2 and below.
It's also the only interoperable option given how the document is set up.
RFC 7919 repurposed the existing DHE scheme with no directly visible server
differences, so the client cannot tell if it is talking to a post-7919
server, or a pre-7919 server that happened to use a well-known parameter.
That means 7919 cannot change how DHE works. (This isn't the only
consequence of that decision. See
https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo. DHE
in TLS 1.2 is a mess and RFC 7919 failed to repair it.)

Note all this only applies to TLS 1.2. TLS 1.3 is free to use the more
sound method and does:
https://tools.ietf.org/html/rfc8446#section-7.4.1

On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov <[email-masked]> wrote:

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

---

From: Andrey Jivsov <[email-masked]>
Date: Wed, 20 Feb 2019 10:48:42 -0800

Why isn't the

"The server indicates
the choice of group to the client by sending the group's parameters
as usual in the ServerKeyExchange"
https://tools.ietf.org/html/rfc7919#section-4

an evidence that the server supports RFC 7919?

On 2/20/19 10:29 AM, David Benjamin wrote:
> (We haven't actually implemented RFC 7919 and have no plans to, so I'm
> just going by the document.)
> 
> interpretation is to continue with the legacy option for TLS 1.2 and
> below. It's also the only interoperable option given how the document is
> set up. RFC 7919 repurposed the existing DHE scheme with no directly
> visible server differences, so the client cannot tell if it is talking
> to a post-7919 server, or a pre-7919 server that happened to use a
> well-known parameter. That means 7919 cannot change how DHE works. (This
> isn't the only consequence of that decision.
> See https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo.
> DHE in TLS 1.2 is a mess and RFC 7919 failed to repair it.)
> 
> On Tue, Feb 19, 2019 at 6:10 PM Andrey Jivsov <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Greetings.
> 
>     [email-masked] <mailto:[email-masked]>

---

From: David Benjamin <[email-masked]>
Date: Wed, 20 Feb 2019 13:08:09 -0600

It is some evidence, but the server may have been configured with that
group anyway. Regardless, the specification doesn't say anything, so I
think the only reasonable interpretation is the existing TLS 1.2 mechanism,
sadly.

On Wed, Feb 20, 2019 at 12:48 PM Andrey Jivsov <[email-masked]> wrote:

> > See
> https://mailarchive.ietf.org/arch/msg/tls/bAOJD281iGc2HuEVq0uUlpYL2Mo.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Feb 2019 16:24:06 -0500

What David said.

We implement 7919, which includes an option to only accept server shares from the 7919 groups.  With that option a simple comparison is used to determine if the group is one from the spec, rejecting all else, but we otherwise just treat the share as normal.  I'm not aware of anyone seriously using it though, so the usual concerns about it's use in TLS 1.2 remain.

--Martin

On Wed, Feb 20, 2019, at 11:08, David Benjamin wrote:
> think the only reasonable interpretation is the existing TLS 1..2 
> mechanism, sadly.
>

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 21 Feb 2019 00:16:54 +0000

Martin Thomson <[email-masked]> writes:

>We implement 7919, which includes an option to only accept server shares from
>the 7919 groups.  With that option a simple comparison is used to determine if
>the group is one from the spec, rejecting all else, but we otherwise just
>treat the share as normal. 

My code fast-paths known-good primes, for example the RFC 3526 ones, and only
does full checking on unknown ones (that is, it recognises things like the
3526 primes in the hello and uses its built-in values for them).  I don't do
7919 for the same reason that most other implementations don't, although I've
been thinking about adding the 7919 primes to the known-good set.

(A side-note about the 3526 values, they've been independently verified
outside of their publication in the RFC, has anyone done this for the 7919
ones?  Not saying they're suspicious, but it'd be good to get independent
verification that the data values match what's described in the RFC).

>I'm not aware of anyone seriously using it though, 

That's a weird thing about 7919, throughout the draft process lots of people
pointed out, again and again, that it wasn't going to work if published in
that form.  So it got published anyway...

Peter.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 21 Feb 2019 21:17:02 -0500

> verification that the data values match what's described in the RFC).

i'd welcome any additional double-checks.  iirc, at the time of
publication, Tero Kivinen checked them independently, but i'd welcome
any additional checks people want to do.

I also published primality proofs (via primo) of the groups here:

 https://dkg.fifthhorseman.net/ffdhe-primality-proofs/

> that form.  So it got published anyway...

i agree that it would have been functionally stronger to define
ciphersuite values that identify the use of named FFDHE groups.  This
would allow clients to signal to servers that they will *only* accept
DHE if the server uses the named groups, and would avoid getting DHE
handshakes from non-compliant servers.

However, the mechanism is still useful as-is for clients that want to
signal their preference for a known group to a cooperating server.  This
is still useful in a world where some clients were failing to accept
server-offered DHE shares > 1024-bits (sigh, Java).

IIRC, the sense at the time was also that codepoints were scarce
resources, and replicating all the _DHE_RSA_ ciphersuites alone would
consume another 25 codepoints (replicating all of the _DHE_ ciphersuites
would consume 70 additional ones), and then it would also require
haggling over how the handshake messages would differ from the standard
in those variants, which might then increase implementation complexity.
Too bad!

At any rate, it turned out to be useful preparation for TLS 1.3, though
i presume today the named DHE groups will really only come in handy in
case ECDHE turns out to have some kind of serious cryptanalytic setback.

   --dkg, the guilty party