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 <cry...@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 <cry...@brainhub.org > > <mailto:cry...@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
