Re: Stream0 Design Team Proposal

Christian Huitema <> Wed, 23 May 2018 05:29 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D89681241F5 for <>; Tue, 22 May 2018 22:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id s5Smw4RCsKgc for <>; Tue, 22 May 2018 22:29:35 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A5BF512025C for <>; Tue, 22 May 2018 22:29:34 -0700 (PDT)
Received: from ([]) by with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <>) id 1fLML4-0003tA-Qb for; Wed, 23 May 2018 07:29:32 +0200
Received: from [] ( by with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <>) id 1fLMKx-0004rR-R6 for; Wed, 23 May 2018 01:29:27 -0400
Received: (qmail 23171 invoked from network); 23 May 2018 05:29:22 -0000
Received: from unknown (HELO []) ([]) (envelope-sender <>) by (qmail-ldap-1.03) with ESMTPA for <>; 23 May 2018 05:29:22 -0000
References: <> <> <>
From: Christian Huitema <>
Openpgp: preference=signencrypt
Autocrypt:; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <>
Date: Tue, 22 May 2018 22:29:12 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------16AE8EB6EBC4B8EB86EA1E0C"
Content-Language: en-US
Subject: Re: Stream0 Design Team Proposal
Authentication-Results:; auth=pass smtp.auth=
X-AntiSpamCloud-Outgoing-Class: unsure
X-AntiSpamCloud-Outgoing-Evidence: Combined (0.34)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iIhwcd0PmOQbQoa1/fCxbx602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO37pNwwF1lRXh5rzvPzo9Jts1ujulqUFmMITHM77eiVipHPYbz5lftSIizApgCPMbs7i TvJ2/ZGzVWB9scFAaCdIFaUvXN+CI+RGy3Me16pBy0LkIcQZ+RRGzUcmNZyDXh/TBCf6oYXAWGet lavcAjD9ytQxIHf9lN5jjLJaPK8lRJSPf/SXbEnDSsal/zZzc4n9VZdr7RAFD5mRwooUYhwMPaBP aKeQW+/QlaOdv8isl/qMm08Zpim2AHUKEWvQ6G/bWfgucjnNmABpGhD9TTttrFCuZ0NkwnSz2Luu o1u9uevuNfM1HjkNEFwape+IgNezYqxGMqsKjARq8PBC4qjpVMhqNcdjhoIlgrKzBvjTmdySlZou 9qHIGOZDEEo7Oyc1nq0gsY582CWqKjiRB3ukywmZtiDkyd4mEBjJGGEJgawbllbHk+xyUKopM6rc KCaQX/lIXcRWtobViGg9fpXXTg8/eGzRNUUVgcQ9smKzWE4kNwHFJ1FRpFF1qVhW+97PWzLGmQvK RC7xldu8DpWU2yw6z85L3UyCdO+oQ3S7VPd90DA1c/ZLOZZo7XGPVfWv8HL1YL3Zn8TE/e4IMjT6 4dZYZAAUgQSn0n4YsmwRRGxQZAxG+4f1XAVNzQl2yuggKW28pboyZCmKkHUYXaluOeVTar9zozYB t9COYTwdEvjlXiWkXE5dwL2v3l4fZntB4/4Pbrz2QtFuyl+Sh6dFwOZmPeQdOCsWer2luIDmfqb5 R4VemuUI6bcEARsm0H3NNoW1ZvdERgvndX6lJvSNZy58uobCIkCdwVDO83SGTnM2K/9iKCD9v589 nVS3hWSdEOMftBjsWb6BDQzjSsHUIomTnJwT4ky6b7E7Hukt2Ge4B8NG0VKlrY+34Zmj+F/tjlrZ UvGhhjiSam0tWhQxL7hrJSk60SF3F6RYOYr2
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2018 05:29:38 -0000

I like the proposal. In particular, I really like the encryption of
handshake packets with the handshake key, as it does close a number of
avenues for attacks. And I like that it solves the "ack promotion" issue
that I was complaining against for some time. Turns out that in the
current draft, it is very hard to contain that problem if you enable
client auth.

On the other hand, I agree with Martin that a lot of the additions to
transmission recovery should be moved to separate PRs. I am not
enthusiastic with the EMPTY ACK mechanism, or with the proposed
"implicit acknowledgement" of a lower crypto stream by a higher level
ack. In any case, starting as simple as possible would help having the
first implementations and tests.

On 5/22/2018 8:26 PM, Subodh Iyengar wrote:
> As an implementor of fizz, I support this design and am willing to
> implement this as well.
> While this is a change in the API that TLS classically exposes, I
> think this is the right tradeoff because it helps make things way more
> explicit which will prevent several other bugs from happening in the
> future.
> Subodh
> ------------------------------------------------------------------------
> *From:* QUIC <> on behalf of Martin Thomson
> <>
> *Sent:* Tuesday, May 22, 2018 8:00:40 PM
> *To:* Ian Swett
> *Cc:*; QUIC WG
> *Subject:* Re: Stream0 Design Team Proposal
> First of all, thanks to the design team for the work they have done.  I
> haven't digested everything yet, but I think that I have a good sense of
> the shape of the proposal.
> Overall, this looks like a workable design.  It's a lot more invasive of
> the cryptographic handshake implementation than I had thought people were
> willing to stomach originally.  But it's clear that we've run into
> problems
> with the current, more abstract API and this is a fairly natural way to
> split TLS.  I've spent a little time thinking about how this might be
> implemented and I think that it's not going to be *too* painful.  The
> proof
> will be in the pudding there though.
> In looking at the PR, I really appreciate seeing all the changes together.
> BTW, the link above points to the wrong PR, so be careful (it appears to
> have the same content, but that's not guaranteed).  The actual PR is here:
> I've pushed a branch to the main repo so that you can preview the entire
> document set:
> It seems like there are some core changes here and a bunch of separable or
> at least secondary changes.  I'm sure that each one has its own
> justification, but that isn't always clear. The following changes seem
> like
> they are separable:
> * The use of separate packet number spaces
> * The Retry packet changes (and NEW_TOKEN)
> * The TLS extension for flow control
> Right now, some of these appear to be entirely gratuitous.  I'd like
> to get
> to the bottom of each before we continue.
> At a minimum, the PR we land first should include just the core changes.
> As you say, reviewing a monster PR like this will only make GitHub weep
> unicorns, but we might be able to cut this into smaller pieces.
> On Wed, May 23, 2018 at 11:31 AM Ian Swett <ianswett=
>> wrote:
> > Dear QUIC WG,
> > On behalf of the Stream 0 Design Team, I am pleased to report that we
> have consensus on a proposed approach to share with the WG. The DT's
> proposal will make QUIC and TLS work closer together and incorporates
> ideas
> from DTLS, but it does not use the DTLS protocol itself.
> > The DT believes this solves the important open Stream 0 issues. The
> proposal will be a bit more invasive in TLS, but we believe it is the
> right
> long-term direction and several TLS stacks (BoringSSL, PicoTLS, NSS, and
> Mint) are willing and able to do the work necessary.. A number of stacks
> are currently working on implementations of this new approach, which we
> hope to have in time for the Interim meeting.
> > A design document describing the overall approach can be found at:
> > A PR making the changes to the QUIC documents can be found at:
> >
> > A few design details did not have clear consensus, but it was felt it
> would be better to discuss those in the wider WG than delay the design
> team.  A consistent choice was made in the PR and these issues are
> mentioned in Appendix B of the design doc.
> > As always, comments and questions welcome. That said, this is a big PR
> and we recognize that some editorial work is going to be needed before
> merging. In the interest of letting people follow along, and to keep
> github
> from falling over, we ask people to keep discussion on the mailing
> list and
> refrain from making PR comments.
> > See you in Kista!
> > Ian and Eric