(In reply to Nils Ohlmeier [:drno] from comment #5) > Kevin just to make sure I understand the impact here: > The problem is that if we enable DTLS 1.3 in Fx it adds supported_version to it's client hello, which then gets rejected by Fx DTLS server because it misinterprets the version numbers in there? > Currently we can't establish connections with older versions of Firefox, because of this problem, right? The interop problem is now between pre-1615208 and post-1615208 versions, even though that patch itself was correct. There are two issues at play: 1) Prior to the patch for bug 1615208, NSS (and Firefox) were sending *and expecting* TLS version numbers in the `supported_versions` extension of the DTLS 1.3 client hello. This is wrong and sending DTLS version numbers corrected the Chrome interop issue. 2) NSS attempts to negotiate through the `supported_versions` extension even if DTLS and/or TLS 1.3 are disabled. This is somewhat unexpected, since `supported_versions` was introduced in TLS 1.3. Older versions of Firefox (with DTLS 1.3 disabled) are still trying to negotiate incorrectly from `supported_versions`. Without sending both TLS and DTLS versions in 75+, we'd have to patch old versions of Firefox to ignore `supported_versions` when (D)TLS 1.3 is disabled. > > How come that Chrome is now fine with Fx advertising 1.3, but Fx can't handle it? Bug 1615208 fixed the issue of sending wrong versions in a DTLS 1.3 ClientHello. Old versions of Fx still expect the wrong version numbers. > Would it be possible to create a patch for Fx Beta, which makes it stop aborting because of the "wrong protocol" version? Or maybe that will even > happen automatically once 75 becomes Beta? Not easily since this is low-level code in the TLS stack, and applies to all prior versions of NSS.
Bug 1619102 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Nils Ohlmeier [:drno] from comment #5) > Kevin just to make sure I understand the impact here: > The problem is that if we enable DTLS 1.3 in Fx it adds supported_version to it's client hello, which then gets rejected by Fx DTLS server because it misinterprets the version numbers in there? > Currently we can't establish connections with older versions of Firefox, because of this problem, right? The interop problem is now between pre-1615208 and post-1615208 versions, even though that patch itself was correct. There are two issues at play: 1) Prior to the patch for bug 1615208, NSS (and Firefox) were sending *and expecting* TLS version numbers in the `supported_versions` extension of the DTLS 1.3 client hello. This is wrong and sending DTLS version numbers corrected the Chrome interop issue. 2) NSS attempts to negotiate through the `supported_versions` extension even if DTLS and/or TLS 1.3 are disabled (if it is present). This is somewhat unexpected, since `supported_versions` was introduced in TLS 1.3. Older versions of Firefox (with DTLS 1.3 disabled) are still trying to negotiate incorrectly from `supported_versions`. Without sending both TLS and DTLS versions in 75+, we'd have to patch old versions of Firefox to ignore `supported_versions` when (D)TLS 1.3 is disabled. > > How come that Chrome is now fine with Fx advertising 1.3, but Fx can't handle it? Bug 1615208 fixed the issue of sending wrong versions in a DTLS 1.3 ClientHello. Old versions of Fx still expect the wrong version numbers. > Would it be possible to create a patch for Fx Beta, which makes it stop aborting because of the "wrong protocol" version? Or maybe that will even > happen automatically once 75 becomes Beta? Not easily since this is low-level code in the TLS stack, and applies to all prior versions of NSS.
(In reply to Nils Ohlmeier [:drno] from comment #5) > Kevin just to make sure I understand the impact here: > The problem is that if we enable DTLS 1.3 in Fx it adds supported_version to it's client hello, which then gets rejected by Fx DTLS server because it misinterprets the version numbers in there? > Currently we can't establish connections with older versions of Firefox, because of this problem, right? Correct - it gets rejected by an old (pre-75) Fx DTLS server. The interop problem is between pre-1615208 and post-1615208 versions, even though that patch itself was correct. There are two issues at play: 1) Prior to the patch for bug 1615208, NSS (and Firefox) were sending *and expecting* TLS version numbers in the `supported_versions` extension of the DTLS 1.3 client hello. This is wrong and sending DTLS version numbers corrected the Chrome interop issue. 2) NSS attempts to negotiate through the `supported_versions` extension even if DTLS and/or TLS 1.3 are disabled (if it is present). This is somewhat unexpected, since `supported_versions` was introduced in TLS 1.3. Older versions of Firefox (with DTLS 1.3 disabled) are still trying to negotiate incorrectly from `supported_versions`. Without sending both TLS and DTLS versions in 75+, we'd have to patch old versions of Firefox to ignore `supported_versions` when (D)TLS 1.3 is disabled. > > How come that Chrome is now fine with Fx advertising 1.3, but Fx can't handle it? Bug 1615208 fixed the issue of sending wrong versions in a DTLS 1.3 ClientHello. Old versions of Fx still expect the wrong version numbers. > Would it be possible to create a patch for Fx Beta, which makes it stop aborting because of the "wrong protocol" version? Or maybe that will even > happen automatically once 75 becomes Beta? Not easily since this is low-level code in the TLS stack, and applies to all prior versions of NSS.
(In reply to Nils Ohlmeier [:drno] from comment #5) > Kevin just to make sure I understand the impact here: > The problem is that if we enable DTLS 1.3 in Fx it adds supported_version to it's client hello, which then gets rejected by Fx DTLS server because it misinterprets the version numbers in there? > Currently we can't establish connections with older versions of Firefox, because of this problem, right? Correct - it gets rejected by an old (pre-75) Fx DTLS server. The interop problem is between pre-1615208 and post-1615208 versions, even though that patch itself was correct. There are two issues at play: 1) Prior to the patch for bug 1615208, NSS (and Firefox) were sending *and expecting* TLS version numbers in the `supported_versions` extension of the DTLS 1.3 client hello. This is wrong and sending DTLS version numbers corrected the Chrome interop issue. 2) NSS attempts to negotiate through the `supported_versions` extension even if DTLS and/or TLS 1.3 are disabled (if it is present). This is somewhat unexpected, since `supported_versions` was introduced in TLS 1.3. Older versions of Firefox (with DTLS 1.3 disabled) are still trying to negotiate incorrectly from `supported_versions`. Without sending both TLS and DTLS versions in 75+, we'd have to patch old versions of Firefox to ignore `supported_versions` when (D)TLS 1.3 is disabled. > > How come that Chrome is now fine with Fx advertising 1.3, but Fx can't handle it? Bug 1615208 fixed the issue of sending wrong versions in a DTLS 1.3 ClientHello. Old versions of Fx still expect the wrong version numbers. > Would it be possible to create a patch for Fx Beta, which makes it stop aborting because of the "wrong protocol" version? Or maybe that will even > happen automatically once 75 becomes Beta? Not easily since this is low-level code in the TLS stack, and applies to all prior TLS1.3-comprehending versions of NSS.
(In reply to Nils Ohlmeier [:drno] from comment #5) > Kevin just to make sure I understand the impact here: > The problem is that if we enable DTLS 1.3 in Fx it adds supported_version to it's client hello, which then gets rejected by Fx DTLS server because it misinterprets the version numbers in there? > Currently we can't establish connections with older versions of Firefox, because of this problem, right? Correct - it gets rejected by an old (pre-75) Fx DTLS server. The interop problem is between pre-1615208 and post-1615208 versions, even though that patch itself was correct. There are two issues at play: 1) Prior to the patch for bug 1615208, NSS (and Firefox) were sending *and expecting* TLS version numbers in the `supported_versions` extension of the DTLS 1.3 client hello. This is wrong and sending DTLS version numbers corrected the Chrome interop issue. 2) NSS attempts to negotiate through the `supported_versions` extension even if DTLS and/or TLS 1.3 are disabled (if it is present). This is somewhat unexpected, since `supported_versions` was introduced in TLS 1.3. Older versions of Firefox (with DTLS 1.3 disabled) are still trying to negotiate incorrectly from `supported_versions`. Without sending both TLS and DTLS versions in 75+, we'd have to patch old versions of Firefox to ignore `supported_versions` when (D)TLS 1.3 is disabled. > > How come that Chrome is now fine with Fx advertising 1.3, but Fx can't handle it? Bug 1615208 fixed the issue of sending wrong versions in a DTLS 1.3 ClientHello. Old versions of Fx process the `supported_versions` extension (which only DTLS 1.3 sends) and expect it to hold the wrong version numbers. > Would it be possible to create a patch for Fx Beta, which makes it stop aborting because of the "wrong protocol" version? Or maybe that will even > happen automatically once 75 becomes Beta? Not easily since this is low-level code in the TLS stack, and applies to all prior TLS1.3-comprehending versions of NSS.
(In reply to Nils Ohlmeier [:drno] from comment #5) > Kevin just to make sure I understand the impact here: > The problem is that if we enable DTLS 1.3 in Fx it adds supported_version to it's client hello, which then gets rejected by Fx DTLS server because it misinterprets the version numbers in there? > Currently we can't establish connections with older versions of Firefox, because of this problem, right? Correct - it gets rejected by an old (pre-75) Fx DTLS server. The interop problem is between pre-1615208 and post-1615208 versions, even though that patch itself was correct. There are two issues at play: 1) Prior to the patch for bug 1615208, NSS (and Firefox) were sending *and expecting* TLS version numbers in the `supported_versions` extension of the DTLS 1.3 client hello. This is wrong and sending DTLS version numbers corrected the Chrome interop issue. 2) NSS attempts to negotiate through the `supported_versions` extension even if DTLS and/or TLS 1.3 are disabled (if it is present). This is somewhat unexpected, since `supported_versions` was introduced in TLS 1.3. > > How come that Chrome is now fine with Fx advertising 1.3, but Fx can't handle it? Bug 1615208 fixed the issue of sending wrong versions in a DTLS 1.3 ClientHello. Old versions of Fx process the `supported_versions` extension (which only DTLS 1.3 sends) and expect it to hold the wrong version numbers. > Would it be possible to create a patch for Fx Beta, which makes it stop aborting because of the "wrong protocol" version? Or maybe that will even > happen automatically once 75 becomes Beta? Not easily since this is low-level code in the TLS stack, and applies to all prior TLS1.3-comprehending versions of NSS.