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

(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 <crypto@brainhub.org> wrote:

> 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.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>