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