Subject: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC

From: Ted Hardie <[email-masked]>
Date: Wed, 23 May 2018 13:16:23 -0700

The charter for the working group currently says:

This work will describe how the protocol uses TLS 1.3 for key negotiation
and will also describe how those keys are used to provide confidentiality
and integrity protection of both application data and QUIC headers.

It's easy to read that as saying the work should be constrained to use TLS
1.3 as provided.  If we read it that way, the design team proposal is
strictly speaking out of charter, because it requires the creation of not
just new APIs for TLS 1.3 but essentially a new formal analysis that the
security guarantees work when there is no record layer and where the
replacement has somewhat different facilities.

But the charter also says

Note that consensus is required both for changes to the current
protocol mechanisms and retention of current mechanisms. In particular,
because something is in the initial document set does not imply that
there is consensus around the feature or around how it is specified.

That argues that the community was willing to see serious change in
adopting this work and that this work falls within the kind of change that
was contemplated, even if happens to be across working groups.  Personally,
I think that means the design should be considered.

But I have grave concerns about the implications.  My back of the envelope
calculation is that this means at least one more cycle of specification and
interop will be required before we get back to where we are with draft -11,
and that estimate is because I'm in a hopeful mood that Sean and Eric can
move the required work in TLS along.  A more practical Ted would see this
as adding at minimum 6 months to the schedule.  The changes in TLS are also
large enough that I expect that the deployment time to see significant
penetration of the new libraries to be longer than it would be for the
previous design.   Call it 9 months, with 3 months of error bar.

During that time, the penetration of gQUIC outside Google does not seem
likely to slow.  If you want what QUIC has to offer now, you will take the
already available code and go.  For Web usages, there are some down sides
to that, and it may slow the eventual deployment of IETF QUIC.

But there are also down sides to all of the other protocols that would like
to use QUIC but have been told to wait for the completion of this effort.
We're likely to see DNS over HTTPS over QUIC instead of DNS over QUIC,
simply because the DOH transport docs will be done.  There are some
advantages there, but also disadvantages in enmeshing the HTTP and DNS
caching semantics.    There are also a number of groups who want to use
QUIC as a replacement for the WebRTC data channel (and some as the
substrate for media).  This additional delay will certainly cause some code
to be written that will either need extensive change or will bit rot (or
fork).  None of that is without costs, especially opportunity costs.

If the working group does decide to adopt this design, I believe part of
the milestone adjustment must be a serious consideration of delaying the
qpack and HTTP-specific work while the core transport is finished.  The
good news, I think this design could end up making the document separation
that requires much cleaner, as well as making how to use QUIC with other
application protocols much more obvious.

My thanks again for doing the work of bringing the design forward,

Ted

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 23 May 2018 20:23:16 +0000

> The changes in TLS are also large enough that I expect that the deployment time to see significant penetration of the new libraries to be longer than it would be for the previous design.   Call it 9 months, with 3 months of error bar.

For what it’s worth, the next release of OpenSSL would have supported everything that’s needed for the prior QUIC crypto. We had some email chats with Chris, and in my view, this is no longer possible, which means it will fall to the next release, which will be gated by FIPS validation work and is probably similar timetable to yours, above.  Or folks will have to run off master, which many are reluctant to do.

---

From: Roberto Peon <[email-masked]>
Date: Wed, 23 May 2018 20:25:44 +0000

I’ll say again that we should start work on IETF QUICv2 now.
How/when do we charter that work? Not only do I think this is the right thing, I suspect it will speed up the work on IETF QUICv1

-=R

From: QUIC <[email-masked]> on behalf of Ted Hardie <[email-masked]>
Date: Wednesday, May 23, 2018 at 1:17 PM
To: IETF QUIC WG <[email-masked]>
Subject: Higher layer comments on stream 0 proposal, WG schedule, and gQUIC

This work will describe how the protocol uses TLS 1.3 for key negotiation and will also describe how those keys are used to provide confidentiality and integrity protection of both application data and QUIC headers.

It's easy to read that as saying the work should be constrained to use TLS 1..3 as provided.  If we read it that way, the design team proposal is strictly speaking out of charter, because it requires the creation of not just new APIs for TLS 1.3 but essentially a new formal analysis that the security guarantees work when there is no record layer and where the replacement has somewhat different facilities.

That argues that the community was willing to see serious change in adopting this work and that this work falls within the kind of change that was contemplated, even if happens to be across working groups.  Personally, I think that means the design should be considered.

But I have grave concerns about the implications.  My back of the envelope calculation is that this means at least one more cycle of specification and interop will be required before we get back to where we are with draft -11, and that estimate is because I'm in a hopeful mood that Sean and Eric can move the required work in TLS along.  A more practical Ted would see this as adding at minimum 6 months to the schedule.  The changes in TLS are also large enough that I expect that the deployment time to see significant penetration of the new libraries to be longer than it would be for the previous design.   Call it 9 months, with 3 months of error bar.

During that time, the penetration of gQUIC outside Google does not seem likely to slow.  If you want what QUIC has to offer now, you will take the already available code and go.  For Web usages, there are some down sides to that, and it may slow the eventual deployment of IETF QUIC.

But there are also down sides to all of the other protocols that would like to use QUIC but have been told to wait for the completion of this effort.  We're likely to see DNS over HTTPS over QUIC instead of DNS over QUIC, simply because the DOH transport docs will be done.  There are some advantages there, but also disadvantages in enmeshing the HTTP and DNS caching semantics.    There are also a number of groups who want to use QUIC as a replacement for the WebRTC data channel (and some as the substrate for media).  This additional delay will certainly cause some code to be written that will either need extensive change or will bit rot (or fork).  None of that is without costs, especially opportunity costs.

If the working group does decide to adopt this design, I believe part of the milestone adjustment must be a serious consideration of delaying the qpack and HTTP-specific work while the core transport is finished.  The good news, I think this design could end up making the document separation that requires much cleaner, as well as making how to use QUIC with other application protocols much more obvious.

Ted

---

From: Patrick McManus <[email-masked]>
Date: Wed, 23 May 2018 16:50:57 -0400

Schedule needs to be part of this conversation - it certainly was within
the design team. But its not the initial (or solely determinative)
question, in my mind.

At the end of the DT process the group had consensus that it was more
important to get it right with reasonable cost instead of constraining
ourselves to near zero cost. The output reflects that.

In particular the proposal does a nice job of sorting out the issues of
encryption level (which is a terrible problem with stream 0 and the
associated acks) while still maintaining a unified reliability layer.
That's a pretty neat trick and a tough circle to square.

There was a bit of a personal journey on this as well for me (it may have
helped to have internalized an entire potential shift to DTLS first before
settling on this much more modest approach). I would encourage you to get
comfortable with the details, and lets all have a discussion of the merits
instead of jumping ahead to the cost benefit discussion (I'm not suggesting
eliding that discussion entirely - shipping is a feature, and we should
balance all the features as we've done in the past.). As the details start
to come together it actually feels less ambitious - just a reasonable
ordering of things really that solves a number of very practical issues
we've shown during our running code exercises. It just looks at the
boundaries between security/application/transport in a novel way.. which is
just a synonym for the QUIC WG :)

That's my experience anyhow.

Personally, I've been reassured that the owners of a number of TLS stacks
embraced this approach so eagerly, as a significant amount of the burden
falls on them. There will, as always, be laggards and trailblazers on that
front.. as long as there are existence proofs that it can be done
reasonably I wouldn't let the competitive details of which libraries are at
what stage tell us too much about what is right for the protocol we're
building.

-P

On Wed, May 23, 2018 at 4:16 PM, Ted Hardie <[email-masked]> wrote:

> 1..3 as provided.  If we read it that way, the design team proposal is
> But there are also down sides to all of the other protocols that would
> like to use QUIC but have been told to wait for the completion of this
> effort.  We're likely to see DNS over HTTPS over QUIC instead of DNS over
> QUIC, simply because the DOH transport docs will be done.  There are some

---

From: Lucas Pardue <[email-masked]>
Date: Wed, 23 May 2018 21:47:05 +0000

Hi Ted,

Thanks for your thoughts.

> My back of the envelope calculation is that this means at least one more cycle of specification and interop will be required before we get back to where we are with draft -11, and that estimate is because I'm in a hopeful mood that Sean and Eric can move the required work in TLS along.  A more practical Ted would see this as adding at minimum 6 months to the schedule.  The changes in TLS are also large enough that I expect that the deployment time to see significant penetration of the new libraries to be longer than it would be for the previous design.   Call it 9 months, with 3 months of error bar.

I can't talk to the merit of this proposal in relation to QUIC transport. As somebody greatly interested in application mapping (with a WIP HTTP/QUIC implementation) I have concerns that progress in this area keeps being pushed back. We have little interop experience in this area to feed back to transport. 

A particular sore point is that the handshake-oriented changes have weak relation to QUIC "steady state', upon which application mappings depend. E.g. Draft 09 and 12 differ little in handling of STREAM frames. 

Regards
Lucas

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 23 May 2018 17:05:56 -0700

I agree that we must grapple with the question of what this proposal does
to the timeline and that schedule needs to be a part of the discussion.

That said, I think this needs to be done in context. Going into London, the
editors spent three days whittling down and addressing open issues as best
we could. This was presented during the wg meeting. Importantly, the list
of issues that we had no clear ideas or direction on how to fix were all
around the handshake (see slide 9 in this deck
<https://github.com/quicwg/wg-materials/blob/master/ietf101/editors-update.pdf>
.)

The set of handshake issues is probably the most difficult and glaring one
at this point in the list of pending QUICv1 issues.

Solving them with the DT's proposal moves us closer to our goals. Yes, it
will take time, but how much time any other solution(s) take? We have only
one other real proposal that fully solves all those issues: some form of
the QUIC/DTLS proposal. The DT spent time with further generations of
integrating QUIC and DTLS, but among others, there are concerns of
available implementations and implementation maturity there. Additionally,
that proposal ends up tying up QUIC and DTLS standardization processes in
ways that may cause even more delay and limit future evolution. It may be
worth documenting the alternative DTLS proposal and why the DT chose the
proposal it did, for posterity.

I agree that we should have a discussion on what this proposal does to our
timeline. But I'll note that this is finally a timeline that would include
real solutions to important open issues that need solving for QUICv1 to
finish.

On Wed, May 23, 2018 at 2:47 PM, Lucas Pardue <[email-masked]>
wrote:

> > My back of the envelope calculation is that this means at least one more
> cycle of specification and interop will be required before we get back to
> where we are with draft -11, and that estimate is because I'm in a hopeful
> mood that Sean and Eric can move the required work in TLS along.  A more
> practical Ted would see this as adding at minimum 6 months to the
> schedule.  The changes in TLS are also large enough that I expect that the
> deployment time to see significant penetration of the new libraries to be
> longer than it would be for the previous design.   Call it 9 months, with 3
> months of error bar.
>
> I can't talk to the merit of this proposal in relation to QUIC transport.
> As somebody greatly interested in application mapping (with a WIP HTTP/QUIC
> implementation) I have concerns that progress in this area keeps being
> pushed back. We have little interop experience in this area to feed back to
> transport.
>
> A particular sore point is that the handshake-oriented changes have weak
> relation to QUIC "steady state', upon which application mappings depend.
> E.g. Draft 09 and 12 differ little in handling of STREAM frames.
>
> Regards
> Lucas
>

---

From: Kazuho Oku <[email-masked]>
Date: Thu, 24 May 2018 09:42:40 +0900

2018-05-24 9:05 GMT+09:00 Jana Iyengar <[email-masked]>:
> I agree that we must grapple with the question of what this proposal does to
> the timeline and that schedule needs to be a part of the discussion.
>
> we could. This was presented during the wg meeting. Importantly, the list of
> issues that we had no clear ideas or direction on how to fix were all around
> the handshake (see slide 9 in this deck.)
>
> one other real proposal that fully solves all those issues: some form of the
> QUIC/DTLS proposal. The DT spent time with further generations of
> integrating QUIC and DTLS, but among others, there are concerns of available
> implementations and implementation maturity there. Additionally, that
> proposal ends up tying up QUIC and DTLS standardization processes in ways
> that may cause even more delay and limit future evolution. It may be worth
> documenting the alternative DTLS proposal and why the DT chose the proposal
> it did, for posterity.

FWIW, I have added Appendix C to the design doc that briefly explains
the DTLS-based approach as well as the reasons why we abandoned it.

The text is rough and is likely to have some aspects missing, I would
appreciate it if anybody in the Design Team could improve it.

Lastly, the comparison of the wire formats between the DTLS-based
approach and the proposed approach might give us a clue on what the
difference of security aspects are between DTLS and the proposed
approach. I think that it is more natural to compare the proposed
approach to DTLS than to TLS when discussing about security aspects.

>> > practical Ted would see this as adding at minimum 6 months to the schedule.
>> > The changes in TLS are also large enough that I expect that the deployment
>> > time to see significant penetration of the new libraries to be longer than
>> > it would be for the previous design.   Call it 9 months, with 3 months of
>> > error bar.
>>

-- 
Kazuho Oku