On Sun, Sep 20, 2015 at 7:59 PM, William Whyte < wwh...@securityinnovation.com> wrote:
> Hi all, > > We've updated the TLS 1.3 Quantum Safe Handshake draft to use extensions > as suggested by DKG in Prague. All comments welcome. > > There's an interesting issue here: McEliece keys, which should be > permissible, are larger in size (about 2^20 bytes) than the maximum > permissible extension size (2^16-1). In order to support McEliece keys it > might be worth increasing the maximum extension size to 2^24-1 for TLS 1.3. > Is there a strong reason for keeping the maximum size at 2^24-1, other than > saving one byte on all the relevant length fields? > William, I suggest you first do an experiment: Create a TLS client that contains all the stuff a browser puts in its TLS handshake. Then, add your new a maximally-sized (2^16-1 bytes) extension, but don't otherwise change the client. What percentage of handshakes fail? I suspect that a huge percentage of the handshakes will fail. First, some implementations won't accept a ClientHello larger than 1KB (IIRC) due to artificial limit imposed presumably as a DoS measure. Secondly, I suspect many implementation will fail to handle a ClientHello that is split across multiple records. Keep in mind that since the maximum record size is less than the maximum extension size, a ClientHello with a maximally-sized extension must require more than one record to be encoded. In general, I would expect most implementations don't want to receive a 1MB message of any sort unless they've advertised that they want such messages. So, a different design that doesn't require including a huge extension in the initial ClientHello would probably be better. Cheers, Brian -- https://briansmith.org/
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
