Subject: [QUIC] Porting QUIC to TLS (1.3) and inspecting traffic

From: Lucas Pardue <[email-masked]>
Date: Thu, 4 Aug 2016 15:56:06 +0000

Hello,

Following a very interesting BoF session at IETF 96 I am re-reviewing draft-thomson-quic-tls-00<https://tools.ietf.org/html/draft-thomson-quic-tls-00>. This has raised a number of questions for me:

1.       Have recent changes to the TLS 1.3 specification caused draft-thomson-quic-tls-00 to become outdated?

a.       Conversely, does the proposed freezing of the TLS 1.3 wire format give the document more stability?

2.       How far off is an implementation of QUIC with TLS 1.3?

a.       I've seen statements (on the QUIC Prototype Protocol Discussion group) about a migration of the Chromium implementation to TLS 1.3. However, those were made a while back and things have moved on. Perhaps some timelines been drawn up?

3.       Once TLS 1.3 is fully integrated, will QUIC client implementations be able to/want to export connection parameters using the NSS Key Log Format? Thus allowing packet sniffers (i.e. Wireshark) the opportunity to decrypt packets.

a.       In the case of the Chromium implementation, is this more a facet of BoringSSL?

To expand on question 3. During the BoF, a point was made that Wireshark can be used to inspect/debug QUIC traffic. This is true to some extent but the capability is currently limited to QUIC packet dissection and the public part of the packet only. QUIC frame dissection (and further still, mapped data dissection) is the really useful/interesting bit, especially in the case where a QUIC packet contains multiple QUIC frames. There are a few pieces of the puzzle missing before QUIC frame dissection is possible but they could feasibly be developed given opportunity and time.

Regards
Lucas

---

From: Ryan Hamilton <[email-masked]>
Date: Wed, 17 Aug 2016 15:19:18 -0700

On Thu, Aug 4, 2016 at 8:56 AM, Lucas Pardue <[email-masked]> wrote:

> Hello,
>
>
>
> Following a very interesting BoF session at IETF 96 I am re-reviewing
> draft-thomson-quic-tls-00
> <https://tools.ietf.org/html/draft-thomson-quic-tls-00>. This has raised
> a number of questions for me:
>
>
>
> 1.       Have recent changes to the TLS 1.3 specification caused
> draft-thomson-quic-tls-00 to become outdated?
>
​I think it's a work-in-progress and needs more work :>​

> a.       I’ve seen statements (on the QUIC Prototype Protocol Discussion
> group) about a migration of the Chromium implementation to TLS 1.3.
> However, those were made a while back and things have moved on. Perhaps
> some timelines been drawn up?
>
Good question. I'd guess more than a quarter, less than a year.​

> 3.       Once TLS 1.3 is fully integrated, will QUIC client
> implementations be able to/want to export connection parameters using the
> NSS Key Log Format? Thus allowing packet sniffers (i.e. Wireshark) the
> opportunity to decrypt packets.
>
​IIRC, Chrome is able to export keys from a TLS connection so that
wireshark can decrypt a connection. I would expect this to be possible for
QUIC connections too.​

To expand on question 3. During the BoF, a point was made that Wireshark
> can be used to inspect/debug QUIC traffic. This is true to some extent but
> the capability is currently limited to QUIC packet dissection and the
> public part of the packet only. QUIC frame dissection (and further still,
> mapped data dissection) is the really useful/interesting bit, especially in
> the case where a QUIC packet contains multiple QUIC frames. There are a few
> pieces of the puzzle missing before QUIC frame dissection is possible but
> they could feasibly be developed given opportunity and time.
>
>
>
> Regards
>
> Lucas
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>
>