Subject: [QUIC] Alissa Cooper's Yes on charter-ietf-quic-00-01: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Thu, 01 Sep 2016 06:47:57 -0700

Alissa Cooper has entered the following ballot position for
charter-ietf-quic-00-01: Yes

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:
----------------------------------------------------------------------

What is the status of these PRs?
https://github.com/IETF-QUIC/Charter/pulls

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Thu, 1 Sep 2016 09:02:18 -0500

Hi, Alissa,

> https://datatracker.ietf.org/doc/charter-ietf-quic/

I checked two of the PRs. One looks like it's reflected in the datatracker,
but the other does not. I'll make sure the proponents think the datatracker
text reflects what they want to go with, before this goes for external
review.

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 12 Sep 2016 16:39:10 -0700

I had a few comments on the draft charter:

> There is emerging implementation and deployment experience with QUIC, a
> UDP-based protocol that provides a stream-multiplexing encrypted
transport.
> Based on that implementation and deployment experience, the QUIC working
group
> will provide a standards track specification generalizing the design
described
> in the initial set of draft-tsvwg-quic-protocol, draft-tsvwg-quic-loss-
recovery,
> and related documents.

"initial set" is ungrammatical here. Strike it.

> Key goals for QUIC are:
>
> - Minimizing connection establishment and overall transport latency for
> applications, starting with HTTP/2;
> - Providing multiplexing without head-of-line blocking;
> - Enabling deployment over unmodified Internet paths; and
> - Enabling multipath and forward error correction extensions.

I would like to see a security objective here, as I think we all agree that
it's a first-class priority.

- Providing secure transport by default using TLS 1.3.

> This work will ensure that
> QUIC using TLS1.3 has security and privacy properties that are at least
as good
> as a stack composed of TLS1.3 using TCP (or MPTCP when using multipath).

This "QUIC using TLS 1.3" language is a little weird. I would just say
"QUIC". I believe MT provided a similar comment.

> The third focus area will describe mappings between specific
applications???
> semantics and the transport facilities of QUIC. The first mapping will be
a
> description of HTTP/2 semantics using QUIC, specifically with the goal of
> minimizing web latency using QUIC. This mapping will accommodate the
extension
> mechanisms defined in the HTTP/2 specification. Upon completion of that
mapping,
> additional protocols may be added by updating this charter to include
them.

I'm not sure this should be in QUIC so much as HTTP. Minimally it somehow
needs to be in cooperation and I don't see anything here. I certainly don't
want this to preclude a mapping of only HTTP/2's transport facilities.

-Ekr

On Thu, Sep 1, 2016 at 7:02 AM, Spencer Dawkins at IETF <
[email-masked]> wrote:

> I checked two of the PRs. One looks like it's reflected in the
> datatracker, but the other does not. I'll make sure the proponents think
> the datatracker text reflects what they want to go with, before this goes
> for external review.
>
> Spencer
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic
>
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 13 Sep 2016 10:02:09 +1000

-IESG

> text reflects what they want to go with, before this goes for external

Any movement here?

---

From: Ryan Hamilton <[email-masked]>
Date: Mon, 12 Sep 2016 17:50:51 -0700

​​

On Mon, Sep 12, 2016 at 4:39 PM, Eric Rescorla <[email-masked]> wrote:

> > in the initial set of draft-tsvwg-quic-protocol, draft-tsvwg-quic
> -loss-recovery,
> > and related documents.
>
> I would like to see a security objective here, as I think we all agree
> that it's a first-class priority.
>

​QUIC is designed to have a plug-able handshake mechanism​. For sure, TLS
1.3 should be used in many cases, including HTTP over QUIC. But I would
want to makes sure that we don't lose the ability to develop other
applications on top of QUIC which want a different handshake.

​I'd be happy to see language requiring that we come up with a QUIC + TLS
1.3 mapping, just not language that says that TLS 1.3 is the only handshake
for QUIC.​ Perhaps you were already saying this, I'm not sure.

Cheers,

Ryan

> > semantics and the transport facilities of QUIC. The first mapping will
> be a

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Sep 2016 01:03:20 +0000

> QUIC is designed to have a plug-able handshake mechanism​. For sure, TLS 1.3 should be used in many cases, including HTTP over QUIC. But I would want to makes sure that we don't lose the ability to develop other applications on top of QUIC which want a different handshake.

I would not be bothered if we lose that ability.  Our industry does not have a good track record of designing protocols.  Even really smart people.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 12 Sep 2016 20:36:58 -0700

> "QUIC". I believe MT provided a similar comment.

At the moment, QUIC is being defined in the initial docs to be the
transport protocol that requires a handshake mechanism. This is why the
TLS1.3 mapping document exists separate from the QUIC document. It would be
odd to just say QUIC if you mean QUIC + TLS1.3.

> want this to preclude a mapping of only HTTP/2's transport facilities.

I don't expect this work to necessarily show up in the QUIC wg later, but
there may be parts of this work that do show up. I think there's value in
stating that other apps will be considered in the future, but I don't have
a strong opinion on what the charter should say about work that is to be
done post re-charter. Can you send a PR?

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 12 Sep 2016 20:43:44 -0700

On Mon, Sep 12, 2016 at 6:03 PM, Salz, Rich <[email-masked]> wrote:

>
> > QUIC is designed to have a plug-able handshake mechanism​. For sure, TLS
> I would not be bothered if we lose that ability.  Our industry does not
> have a good track record of designing protocols.  Even really smart people.

I would be :-)

That aside, I think it's necessary to separate the handshake from the rest
of the protocol, since we have to allow for TLS evolution independent of
QUIC. That would require QUIC to be able to use "a different handshake
protocol" anyways.

---

From: Jim Roskind <[email-masked]>
Date: Tue, 13 Sep 2016 00:01:41 -0700

On Mon, Sep 12, 2016 at 5:50 PM, Ryan Hamilton <[email-masked]> wrote:

>> ...
+1 for Ryan's desire to maintain a plug-able handshake mechanism.

QUIC support for TLS 1.3 is highly desirable (and will probably facilitate
PCI compliance), and that target may be what Eric is pushing for.  However,
it seems very desirable to allow QUIC to evolve the handshake mechanisms
(in various contexts), and then help feed that back for considerations in
future TLS definitions... with potential for a standardized (TLS driven)
adoption of results back into QUIC (some day).  Already work in QUIC has
helped push TLS to contain elements valued by the market (e.g., latency
reduction). It seems like a good thing to maintain that potential.

...again.. as Ryan noted... that may be what Eric requested... but it was
unclear. It would be nice if "plug-able" was as valued as a plugged-in TLS
1.3.

Jim

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 13 Sep 2016 11:43:21 +0000

> That aside, I think it's necessary to separate the handshake from the rest of the protocol, since we have to allow for TLS evolution independent of QUIC. That would require QUIC to be able to use "a different handshake protocol" anyways.

Good point.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Sep 2016 11:42:09 -0500

Hi, Martin,

On Mon, Sep 12, 2016 at 7:02 PM, Martin Thomson <[email-masked]>
wrote:

> datatracker,

Yeah, and actually telling people how the datatracker version relates to
open PRs in github would have been brilliant. Since I didn't do that
before, please accept my apologies, and here's what happened.

There are six open PRs in github, at
https://github.com/IETF-QUIC/Charter/pulls.

#8 (see #14 below).

#9 - I had used part of this PR in 00-02, but have looked more closely at
the result and used more of it in 00-03 (soon to be posted). Thanks for
submitting it, by the way.

#10 - I was able to use much of the proposed changes to the description of
the first work item, although I also got other changes to this text that I
needed to include. I would still like to give the working group some
expectations about partial reliability, and I don't think that capability
is limited to enabling FEC, is it? So I tried to soften language about a
potential rechartering. Please see what you think. I removed the final list
(since all the elements now appear somewhere else in the text).

#12 - This suggested nailing QUIC to New-Reno, rather than "an existing
congestion controller". Given that TCPM has already adopted CUBIC as a
standards-track specification, I split the difference, and used "a
standardized congestion controller", because I didn't want to force a
recharter if the working group found a standardized CUBIC to be acceptable.

#13 - I used the last sentence here, and it's now in 00-03.

#14 - this PR, and #8, were attempting to say something about operational
considerations. That's actually the subject of Benoit's BLOCK and Joel's No
Objection with Comments, but "including how the wire format will be
processed by devices on path" is getting close to the PLUS BOF proposal. On
last week's informal IESG call, we talked about this, and wordsmithed
"deployability and manageability implications". Benoit and I plan to talk
further today or tomorrow about this, so that's not stable text yet.

Stay tuned for a 00-03 version, of course. And thanks for asking.

Spencer

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 13 Sep 2016 09:52:57 -0700

> for QUIC.​ Perhaps you were already saying this, I'm not sure.

Sorry for any unclarity. I wasn't trying to start an argument just
memorialize the consensus.
I'm mirroring the language here from draft-hamilton-quic-transport-
protocol-00:

"TLS is assumed to be the default crypto handshake protocol, as described
in [draft-mthomson-quic-tls
<https://tools.ietf.org/html/draft-mthomson-quic-tls>]."
and was trying to fit it into charter-ese by making "default" do
double-duty.

How about:
- Provide always-secure transport [using TLS 1.3 by default]

I could live with the [] text either way, as I think the milestones make
clear that we're doing a TLS 1.3 binding.

-Ekr

Cheers,
>> > QUIC using TLS1.3 has security and privacy properties that are at
>> least as good

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Sep 2016 11:58:48 -0500

Hi, Eric,

Thanks for your comments. Please see inline.

> "initial set" is ungrammatical here. Strike it.

Consider it struck.

> - Providing secure transport by default using TLS 1.3.

I'm sympathetic to this point. We are also having a parallel chat about how
closely tied to TLS 1.3 (as opposed to future TLS versions) QUIC will be.
So, if this was

- Providing secure transport by default

or

- Providing secure transport by default using TLS,

would either of those work as well?

> "QUIC". I believe MT provided a similar comment.

I agree. That's going to be in 00-03.

> want this to preclude a mapping of only HTTP/2's transport facilities.

I strongly suspect that everyone involved to date knows this so nobody
bothered saying it, which could be fine when we're having a BOF, but is not
so fine when we're chartering a working group that involves people who
weren't present at the beginning of the conversation. I'm proposing

"QUIC will work closely with the HTTPbis working group, especially on the
third
focus area."

Would that work for you?

Thanks,

Spencer

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 13 Sep 2016 12:01:43 -0500

Hi, Eric,

> clear that we're doing a TLS 1.3 binding.

Thanks for clarifying. My previous e-mail crossed yours, I think. So I
should be asking about

- Provide always-secure transport

and

- Provide always-secure transport using TLS

Would either of those say what you're saying?

Thanks,

Spencer

>>> > semantics and the transport facilities of QUIC. The first mapping
>>> will be a
>>> > mechanisms defined in the HTTP/2 specification. Upon completion of
>>> that mapping,

---

From: Ryan Hamilton <[email-masked]>
Date: Tue, 13 Sep 2016 10:37:25 -0700

> and was trying to fit it into charter-ese by making "default" do

Totally on board with this. Sorry for misunderstanding!​

> clear that we're doing a TLS 1.3 binding.

​Sounds good to me.​

​

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 13 Sep 2016 10:42:52 -0700

>> clear that we're doing a TLS 1.3 binding.

+1. Spencer, does this language work for the charter, with the [] text?