Subject: draft-ietf-quic-tls 23 - Sample initial packet protection

From: gag83 E <[email-masked]>
Date: Mon, 23 Sep 2019 14:34:38 +0200

Hello,

Still working on a QUIC implementation in Scapy, I tried to use the packet
given in the appendix A of the draft-ietf-quic-tls-23 for my test with the
existing implementations of QUIC. I realized that the packet didn't meet
some requirements :
In §8.2 : "The quic_transport_parameters extension is carried in the
ClientHello and the EncryptedExtensions messages during the handshake.
Endpoints MUST send the quic_transport_parameters extension; endpoints
that receive
ClientHello or EncryptedExtensions messages without the
quic_transport_parameters
extension MUST close the connection with an error of type 0x16d (equivalent
to a fatal TLS missing_extension alert, see [
https://tools.ietf.org/html/draft-ietf-quic-tls-23#section-4.8 | Section
4.8 ] )."

or the packet doesn't carry this extension.

Moreover, there is no ALPN extension, which implied a connection error with
some servers.

I built the same packet with these extensions, which gave me for the
unprotected packet :

 06004103010000ff030300000000a0f7347c18f937001c8ea4f59c0b7aa3e1017dd24a35c6210b1448fd000006130113031302010000d00000000b0009000006736572766572ff01000100000a00140012001d0017001800190100010101020103010400230000003300260024001d00204cfdfcd178b784bf328cae793b136f2aedce005ff183d7bb14952072366470370010000800060568332d3232002b0003020304000d0020001e040305030603020308040805080604010501060102010402050206020202002d00020101001c00024001ffa5002f002d00050004800040000007000480004000000400048000800000080001010009000103000100026710000e000104

and for the protected packet :

c4ff000017088394c8f03e5157080000449e725753ce53506563268a0da27b1cfb452cfc0ca6d8ae6d86b8fbd4ffeb62f858c3ab3686bd0ab958498e8128266b4daac473e68d7405fbba4e9ea716c87038bdbe908c06d9605d9ac49030359eecb1d05a14e117db8cede2bb09d0dbbfee271cb374d8f10abec82d0f59a1dee29fe95638ed8dd41da07487468791b719c55c46968eb3b54680037102a28e53dc1d12903db0af5821797041cfab36569267e37bfdf9d9befc639be87a6f6c63e9cd1dc1bbf518f13be9c1061f7b2171d05010d0e7176a4075f56d5f1a0f42334b7d1c8dd523bd879ada5d65c485daa6ca2825d74d2f942001cae0a8205412e470080cdc559a24c546e4fa3766092a7d393e53cd0163baab3f432b05bc2ac385681fcf37485dff6595e01e739c8ac9efba31b985d5f656cc092432d781db9522172487641c4d3ab8ece01e39bc85b15436614775a98ba8fa12d46f9b35e2a55eb72d7f85181a366663387ddc20551807e007673bd7e26bf9b29b5ab10a1ca87cbb7ad97e99eb66959c2a9bc3cbde4707ff7720b110fa95354674e395812e47a0ae53b464dcb2d1f345df360dc227270c750676f6724eb479f0d2fbb6124429990457ac6c9167f40aab739998f38b9eccb24fd47c8410131bf65a52af841275d5b3d1880b197df2b5dea3e6de56ebce3ffb6e9277a82082f8d9677a6767089b671ebd244c214f0bde95c2beb02cd1172d58bdf39dce56ff68eb35ab39b49b4eac7c815ea60451d6e6ab82119118df02a586844a9ffe162ba006d0669ef57668cab38b62f71a2523a084852cd1d079b3658dc2f3e87949b550bab3e177cfc49ed190dff0630e43077c30de8f6ae081537f1e83da537da980afa668e7b7fb25301cf741524be3c49884b42821f17552fbd1931a813017b6b6590a41ea18b6ba49cd48a440bd9a3346a7623fb4ba34a3ee571e3c731f35a7a3cf25b551a680fa68763507b7fde3aaf023c50b9d22da6876ba337eb5e9dd9ec3daf970242b6c5aab3aa4b296ad8b9f6832f686ef70fa938b31b4e5ddd7364442d3ea72e73d668fb0937796f462923a81a47e1cee7426ff6d9221269b5a62ec03d6ec94d12606cb485560bab574816009e96504249385bb61a819be04f62c2066214d8360a2022beb316240b6c7d78bbe56c13082e0ca272661210abf020bf3b5783f1426436cf9ff41840593a5d0638d32fc51c5c65ff291a3a7a52fd6775e623a4439cc08dd25582febc944ef92d8dbd329c91de3e9c9582e41f17f3d186f104ad3f90995116c682a2a14a3b4b1f547c335f0be710fc9fc03e0e587b8cda31ce65b969878a4ad4283e6d5b0373f43da86e9e0ffe1ae0fddd3516255bd74566f36a38703d5f34249ded1f66b3d9b45b9af2ccfefe984e13376b1b2c6404aa48c8026132343da3f3a33659ec1b3e95080540b28b7f3fcd35fa5d843b579a84c089121a60d8c1754915c344eeaf45a9bf27dc0c1e78416169122091313eb0e87555abd706626e557fc36a04fcd191a58829104d6075c5594f627ca506bf181daec940f4a4f3af0074eee89daacde6758312622d4fa675b39f728e062d2bee680d8f41a597c262648bb18bcfc13c8b3d97b1a77b2ac3af745d61a34cc4709865bac824a94bb19058015e4e42d5ebcfc51b52c32252c009a798d5b370f

I built this packet in order to respect the 1200 bytes minimal size.
I am considering injecting this in a pull request, unless this was made on
purpose (in which case, what is it?).
What would you think about it?

Regardly,

Eva Gagliardi

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 24 Sep 2019 09:44:00 +1000

I don't think that anyone has validated the ClientHello thus far.  It's been a while since I generated it and it could easily be invalid.

As you say, both the quic_transport_parameters and application_protocol extensions need to be set correctly and I suspect that they are not. If you are able to contribute an example, I can integrate that into the script I use for generating the examples.

On Mon, Sep 23, 2019, at 22:34, gag83 E wrote:
> Hello, 
> 
> Still working on a QUIC implementation in Scapy, I tried to use the 
> packet given in the appendix A of the draft-ietf-quic-tls-23 for my 
> test with the existing implementations of QUIC. I realized that the 
> packet didn't meet some requirements : 
> that receive ClientHello or EncryptedExtensions messages without the 
> quic_transport_parameters extension MUST close the connection with an 
> error of type 0x16d (equivalent to a fatal TLS missing_extension alert, 
> see [ https://tools.ietf.org/html/draft-ietf-quic-tls-23#section-4.8 | 
> Section 4.8 ] )."
> 
> Moreover, there is no ALPN extension, which implied a connection error 
> with some servers. 
> 
> I am considering injecting this in a pull request, unless this was made 
> on purpose (in which case, what is it?).