I see what's going on here. When Firefox constructs the `supported_versions` extension for the DTLS1.3 CH, the alternate versions (DTLS 1.2 and 1.1) do not have their encodings converted for DTLS. I.e., we advertise {0x7f1e, 0x0303, 0x0302} when we should instead advertise {0x7f1e, 0xfefd, 0xfeff}. BoringSSL doesn't find any known DTLS versions in the first list, and alerts. I've confirmed the handshake works as expected with this change.
Moving this bug into NSS.
Bug 1615208 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.
I see what's going on here. As you suggest, when Firefox constructs the `supported_versions` extension for the DTLS1.3 CH, the alternate versions (DTLS 1.2 and 1.1) do not have their encodings converted for DTLS. I.e., we advertise {0x7f1e, 0x0303, 0x0302} when we should instead advertise {0x7f1e, 0xfefd, 0xfeff}. BoringSSL doesn't find any known DTLS versions in the first list, and alerts. I've confirmed the handshake works as expected with this change.
Moving this bug into NSS.
I see what's going on here. As you suggest, when Firefox constructs the `supported_versions` extension for the DTLS1.3 CH, the alternate versions (DTLS 1.2 and 1.0) do not have their encodings converted for DTLS. I.e., we advertise {0x7f1e, 0x0303, 0x0302} when we should instead advertise {0x7f1e, 0xfefd, 0xfeff}. BoringSSL doesn't find any known DTLS versions in the first list, and alerts. I've confirmed the handshake works as expected with this change.
Moving this bug into NSS.