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

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

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