From nobody Thu Aug 4 08:56:17 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD6F12D774 for ; Thu, 4 Aug 2016 08:56:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4vhtiskOc97N for ; Thu, 4 Aug 2016 08:56:14 -0700 (PDT) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FA0712D80C for ; Thu, 4 Aug 2016 08:56:08 -0700 (PDT) Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout1.telhc.bbc.co.uk (8.15.2/8.14.3) with ESMTP id u74Fu7a7018786 for ; Thu, 4 Aug 2016 16:56:07 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by bgb01xi1008 ([10.161.14.22]) with mapi id 14.03.0195.001; Thu, 4 Aug 2016 16:56:06 +0100 From: Lucas Pardue To: "quic@ietf.org" Thread-Topic: Porting QUIC to TLS (1.3) and inspecting traffic Thread-Index: AdHuaCxEkbDuBrP2QiWcqfBZuS3nGA== Date: Thu, 4 Aug 2016 15:56:06 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A2A846C82@bgb01xud1012> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4179-8.000.1202-22494.000 x-tm-as-result: No--51.054900-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A2A846C82bgb01xud1012_" MIME-Version: 1.0 Archived-At: Subject: [QUIC] Porting QUIC to TLS (1.3) and inspecting traffic X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 15:56:16 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A2A846C82bgb01xud1012_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, Following a very interesting BoF session at IETF 96 I am re-reviewing 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-thom= son-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 gr= oup) 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 timelin= es 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 Form= at? Thus allowing packet sniffers (i.e. Wireshark) the opportunity to decry= pt packets. a. In the case of the Chromium implementation, is this more a facet o= f BoringSSL? To expand on question 3. During the BoF, a point was made that Wireshark ca= n be used to inspect/debug QUIC traffic. This is true to some extent but th= e capability is currently limited to QUIC packet dissection and the public = part of the packet only. QUIC frame dissection (and further still, mapped d= ata dissection) is the really useful/interesting bit, especially in the cas= e 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 co= uld feasibly be developed given opportunity and time. Regards Lucas --_000_7CF7F94CB496BF4FAB1676F375F9666A2A846C82bgb01xud1012_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

Following a very interesting BoF session at IETF 96 = I am re-reviewing draft-tho= mson-quic-tls-00. This has raised a number of questions for me:

 

1.     &= nbsp; Have recent changes to the TLS 1.3 specification ca= used 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.     &= nbsp; How far off is an implementation of QUIC with TLS 1= .3?

a.       I’ve seen statements (on the QUIC Prototype P= rotocol 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.     &= nbsp; Once TLS 1.3 is fully integrated, will QUIC client = implementations be able to/want to export connection parameters using the N= SS Key Log Format? Thus allowing packet sniffers (i.e. Wireshark) the oppor= tunity 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 tru= e to some extent but the capability is currently limited to QUIC packet dis= section and the public part of the packet only. QUIC frame dissection (and further still, mapped data dissect= ion) is the really useful/interesting bit, especially in the case where a Q= UIC packet contains multiple QUIC frames. There are a few pieces of the puz= zle missing before QUIC frame dissection is possible but they could feasibly be developed given opportunity and tim= e.

 

Regards

Lucas

--_000_7CF7F94CB496BF4FAB1676F375F9666A2A846C82bgb01xud1012_-- From nobody Wed Aug 17 15:19:40 2016 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0700A12D7F6 for ; Wed, 17 Aug 2016 15:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.947 X-Spam-Level: X-Spam-Status: No, score=-3.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ppDuiInbfjD for ; Wed, 17 Aug 2016 15:19:33 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5157D12D7FA for ; Wed, 17 Aug 2016 15:19:21 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id i5so7655062wmg.0 for ; Wed, 17 Aug 2016 15:19:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2IUFdeemiDMIE56N27tkBvw+DNUs99YrtJFKZtKBvhk=; b=h6Z/+aonzg+nNKJ07irX+vNqNAYsPdqvQOtpP5IdbMdfkFPgjuReculuzovlDgPe/n g3QThWsjg7zzRT6DHEclRUed5eKwtrvpbpQPsdCzgpeho2Tly0b7ntn7Jl+C3QtsL4RZ N3msyI1HMx0RTO6PUNp+PFXnZL5+0mzyL4NdZih7jkcRSPnRsHHpHiBkYafSbTIR5+oY sKai3Ovkyw1RQHsqwcVvEYXaiYPAH8Wa7pGos98GiuQlEiJRrhZZKK8E+ebUvHmSz6tk Ow0ryVxFxwnWchHYNG8NpgfyMbilIOdm14rl0cNQp+pzLUBjkhsNalUeFcS48nnouvQM dCMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2IUFdeemiDMIE56N27tkBvw+DNUs99YrtJFKZtKBvhk=; b=jpFyYtWhXq+x1HSrcrC3u0SqQ9pyA9yenTUfl4fnhHva4wDjYwCRCbYvArsAB6k/LJ wYRvA5kVbSXvwvxfXADVO9B5xvtGCA1r9r6BiWTjx96d6uVW9DTV90vUSchcS0lsqSWF KxVl510VEg4PqMfKoJgnMEfH1M+278XYWfviC+wwa4FLTS2fB21x4TR8C/cDqxQOtL3Q 7YSCbByMpwpSJLNnuDGK6De6bE1XilsFF0Y6M7Dg88jfKfAWzERwyTBHmXyjzini76Cw qTrV35TPs32BbS2F6f0a0r/ibzmR7tojiD2AmzrxV3D1myZ3RzXAFABIOh/+FqHH67xJ 7agA== X-Gm-Message-State: AEkoousH2FbLapPYAgCRsJDGJHjOHbKhazogpn0DJOzpAgZCVKHjU8WfbDt0SyS9emUppaO4JUa61b3eWOr/ksnZ X-Received: by 10.194.87.101 with SMTP id w5mr51878991wjz.94.1471472359690; Wed, 17 Aug 2016 15:19:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.31.68 with HTTP; Wed, 17 Aug 2016 15:19:18 -0700 (PDT) In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A2A846C82@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A2A846C82@bgb01xud1012> From: Ryan Hamilton Date: Wed, 17 Aug 2016 15:19:18 -0700 Message-ID: To: Lucas Pardue Content-Type: multipart/alternative; boundary=089e0102e3ce4c1f1c053a4bdbd4 Archived-At: Cc: "quic@ietf.org" Subject: Re: [QUIC] Porting QUIC to TLS (1.3) and inspecting traffic X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 22:19:39 -0000 --089e0102e3ce4c1f1c053a4bdbd4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Aug 4, 2016 at 8:56 AM, Lucas Pardue wrote= : > Hello, > > > > Following a very interesting BoF session at IETF 96 I am re-reviewing > 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? > =E2=80=8BI think it's a work-in-progress and needs more work :>=E2=80=8B > 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=E2=80=99ve seen statements (on the QUIC Prototype Protocol Dis= cussion > 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.=E2=80=8B > 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? > =E2=80=8BIIRC, 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.=E2=80=8B 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 bu= t > 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 f= ew > 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 > QUIC@ietf.org > https://www.ietf.org/mailman/listinfo/quic > > --089e0102e3ce4c1f1c053a4bdbd4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Aug 4= , 2016 at 8:56 AM, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:

Hello,

=C2=A0

Following a very interesting BoF session at IETF 96 = I am re-reviewing draft-thomson-quic-tls-00. This has raised a = number of questions for me:

=C2=A0

1.=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 Have recent changes to the TLS 1.3 specification cause= d draft-thomson-quic-tls-00 to become outdated?

=E2=80=8BI think it's a work-in-progre= ss and needs more work :>=E2=80=8B
=C2=A0

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

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

a.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 I=E2=80=99ve seen statements (on the QUIC Prototype Pr= otocol Discussion group) about a migration of the Chromium implementation t= o 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, le= ss than a year.=E2=80=8B
=C2=A0

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

a.=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 In the case of the Chromium implementation, is this mo= re a facet of BoringSSL?

=E2=80=8BI= IRC, 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 conne= ctions too.=E2=80=8B

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

=C2=A0

Regards

Lucas


_______________________________________________
QUIC mailing list
QUIC@ietf.org
https://www.ietf.org/mailman/listinf= o/quic


--089e0102e3ce4c1f1c053a4bdbd4-- From nobody Wed Aug 31 23:50:17 2016 Return-Path: X-Original-To: quic@ietf.org Delivered-To: quic@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 16FA012B01A; Wed, 31 Aug 2016 22:50:24 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "Joel Jaeggli" To: "The IESG" X-Test-IDTracker: no X-IETF-IDTracker: 6.31.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147270902405.31899.2385564584375680812.idtracker@ietfa.amsl.com> Date: Wed, 31 Aug 2016 22:50:24 -0700 Archived-At: X-Mailman-Approved-At: Wed, 31 Aug 2016 23:50:15 -0700 Cc: quic@ietf.org, quic-chairs@ietf.org Subject: [QUIC] Joel Jaeggli's No Objection on charter-ietf-quic-00-01: (with COMMENT) X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Mailing list to discuss QUIC standardization List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Sep 2016 05:50:24 -0000 Joel Jaeggli has entered the following ballot position for charter-ietf-quic-00-01: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/charter-ietf-quic/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- While I don't think this is by any means fatal I, thing it's unfortunate that the third and fourth areas address transport considerations but not really the managability of flows. e.g. interactions with flow based sampling and reporting, firewall/load-balancer l4 interaction (on the state side) and so on as an area of consideration.