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

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