Boris Pismenny <borispisme...@gmail.com> 于2023年3月2日周四 18:43写道：
> > On Tue, Feb 28, 2023 at 2:18 PM Lanlan Pan <abby...@gmail.com> wrote: > >> Personally I think, the negotiation may cause the downgrade security >> risk, making PNE not actually work for privacy protection. >> The hardware acceleration can support both PNE and plaintext packet >> number. >> Maybe we can consider assigning a new port, just for plaintext packet >> number's QUIC/DTLS ? >> such as : >> port 80: plain text, http >> port 443: QUIC with PNE/TLS, by default. >> port 886: QUIC with plaintext packet number, only used on specific >> environments. >> port 4433: DTLS with PNE, by default. >> port 8866: DTLS with plaintext packet number, only used on specific >> environments. >> >>> >>> > Thanks for proposing this. > > Multiplexing at the transport layer would work, and I don't mind going > that route. > But I'm not sure if that's so much different from negotiating in-band > given that > the default configuration is to disallow plaintext packet numbers. > Thanks Boris. My concern is, negotiating in-band, may make us hard to prevent the abuse of "NO PNE" configuration. > Moreover, DTLS1.2 and DTLS1.3 use the same port while providing different > guarantees related to PNE, so using this logic suggests that DTLS1.2 should > run on a different port too?! > The logic is, the default port 4433 follows default DTLS specification, no change. DTLS1.2 runs at 4433, no change.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
