Subject: [QUIC] Draft charter

From: Ted Hardie <[email-masked]>
Date: Fri, 13 May 2016 16:26:39 -0700

Howdy,

As part of the BoF preparation, we put together a stab at a draft charter.
It's available as html and markdown on github at:

https://github.com/IETF-QUIC/Charter

I've attached the HTML version as well.

It would be great to have some of the discussion on the list before the
BoF.  Comments to the list or issues/pull requests at the github repo are
welcome.  We will periodically reflect any issues or suggestion from the
Repo back to the list, but this will be manual, so expect some lag.

regards,

Ted

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 13 May 2016 19:55:43 -0400

How do you intend to provide for lawful
interception that will allow it to be used?
--tony

On 2016-05-13 7:26 PM, Ted Hardie wrote:
> Howdy,
>
> As part of the BoF preparation, we put together a stab at a draft 
> charter.  It's available as html and markdown on github at:
>
> It would be great to have some of the discussion on the list before 
> the BoF.  Comments to the list or issues/pull requests at the github 
> repo are welcome.  We will periodically reflect any issues or 
> suggestion from the Repo back to the list, but this will be manual, so 
> expect some lag.
>
> regards,
>
> Ted
>
>
> _______________________________________________
> QUIC mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/quic

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 May 2016 17:28:02 -0700

> interception that will allow it to be used?

Hi Tony,

Please review RFC 2804. The issue you raise is not a consideration in this
context.

Regards,

Ted

Mobile, terse.

---

From: Tony Rutkowski <[email-masked]>
Date: Fri, 13 May 2016 20:34:14 -0400

Hi Ted,

RFC2804 is familiar, but pronouncements
do not solve real world requirements.  There
are many reasons today why providers require
lawful interception capabilities - which is far
broader than "wiretapping."  Managing traffic,
cybersecurity, and an array of compliance
obligations worldwide necessitate a means
under the appropriate circumstances to acquire
a variety of circumscribed, controlled access to
observables on the wire.  This can't just be blown
away by a political RFC reference.

--tony

On 2016-05-13 8:28 PM, Ted Hardie wrote:
>
> Hi Tony,
>
> Please review RFC 2804. The issue you raise is not a consideration in 
> this context.
>
> Regards,
>
> Ted
>

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 13 May 2016 17:50:53 -0700

Tony,

I assume you are asking about lawful interception of HTTPS traffic, which
can be over TCP, or, as will be proposed in this BoF, over QUIC -- this
isn't a QUIC-specific problem, and therefore probably doesn't belong in
this BoF.

Did you mean something else?

- jana
On May 13, 2016 4:55 PM, "Tony Rutkowski" <[email-masked]> wrote:

> QUIC mailing [email-masked]://www.ietf.org/mailman/listinfo/quic
>
>
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 13 May 2016 17:54:51 -0700

I too am having trouble understanding the concern. We already have
extensive experience with end-to-end encryption for HTTPS traffic
(specifically HTTP over TLS over TCP) and those protocols contain no
provisions for lawful intercept. As Jana says, QUIC is isomorphic to that
stack and as it will be using the same security layer (TLS), whatever law
enforcement currently does would presumably also apply with small
modifications to QUIC.

-Ekr

---

From: Ted Hardie <[email-masked]>
Date: Fri, 13 May 2016 18:34:39 -0700

On Fri, May 13, 2016 at 5:34 PM, Tony Rutkowski <[email-masked]>
wrote:

> do not solve real world requirements.
>

RFC 2804 is a consensus statement of the IETF on what sort of work it will
take on.  In the context of a charter for work in the IETF, it is salient.

> There
You are welcome to suggest changes in IETF policy for these reasons (or any
others).   Given the publication of RFC 7258 and RFC 7624, I do not think
of much of your chances, honestly, but the drafts directory is open at your
will.  The General Area director will no doubt be happy to suggest an
appropriate place for discussion.

Until the policy has changed, however, putting forward a charter with work
the IETF will not do is simply a waste of time.

Ted

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 14 May 2016 08:41:58 -0400

Hi Ted,

This is an unfortunate fallout of the extreme
politicization of the IETF in recent years resulting
in religious dogma concerning the technology.
The result is that the IETF does a lot of work
that itself is a waste of time because it doesn't
meet the requirements of industry and legal
systems, and inures to the benefit of the worst
kinds of end users.

One would like to think there is some halfway
house such as the IEEE's new Encrypted Traffic
Inspection working group.  It isn't quite so
dogmatic and religious.

sigh,
tony

On 2016-05-13 9:34 PM, Ted Hardie wrote:
> Until the policy has changed, however, putting forward a charter with 
> work the IETF will not do is simply a waste of time.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 14 May 2016 13:30:36 +0000

> The result is that the IETF does a lot of work that itself is a waste of time

Such as?

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 14 May 2016 11:23:34 -0400

As a SWAG, observing the IETF and
precursor over the past 45 some years,
maybe about 10 percent of its RFCs have
seen substantial implementation.  That's
not bad for an academic oriented group and
a testament to innovation introduced.

The much larger, major industry ones such
as 3GPP achieve higher success rates because
their specs are mandated into the infrastructure
and service.  Ditto CableLabs and the large vendor
development group organizations.

The IETF's religious views on encryption and
failure to support forensic requirements seem
to be producing RFCs that will not pass legal
muster or meet industry service agreements
or expose providers to significant tort penalties.
(As the guy who initially arranged for ISOC to
provide liability insurance to those in IETF
positions, it might be worth considering, increasing
the coverage with the increasing awards being
witnessed in tort litigation.)

--tony

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 14 May 2016 15:29:57 +0000

Tony,

Please name one specific example.  No guesses.  One that is not trumped by, say, TLS or IPsec.

As for comparisons to CableLabs or 3GPP, they perhaps get higher rates of success but (a) entry costs are prohibitive and (b) records are not public.  So who knows if what you claim is accurate, or even what the reasons for it are?  The mobile industries history with encryption is a sad one, isn’t it.
--
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 14 May 2016 11:45:57 -0400

Contraire.  Their specifications are public,
free, well versioned, and easily discoverable
with persistent URI's.  In the case of 3GPP, all
of its input materials are public - even if not
downloadable without membership - which
at the lowest levels is not much more than IETF
meeting charges these days.  The biggest challenge
is dealing with the enormous amount of work,
and frequency of meetings - spread across almost
40 groups.

The history is hardly sad.  It cost effectively meets
the needs of providers and end users and passes
legal muster.  It also by any metric has produced
by far the largest, most ubiquitous, and most
successful electronic communications infrastructure
worldwide.  It represents the difference between
industry and academic groups; and the fact that
the encryption is good enough for the vast preponderance
of users except maybe ISIS, underscores that difference.

--tony

On 2016-05-14 11:29 AM, Salz, Rich wrote:
>
> As for comparisons to CableLabs or 3GPP, they perhaps get higher rates 
> of success but (a) entry costs are prohibitive and (b) records are not 
> public.  So who knows if what you claim is accurate, or even what the 
> reasons for it are?  The mobile industries history with encryption is 
> a sad one, isn’t it.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Sat, 14 May 2016 15:48:15 +0000

Tony,

Can I see drafts and failed working groups and read email and understand why AS/5 was picked, for example?  Cost to fully participate in IETF is email and Internet video, really.

Any any rate, still looking for proof, rather than assertion, of IETF RFC’s that failed because of law enforcement.  Or even just wasted effort.

---

From: Ted Hardie <[email-masked]>
Date: Sat, 14 May 2016 09:25:43 -0700

Howdy,

This seems to have gone in a direction not directly related to the subject
"draft charter" or, indeed, to QUIC specifically.  Can I ask you gentlemen
to take the discussion to a different venue?

thanks,

Ted

On Sat, May 14, 2016 at 8:48 AM, Salz, Rich <[email-masked]> wrote:

> Tony,
>
>
>
> Can I see drafts and failed working groups and read email and understand
> why AS/5 was picked, for example?  Cost to fully participate in IETF is
> email and Internet video, really.
>
>
>
> Any any rate, still looking for proof, rather than assertion, of IETF
> RFC’s that failed because of law enforcement.  Or even just wasted effort.
>
>
>
> --
>

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 14 May 2016 09:47:27 -0700

+1.  None of this is specific to QUIC, and none of this is related to the
charter that's been proposed. I would love to see specific discussion on
the charter, so I encourage folks to read the charter and comment on it in
this or in new threads.

- jana
On May 14, 2016 9:26 AM, "Ted Hardie" <[email-masked]> wrote:

Howdy,

thanks,

Ted

---

From: Tony Rutkowski <[email-masked]>
Date: Sat, 14 May 2016 15:51:49 -0400

No need.  Did due diligence.
Swap those T-Shirts for ones
that read "Encryption everywhere" :-)

On 2016-05-14 12:25 PM, Ted Hardie wrote:
> indeed, to QUIC specifically.  Can I ask you gentlemen to take the 
> discussion to a different venue?

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 May 2016 12:08:36 +0300

Hi, Ted

The charter looks OK, except that the term “quic” is used for the Google experiment (“There is emerging implementation and deployment experience with QUIC”), the protocol described in the initial set of drafts, and the output of the working group. The phrase “a standards track specification generalizing the design described in the initial set” seems to limit the amount of change control the working group will have.

I think it would be better for the charter to read like many others along the lines of “the WG will specify a standards-track protocol with these drafts as starting points and based on implementation and deployment experiments with UDP-based Google experiment.”

Just so long as it’s clear that the WG has change control.

Yoav

> On 14 May 2016, at 2:26 AM, Ted Hardie <[email-masked]> wrote:
> 
> Howdy,
> 
> As part of the BoF preparation, we put together a stab at a draft charter.  It's available as html and markdown on github at:
> 
> https://github.com/IETF-QUIC/Charter <https://github.com/IETF-QUIC/Charter>
> 
> It would be great to have some of the discussion on the list before the BoF.  Comments to the list or issues/pull requests at the github repo are welcome.  We will periodically reflect any issues or suggestion from the Repo back to the list, but this will be manual, so expect some lag.
> 
> regards,
> 
> Ted
> <quic-charter.html>_______________________________________________
> QUIC mailing list
> [email-masked]

---

From: "Eggert, Lars" <[email-masked]>
Date: Sun, 15 May 2016 13:35:40 +0000

> https://github.com/IETF-QUIC/Charter <https://github.com/IETF-QUIC/Charter>

This is one of the better charters for new work I've read - good to go IMO.

Lars

---

From: Ted Hardie <[email-masked]>
Date: Sun, 15 May 2016 09:18:03 -0700

Hi Yoav,

On Sun, May 15, 2016 at 2:08 AM, Yoav Nir <[email-masked]> wrote:

> Hi, Ted
>
> The charter looks OK, except that the term “quic” is used for the Google
> experiment (“There is emerging implementation and deployment experience
> with QUIC”), the protocol described in the initial set of drafts, and the
> output of the working group. The phrase “a standards track specification
> generalizing the design described in the initial set” seems to limit the
> amount of change control the working group will have.
>
> That's not the intent--the change control will shift to the working group
as normal.  We tried to capture that with this language:

"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's taken from how the HTTPbis work handled the input documents to
HTTP/2.

I think it would be better for the charter to read like many others along
> the lines of “the WG will specify a standards-track protocol with these
> drafts as starting points and based on implementation and deployment
> experiments with UDP-based Google experiment.”
>
> If you are okay with "these drafts" being a bit of a moving target, I
think something like this would be okay, modulo the "Google" above.  Lots
of other folks have worked with quic and contributed.  Would this language
work:

"The Working group will specify a standards-track protocol based on drafts
derived from the implementation and deployment experiments of pre-standard
QUIC."?

regards,

Ted

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 May 2016 12:42:57 -0400

> https://github.com/IETF-QUIC/Charter

As Lars says, this is pretty good.

I think that the first and second parts are the essential pieces to
concentrate on at this moment.  While I also want to do multipath and
FEC, I don't believe that we are ready enough yet to commit to doing
something with FEC.  A rechartering when that time comes should not be
hard and a smaller scope helps maintain focus.

If you reduce part 4 to a note saying that the group might recharter
to add these capabilities, then that gives you more space to expand on
part 1, which I think is lacking in detail.

--

This list in part 1 raises quite a few questions for me:

"connection establishment, stream multiplexing, data reliability, loss
detection and recovery, congestion control, and negotiation"

How is data reliability different to loss detection and recovery?

Are we talking about adding features like SCTP has with respect to
partial reliability?  HTTP doesn't need it, but I've heard of grand
plans to do real-time media over this abstraction.  Framing of that in
the charter is probably much harder than the actual technical work
needed to define such things.

What, if any, effort is this group going to put into defining a
congestion control mechanism as opposed to just picking one (or more)
existing mechanisms?  Can we push this more toward just picking
something, maybe allowing for a few tweaks?

And what is being negotiated?

--

I would recommend removing or reducing the following statement: "It
will also provide a threat model description specific to connection
resumption, along with a description for denial-of-service
mitigations."  The threat model should be a little more comprehensive
than just resumption, but we have a great deal of analysis for
existing and similar protocols.  It's unclear what additional work
would be required, and it might be the case that we don't want to
write that all down. Moreover, this implies a narrower scope than
necessary.

The denial of service aspects are important, but do we really need to
write those into a charter?  I notice that we aren't writing down
operational concerns, which are also considerable.

---

From: Yoav Nir <[email-masked]>
Date: Sun, 15 May 2016 21:21:14 +0300

> On 15 May 2016, at 7:18 PM, Ted Hardie <[email-masked]> wrote:
> 
> Hi Yoav,
> 
> On Sun, May 15, 2016 at 2:08 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
> Hi, Ted
> 
> That's not the intent--the change control will shift to the working group as normal.  We tried to capture that with this language:
> 
> "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's taken from how the HTTPbis work handled the input documents to HTTP/2.

That’s fine. I think what’s bothering me is that the experiment, the (potential) working group and the output product are all called the same thing.  In HTTPbis it was clearer that SPDY was the experiment and HTTP/2 was the output.

But with that clarification, it seems ready-to-go to me as well, though I agree with Martin that we don’t need to spell out specific security considerations like DoS in the charter.

Yoav

---

From: Salvatore Loreto <[email-masked]>
Date: Sun, 15 May 2016 19:32:50 +0000

Hi Ted

I thinks the charter looks OK,
However I tend to agree with previous comments
that the work at moment should really focused on (narrowed to) the first and second parts to the design of QUIC as transport protocol

for the third focus
I have some concerns of the wg doing at same time the work for designing the transport protocol and describing
“mappings between specific applications’ semantics and the transport facilities of QUIC”

For the fourth focus I don’t think the experimentation has showed so far enough interesting results deserving to be standardized.

Cheers
Salvatore

From: QUIC [mailto:[email-masked]] On Behalf Of Ted Hardie
Sent: den 14 maj 2016 01:27
To: [email-masked]; Jana Iyengar; Christian Huitema
Subject: [QUIC] Draft charter

Howdy,

regards,
Ted

---

From: Christian Huitema <[email-masked]>
Date: Sun, 15 May 2016 20:51:46 +0000

> “mappings between specific applications’ semantics and the transport facilities of QUIC”

We certainly need to specify the mapping with HTTP 2. But with HTTP the client always sends the first message, and that creates an "experimentation gap." In short, HTTP will use 0-RTT and 1-RTT data, but not 0.5-RTT data. That's only exercised by applications for which the server sends the first message. I don't care much which of these applications we look at, but we should pick one, just for closing the experimentation gap. Maybe FTP

> For the fourth focus I don’t think the experimentation has showed so far enough interesting results deserving to be standardized.

Again, we need to consider at least one experimentation, if only to test the extension mechanisms.

-- Christian Huitema

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 15 May 2016 14:35:34 -0700

On Sun, May 15, 2016 at 1:51 PM, Christian Huitema <[email-masked]>
wrote:

> > that the work at moment should really focused on (narrowed to) the first
> and second parts to the design of QUIC as transport protocol
> >
> > for the third focus
> We certainly need to specify the mapping with HTTP 2. But with HTTP the
> client always sends the first message, and that creates an "experimentation
> gap." In short, HTTP will use 0-RTT and 1-RTT data, but not 0.5-RTT data.
> That's only exercised by applications for which the server sends the first
> message. I don't care much which of these applications we look at, but we
> should pick one, just for closing the experimentation gap. Maybe FTP
>

What about relaxing the HTTP profile to allow server push immediately upon
connection?

-Ekr

> > For the fourth focus I don’t think the experimentation has showed so far
> enough interesting results deserving to be standardized.
>

---

From: Martin Thomson <[email-masked]>
Date: Sun, 15 May 2016 20:32:28 -0400

> What about relaxing the HTTP profile to allow server push immediately upon

That doesn't work particularly well unless you associate the push with
a request, but I'm sure that we can work something out.

I don't know if the settings that HTTP/2 sends are considerable enough
that we can claim to be using 0.5-RTT data, but they are something
that a server can send.  Maybe Christian wants to find something with
which the pipe can be filled, in which case pushing seems like a
plausible option.

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 15 May 2016 22:00:32 -0700

Martin,

Responses inline.

> hard and a smaller scope helps maintain focus.

It should be clear  but it's worth clarifying that the FEC item is not
about FEC schemes, but about identifying and specifying core protocol
mechanisms that will be required to allow FEC schemes to be used by QUIC.
That said, I'm on the fence about requiring a re-charter for FEC; and I
would very much like to hear more voices on this question.

> part 1, which I think is lacking in detail.

(Assuming the specific details you are asking about are the ones listed
below.)

They aren't functionally different. But I think it's worth calling out loss
detection and recovery mechanisms separately, since most modern loss
detection and recovery mechanisms are all about performance. Specifically,
RFC 793 specifies a completely reliable TCP, and it specifies a
retransmission timeout as the mechanism for loss detection and recovery.
Pretty much all of loss detection and recovery mechanisms built since 1981
(NewReno, FR, ER, TLP, F-RTO) fall under the category of performance
optimizations of this reliability function. I think it's worth calling that
out separately, since we'll need to specify how to get these (and more)
performance optimizations in loss detection and recovery with QUIC as well.

> needed to define such things.

This charter does not propose SCTP-style packet-level partial reliability
at the moment.

> something, maybe allowing for a few tweaks?

At the moment, the charter deliberately does not mention defining or
negotiating a congestion control mechanism. My specific expectation was
that we'd end up defining a NewReno-style CC as a (non-mandatory) default,
since it is one CC that will probably need to be specified for QUIC. That
said, CC is largely a sender-side concern, and with a reasonable ack
mechanism, a sender can unilaterally implement quite a diverse set of CC
mechanisms. Folks will ultimately use whatever CC they want with QUIC, just
as they do with TCP -- I expect CC in QUIC deployments to be at least as
diverse as it is for TCP now. Do you think something should be added to the
charter to clarify that the wg is expected to map existing TCP CC onto QUIC
and not define new CC mechanisms?

> And what is being negotiated?

It was supposed to be a placeholder for negotiating QUIC version, in
addition to any transport extensions (multipath) that may need negotiation.
How about we change it to just "version negotiation" and deal with other
negotiation needs as we encounter them?

--
> operational concerns, which are also considerable.

That's fair. I'm comfortable removing that statement.

Thanks much!
- jana

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 15 May 2016 22:18:43 -0700

To concerns about multipath in the fourth area: TSVAREA has done multipath
in SCTP and in MPTCP. MPTCP is seeing deployment -- albeit slowly and in
limited quarters -- and I would argue that expecting multipath to be a
facility available as a part of a brand new transport seems quite
reasonable.

Mechanisms for enabling FEC are a bit more experimental, so I'm more
comfortable moving this item to requiring a re-charter.

On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto <
[email-masked]> wrote:

> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Ted Hardie
> *Sent:* den 14 maj 2016 01:27
> *To:* [email-masked]; Jana Iyengar; Christian Huitema
> *Subject:* [QUIC] Draft charter
>
>
>
> Howdy,
>

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 15 May 2016 22:33:14 -0700

Salvatore,

> “mappings between specific applications’ semantics and the transport

The thinking was that it's helpful to have an application mapping going on
in parallel to ensure that we don't miss any important gotchas while
specifying the transport and its interfaces... and HTTP/2 is the only
application that QUIC has any real deployment experience with so far, so
specifying it alongside the transport seemed natural.

As a high-order point, I tend to think that having no application use-case
for a transport is equivalent to having all applications as use-cases for
the transport, since it quickly becomes difficult to tell which facilities
are important for the transport and which ones are not.

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Sun, 15 May 2016 22:58:10 -0700

> which the pipe can be filled, in which case pushing seems like a

You've identified an outcome of the choice of HTTP/2 as the first
application on the charter. I'm sure that as we start talking about more
applications, we are likely to find additional tweaks that we'd want to
start making to accomodate those use cases. I'm wary of simply adding
features to the charter that might become hurdles to getting to first
application use-cases. Is there another application that we think is
important enough that we add as additional first application use-cases to
the charter?

I'd prefer that we keep a tight application-set to start with, which at the
moment is {HTTP/2}, and then re-charter to add more as the initial specs
mature.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 16 May 2016 16:18:10 +1000

> On 16 May 2016, at 4:21 AM, Yoav Nir <[email-masked]> wrote:
> 

I tend to agree with Yoav's concern; it will be easier to manage perceptions both inside and outside of the IETF if there's a clear distinction between the experiment and the standard (it was certainly helpful in H2).

That said, I fear the inevitable bikeshed.

Cheers,

--
Mark Nottingham   https://www.mnot.net/

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 16 May 2016 09:18:49 +0000

Thru
but with the difference that the work been done so far in TSVAREA (i.e. SCTP and Multipath TCP) is for connection oriented
transport protocols.
don’t get me wrong I do think a brand new transport protocol should (actually has to) include the multipath facility and have it
actually as a native one.  Indeed I would like to see the multipath item expanded and explained more in the charter.

My comment was mainly for FEC, and moving this item to requiring a re-charter would make me more comfortable with
the charter for the BoF

From: Jana Iyengar [mailto:[email-masked]]
Sent: den 16 maj 2016 07:19
To: Salvatore Loreto
Cc: Ted Hardie; [email-masked]; Christian Huitema
Subject: Re: [QUIC] Draft charter

To concerns about multipath in the fourth area: TSVAREA has done multipath in SCTP and in MPTCP. MPTCP is seeing deployment -- albeit slowly and in limited quarters -- and I would argue that expecting multipath to be a facility available as a part of a brand new transport seems quite reasonable.

Mechanisms for enabling FEC are a bit more experimental, so I'm more comfortable moving this item to requiring a re-charter.

On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto <[email-masked]<mailto:[email-masked]>> wrote:
Hi Ted

for the third focus

Cheers
Salvatore

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ted Hardie
Sent: den 14 maj 2016 01:27
To: [email-masked]<mailto:[email-masked]>; Jana Iyengar; Christian Huitema
Subject: [QUIC] Draft charter

Howdy,

regards,
Ted

---

From: Michael Tuexen <[email-masked]>
Date: Mon, 16 May 2016 11:30:03 +0200

> On 16 May 2016, at 07:18, Jana Iyengar <[email-masked]> wrote:
> 
> To concerns about multipath in the fourth area: TSVAREA has done multipath in SCTP and in MPTCP. 
There is a difference here:
* For SCTP this work was done only for redundancy, not for load sharing. The CMT work
  wasn't accepted as a work item in TSVWG.
* For MTPTCP, multipath for load sharing and redundancy was considered.
> MPTCP is seeing deployment -- albeit slowly and in limited quarters -- and I would argue that 
The initial deployment target for SCTP are signalling networks. As far as I know,
multipath support for redundancy is deployed there.
As far as I know the deployment for MPTCP within the Siri context also focuses on
the redundancy part. Other deployments use the load sharing part.

Another use-case, where MPTCP is used, is the one of transport layer mobility, where
the end-point can change its IP-addresses and/or port numbers. This is supported by
MPTCP, SCTP with dynamic address reconfiguration (including UDP encapsulation) and also by QUIC.

Best regards
Michael
> expecting multipath to be a facility available as a part of a brand new transport seems quite reasonable.
> 
> On Sun, May 15, 2016 at 12:32 PM, Salvatore Loreto <[email-masked]> wrote:
> Hi Ted
> 
>  
>

---

From: "Maxim Proshin [GMAIL]" <[email-masked]>
Date: Mon, 16 May 2016 22:52:45 +0400

Hi,

There is nothing about QUIC API in the charter. Will the group work on it?

Best regards,
Maxim

-- 
BR, Maxim

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 May 2016 16:33:09 -0400

On 16 May 2016 at 01:00, Jana Iyengar <[email-masked]> wrote:
> It should be clear  but it's worth clarifying that the FEC item is not about
> FEC schemes, but about identifying and specifying core protocol mechanisms
> that will be required to allow FEC schemes to be used by QUIC. That said,
> I'm on the fence about requiring a re-charter for FEC; and I would very much
> like to hear more voices on this question.

Ack.  I just don't see it as baked.  Maybe you can convince me
otherwise, but I don't want to embark upon this without some amount of
certainty.

> Do you think something should be added to the charter to
> clarify that the wg is expected to map existing TCP CC onto QUIC and not
> define new CC mechanisms?

Yes, that would help a great deal.

> negotiation needs as we encounter them?

Yes.

> moment is {HTTP/2}, and then re-charter to add more as the initial specs

I would also prefer this.  A narrow scope maximizes chances of success.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 May 2016 23:42:26 +0300

> On 16 May 2016, at 9:52 PM, Maxim Proshin [GMAIL] <[email-masked]> wrote:
> 
> Hi,
> 

We’re still discussing the charter. Do you want the group to work on it?  Are you proposing to write an API draft?  Are you volunteering to write it?

The IETF has written APIs before. We mostly avoid it when possible.

Yoav

---

From: Martin Thomson <[email-masked]>
Date: Mon, 16 May 2016 16:45:39 -0400

> We’re still discussing the charter. Do you want the group to work on it?  Are you proposing to write an API draft?  Are you volunteering to write it?

The API is exactly the HTTP API if we narrow the scope as has been suggested.

---

From: Yoav Nir <[email-masked]>
Date: Mon, 16 May 2016 23:52:38 +0300

> On 16 May 2016, at 11:45 PM, Martin Thomson <[email-masked]> wrote:
> 

HTTP runs over TCP, so some of the tweaking you can do to TCP is not in the HTTP API but in socket options.

QUIC runs over UDP, so many of the flow control attributes have to be part of the QUIC API, because UDP doesn’t have flow control. This is mostly the stuff in sections 9 and 10 of draft-tsvwg-quic-protocol.

Yoav

---

From: Michael Thornburgh <[email-masked]>
Date: Mon, 16 May 2016 21:22:28 +0000

> From: QUIC [mailto:[email-masked]] On Behalf Of Martin Thomson
> Sent: Monday, May 16, 2016 1:33 PM
[...]
> I would also prefer this.  A narrow scope maximizes chances of success.

i agree; however, other potential uses should be kept in mind (ideally everybody's minds) so that the design isn't painted into an unfortunate corner.

if the eventual goal is to also support real-time media, partial reliability, and other things, there are things in draft-tsvwg-quic-protocol that i would do very differently (and did do very differently, see RFC 7016, in particular Section 1.1).

-mike

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 May 2016 18:13:37 -0700

On Mon, May 16, 2016 at 2:18 AM, Salvatore Loreto <
[email-masked]> wrote:

>
>
> Thru
>
> but with the difference that the work been done so far in TSVAREA (i.e.
> SCTP and Multipath TCP) is for connection oriented
>
> transport protocols.
>
> don’t get me wrong I do think a brand new transport protocol should
> (actually has to) include the multipath facility and have it
>
> actually as a native one.  Indeed I would like to see the multipath item
> expanded and explained more in the charter.
>

I don't think the multipath work would be much different since QUIC is
connection-oriented as well.

My comment was mainly for FEC, and moving this item to requiring a
> re-charter would make me more comfortable with
>
> the charter for the BoF
>

Got it. That seems to be the emerging view at this point, so we may well
end up there.

- jana

>
>
>
>
>
>
> *From:* Jana Iyengar [mailto:[email-masked]]
> *Sent:* den 16 maj 2016 07:19
> *To:* Salvatore Loreto
> *Cc:* Ted Hardie; [email-masked]; Christian Huitema
> *Subject:* Re: [QUIC] Draft charter
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 May 2016 18:57:18 -0700

On Mon, May 16, 2016 at 1:42 PM, Yoav Nir <[email-masked]> wrote:

> We’re still discussing the charter. Do you want the group to work on it?
> Are you proposing to write an API draft?  Are you volunteering to write it?
>

+1. I'm comfortable leaving it out for now, and re-chartering to include it
if the wg has a burning desire to work on it.

- jana

---

From: Erik Nygren <[email-masked]>
Date: Mon, 16 May 2016 22:13:30 -0400

On Mon, May 16, 2016 at 5:22 PM, Michael Thornburgh <[email-masked]>
wrote:

>
> i agree; however, other potential uses should be kept in mind (ideally
> everybody's minds) so that the design isn't painted into an unfortunate
> corner.
>
> if the eventual goal is to also support real-time media, partial
> reliability, and other things, there are things in
> draft-tsvwg-quic-protocol that i would do very differently (and did do very
> differently, see RFC 7016, in particular Section 1.1).

I agree, and I think it's worth keeping "considering extensibility to
enable future FEC and partial reliability" in the charter even if they are
explicitly not work items initially.  Having the extensibility hooks to
enable them in the future will be important as if we don't consider hooks
for them in the future, it may be hard to retrofit the back in.  I think
many of the interesting future benefits from QUIC will come from being able
to add things like this in down the road.

    Erik

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 May 2016 19:24:39 -0700

On Mon, May 16, 2016 at 1:52 PM, Yoav Nir <[email-masked]> wrote:

> >> We’re still discussing the charter. Do you want the group to work on
> it?  Are you proposing to write an API draft?  Are you volunteering to
> write it?
> >

As Yoav alludes, there is the question of the transport API to HTTP ---
basically the QUIC equivalent of the socket API for TCP or SCTP. That said,
the socket API is usually Informational (see RFC 6458
<https://tools.ietf.org/html/rfc6458> as an example), since most
traditional transport implementations live in the kernel. Since the
expectation is that QUIC will mostly have userspace implementations, the
interaction model (sync/async, push/pull) will depend on the specific
implementations of both QUIC and the application. Given that we don't even
have a sockets framework (which defines a very specific interaction model)
to operate in, I'm not sure how specific this API between QUIC and the
application can be.

My instinct is to deal with it if/when the need arises. I'm willing to be
convinced otherwise... I suppose we could do a functional API in the spirit
of what was defined for TCP in RFC 793
<https://tools.ietf.org/html/rfc793#section-3.8>.

- jana

HTTP runs over TCP, so some of the tweaking you can do to TCP is not in the
> HTTP API but in socket options.
>
> QUIC runs over UDP, so many of the flow control attributes have to be part
> of the QUIC API, because UDP doesn’t have flow control. This is mostly the
> stuff in sections 9 and 10 of draft-tsvwg-quic-protocol.
>
> Yoav
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 May 2016 19:50:08 -0700

> to add things like this in down the road.

I definitely agree with the general sentiment. I had hoped that having
multipath (as an extension) in the charter allows us to specify these
"extensibility mechanisms", which can be exercised later for other features
such as FEC and partial reliability.  If you think it's helpful to call out
extensibility explicitly, can you suggest text?

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 16 May 2016 20:03:43 -0700

> everybody's minds) so that the design isn't painted into an unfortunate

I agree... though I find it hard to word this into the charter.

> differently, see RFC 7016, in particular Section 1.1).

QUIC running code and deployment experience is limited to HTTP/2 at this
point, which is why early focus is limited to the initial application-set.
I think this wg will need to walk the fine line between over-engineering
for the initial application-set and becoming a kitchen sink for any/all
applications. We may well learn later that to support a new application
(real-time media, say) we may need to modify mechanisms in the core
protocol spec, but that still seems like a better process for keeping the
wg coherent.

- jana

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 May 2016 13:31:06 +1000

Hi Ted,

Thanks for proposing a draft charter early.

A few comments:

> The first of these is the core transport work, which will describe the wire format, along with the mechanisms for connection establishment, stream multiplexing, data reliability, loss detection and recovery, congestion control, and negotiation.

What is "negotiation" in this context? Is it just QUIC versioning, or is it also a functional equivalent to ALPN (i.e., negotiation of the application protocol carried), or is it more like HTTP/2 SETTINGS (which is not really a negotiation mechanism, it's more like a configuration advertisement)?

> 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. Upon completion of that mapping, additional protocols may be added by updating this charter to include them.

Defining application protocols in the Transport area is a pretty big change around here, even if it is just mapping existing semantics to a new transport. 

As everyone knows, such mappings are "leaky" -- changes under the hood can and will affect how people use the application. We had numerous examples of this in H2, and while QUIC appears to be a more straightforward change in this respect, it's still easy enough to have unintended side effects. HTTP is especially fragile in this regard, because of its complexity, history and breadth of use.

Note that I'm not saying I'm firmly against this approach, just concerned; this WG is obviously going to be very deep in transport discussions, and it would be easy to lose the application perspective in it. 

So, can you speak to why you chose to propose this avenue, rather than doing the application mappings in ART groups? In other words, HTTP and other TCP-based protocols have been successfully defined in APPS (later ART) WGs until now; why is QUIC different?

Also, if this WG *is* to do the HTTP/2 mapping, more text about what semantics are being mapped would avoid a lot of argument down the road; if you say it's "all of them", that includes running HTTP without TLS.

> Milestones

It would be helpful to also propose the timing of the milestones, perhaps in the form of "date of chartering + n months."

HTTP/2 was chartered to ship to the IESG in two years, and we only overshot that goal by sixteen days (if memory serves correctly). 

I don't think QUIC will go so... speedily? However, it's good to have goals, and to get consensus within the group as to how seriously it takes them. Getting experienced engineers to commit to an unbounded timeline (or one that everyone knows isn't serious) is hard, and IMO effects the quality of the work. 

Cheers,

---

From: Christian Huitema <[email-masked]>
Date: Tue, 17 May 2016 06:39:31 +0000

On Monday, May 16, 2016 5:31 PM, Mark Nottingham wrote: 
> ...
> What is "negotiation" in this context? Is it just QUIC versioning, or is it also a
> functional equivalent to ALPN (i.e., negotiation of the application protocol
> carried), or is it more like HTTP/2 SETTINGS (which is not really a negotiation
> mechanism, it's more like a configuration advertisement)?

There is versioning, but that's a blunt instrument. My personal model is more about TCP Option, which over time allowed the introduction of time stamps, selective acknowledgements, or multipath parameters, An equivalent for QUIC would be experimentation with options for forward error correction or multipath.

-- Christian Huitema

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 17 May 2016 08:21:24 +0000

On congestion control (<ms>)…

At the moment, the charter deliberately does not mention defining or negotiating a congestion control mechanism. My specific expectation was that we'd end up defining a NewReno-style CC as a (non-mandatory) default, since it is one CC that will probably need to be specified for QUIC. That said, CC is largely a sender-side concern, and with a reasonable ack mechanism, a sender can unilaterally implement quite a diverse set of CC mechanisms. Folks will ultimately use whatever CC they want with QUIC, just as they do with TCP -- I expect CC in QUIC deployments to be at least as diverse as it is for TCP now. Do you think something should be added to the charter to clarify that the wg is expected to map existing TCP CC onto QUIC and not define new CC mechanisms?

<ms> I’d like to see some statement like this in the charter, i.e., that new CC mechanisms are not in scope (or require re-chartering).

<ms> In general, I think the charter has to be a bit more explicit about congestion control and “TCP-friendliness”. Experimenting with CC should be simpler in a user-space protocol implementation. This is both a research opportunity, but also an operational risk. Re-use of TCP algorithms, as far as applicable, could reduce the latter.

Michael

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 May 2016 12:23:25 -0700

Thanks, Mark. Responses inline:

On Mon, May 16, 2016 at 8:31 PM, Mark Nottingham <[email-masked]> wrote:

> > The first of these is the core transport work, which will describe the
> wire format, along with the mechanisms for connection establishment, stream
> multiplexing, data reliability, loss detection and recovery, congestion
> control, and negotiation.
>
> What is "negotiation" in this context? Is it just QUIC versioning, or is
> it also a functional equivalent to ALPN (i.e., negotiation of the
> application protocol carried), or is it more like HTTP/2 SETTINGS (which is
> not really a negotiation mechanism, it's more like a configuration
> advertisement)?
>

This was supposed to be just QUIC versions. I'm changing the charter text
to say "version negotiation."
(HTTP/2 SETTINGS, though orthogonal to the negotiation described in the
charter, is useful, and is something that may be worth having in QUIC.)

> 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. Upon completion of that
> mapping, additional protocols may be added by updating this charter to
> include them.
>
>
> Defining application protocols in the Transport area is a pretty big
> change around here, even if it is just mapping existing semantics to a new
> transport.
>
> As everyone knows, such mappings are "leaky" -- changes under the hood can
> and will affect how people use the application. We had numerous examples of
> this in H2, and while QUIC appears to be a more straightforward change in
> this respect, it's still easy enough to have unintended side effects. HTTP
> is especially fragile in this regard, because of its complexity, history
> and breadth of use.
>
> Note that I'm not saying I'm firmly against this approach, just concerned;
> this WG is obviously going to be very deep in transport discussions, and it
> would be easy to lose the application perspective in it.
>
> So, can you speak to why you chose to propose this avenue, rather than
> doing the application mappings in ART groups? In other words, HTTP and
> other TCP-based protocols have been successfully defined in APPS (later
> ART) WGs until now; why is QUIC different?
>

I can share my thinking, I'm sure Ted will share his too. My first reason
was that having application(s) that intend to use the transport in the same
wg helps guide transport conversations, and helps define scope. It wasn't
to take the work out of ART as much as it was to bring in a guide to the
TSVAREA work. That said, ART, perhaps specifically HTTPBIS, should be
strongly involved in the mapping document for all the reasons you point
out. If the right way to do this is to move the doc to a home in ART, I'm
not strongly opposed to it. I would still want to have HTTP/2 in the QUIC
charter for the TSV work.

My second reason was to have ART mindshare present in the wg discussions.
The work you point out as having been done in ART largely uses a
pre-fabricated transport (TCP for HTTP, SCTP for WebRTC). QUIC is about to
be defined, and that does make it different from this past work, since the
mapping document will evolve as QUIC in the wg does.

I'm not against moving the mapping doc to a different home in ART.
Alternatively, we could also consider an ART liaison to this wg, just as we
are proposing a SAAG liaison for the TLS1.3 mapping document.

Also, if this WG *is* to do the HTTP/2 mapping, more text about what
> semantics are being mapped would avoid a lot of argument down the road; if
> you say it's "all of them", that includes running HTTP without TLS.
>

Fair point. (I was going to say "all of them" :-)) Since QUIC itself is
being proposed as an encrypted transport, the proposed mapping is limited
to HTTPS (I can add some text to this effect.) Are you looking for other
specificity in terms of HTTP/2 semantics?

> > Milestones
>
> It would be helpful to also propose the timing of the milestones, perhaps
> in the form of "date of chartering + n months."
>
> HTTP/2 was chartered to ship to the IESG in two years, and we only
> overshot that goal by sixteen days (if memory serves correctly).
>
> I don't think QUIC will go so... speedily? However, it's good to have
> goals, and to get consensus within the group as to how seriously it takes
> them. Getting experienced engineers to commit to an unbounded timeline (or
> one that everyone knows isn't serious) is hard, and IMO effects the quality
> of the work.

Agreed. I love that HTTP/2 delivered so close to the originally proposed
timeline. As you point out though, QUIC is a much deeper cut, which tends
to increase both the the length and variance of expected completion times.
Nevertheless, your point is  taken. We can come up with some milestones,
and have the list bash them.

- jana

Cheers,

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 May 2016 12:31:23 -0700

On Mon, May 16, 2016 at 11:39 PM, Christian Huitema <[email-masked]>
wrote:

> it also a
> There is versioning, but that's a blunt instrument. My personal model is
> more about TCP Option, which over time allowed the introduction of time
> stamps, selective acknowledgements, or multipath parameters, An equivalent
> for QUIC would be experimentation with options for forward error correction
> or multipath.

These are two different things in my mental model, and they're both useful.
The version tells you how to interpret the basic wire format, and
importantly allows you to change the wire format; options is for feature
negotiation. I think it's important for us to have an options negotiation
mechanism as well. Do you think this is worth calling out explicitly
("version negotiation, and feature negotiation")?

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 May 2016 12:40:09 -0700

On Tue, May 17, 2016 at 1:21 AM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> <ms> I’d like to see some statement like this in the charter, i.e., that
> new CC mechanisms are not in scope (or require re-chartering).
>

Thanks -- I'm adding text to the charter to say this.

> <ms> In general, I think the charter has to be a bit more explicit about
> congestion control and “TCP-friendliness”. Experimenting with CC should be
> simpler in a user-space protocol implementation. This is both a research
> opportunity, but also an operational risk. Re-use of TCP algorithms, as far
> as applicable, could reduce the latter.
>

I think this probably belongs in the protocol spec where we define a basic
default CC for QUIC (which I expect will be a mapping of major parts RFC
5681 to QUIC.) I don't think this belongs in the charter, since the plan is
to not have new CC be defined in this wg.

- jana

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 17 May 2016 22:02:52 +0200

Jana,
>
>     <ms> In general, I think the charter has to be a bit more explicit
>     about congestion control and “TCP-friendliness”. Experimenting with
>     CC should be simpler in a user-space protocol implementation. This
>     is both a research opportunity, but also an operational risk. Re-use
>     of TCP algorithms, as far as applicable, could reduce the latter.
>
>
> I think this probably belongs in the protocol spec where we define a
> basic default CC for QUIC (which I expect will be a mapping of major
> parts RFC 5681 to QUIC.) I don't think this belongs in the charter,
> since the plan is to not have new CC be defined in this wg.

I think that it is useful to mention in the charter that the WG will not 
design a new Congestion Control scheme but simply adapt the existing TCP 
and Multipath TCP congestion control schemes to QUIC.

Olivier

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 May 2016 15:10:42 -0700

Olivier,

> and Multipath TCP congestion control schemes to QUIC.

Agreed. I was specifically speaking to not saying anything about
"TCP-friendliness" since this wg will not be defining new CC algorithms.

- jana

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 18 May 2016 09:40:51 +1000

> On 18 May 2016, at 8:10 AM, Jana Iyengar <[email-masked]> wrote:
> 
> Agreed. I was specifically speaking to not saying anything about "TCP-friendliness" since this wg will not be defining new CC algorithms.

Along those lines, it's often good to have an explicit "Out of Scope" section in the charter, listing the various potential ratholes / diversions that the WG shouldn't go down.

Cheers,

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 May 2016 16:42:44 -0700

On Tue, May 17, 2016 at 4:40 PM, Mark Nottingham <[email-masked]> wrote:

> Along those lines, it's often good to have an explicit "Out of Scope"
> section in the charter, listing the various potential ratholes / diversions
> that the WG shouldn't go down.

Great suggestion. I'll give it a shot.

- jana

Cheers,

---

From: Christian Huitema <[email-masked]>
Date: Wed, 18 May 2016 00:04:04 +0000

On Tuesday, May 17, 2016 9:31 AM, Jana Iyengar wrote:
> On Mon, May 16, 2016 at 11:39 PM, Christian Huitema <mailto:[email-masked]> wrote:
>> There is versioning, but that's a blunt instrument. My personal model is more 
>> about TCP Option, which over time allowed the introduction of time stamps, 
>> selective acknowledgements, or multipath parameters, An equivalent for QUIC 
>> would be experimentation with options for forward error correction or multipath.
>
> These are two different things in my mental model, and they're both useful. The version
> tells you how to interpret the basic wire format, and importantly allows you to change
> the wire format; options is for feature negotiation. I think it's important for us to have an 
> options negotiation mechanism as well. Do you think this is worth calling out explicitly

It probably would not hurt, if that is not too unwieldy. 

-- Christian Huitema

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 17 May 2016 17:06:39 -0700

> It probably would not hurt, if that is not too unwieldy.

Ack.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sat, 21 May 2016 06:26:56 +0000

Is it planned to discuss potential privacy implications of the „QUIC connection identifier“ (also named “clear text super cookie” on the SPUD list)?

Thanks

Michael

From: QUIC [mailto:[email-masked]] On Behalf Of EXT Ted Hardie
Sent: Saturday, May 14, 2016 1:27 AM
To: [email-masked]; Jana Iyengar; Christian Huitema
Subject: [QUIC] Draft charter

Howdy,

regards,
Ted

---

From: Ryan Hamilton <[email-masked]>
Date: Sat, 21 May 2016 06:55:56 -0700

Definitely.

On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> Is it planned to discuss potential privacy implications of the „QUIC
> connection identifier“ (also named “clear text super cookie” on the SPUD
> list)?
>
>
>
> Thanks
>
>
>
> Michael
>
>
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *EXT Ted Hardie
> *Sent:* Saturday, May 14, 2016 1:27 AM

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 21 May 2016 09:04:44 -0700

That's a design element that should and will definitely be discussed in the
WG.

Specifically this applies to use of connection IDs during multipath, and I
expect that conversation to happen when we discuss multipath.

---

From: Jana Iyengar <[email-masked]>
Date: Sat, 21 May 2016 20:20:18 -0700

Michael,

Just caught up on the SPUD thread, and I'd like to correct something you
said there that I'll quote here for context:
*"if there is now a new clear text identifier that just happens to be
unique per subscriber. What a great improvement for privacy in the
Internet! And even better that it seems compatible with QUIC..."*

QUIC's connection ID is NOT unique per subscriber. It's per connection. As
I said on the other thread, in the single-path case, it reveals no more
informtion than TCP. In the multipath case, it effectively reveals no more
than MPTCP, since the ID is used to tie the multiple, using MPTCP
parlance, "sub-flows", together. It is possible to consider a different
design that uses multiple connection IDs for the multiple sub-flows, but to
be clear, that makes this new multipath strictly better than MPTCP at
privacy-preservation.

At any rate, I wanted to make sure that we're talking about the same issue.
I'll also note that it's plain wrong to use the term "clear text super
cookie" in relation to the QUIC connection ID (see
https://www.techopedia.com/definition/27310/super-cookie for what I think a
supercookie is.)

- jana

On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <[email-masked]> wrote:

> That's a design element that should and will definitely be discussed in
> the WG.
>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 22 May 2016 03:44:04 +0000

Just to be clear, I did use the term “super cookie” in the context of multi-path and mobility. That was triggered by the SPUD discussion, during which a proposition surfaced to use a QUIC-like connection ID for mobility and multipath, and to standardize that as part of the SPUD header. I think using the same statistically unique 64-bit number in the clear text envelope of packets sent from different IP addresses is a really bad idea. It is a bad idea for MP-TCP, and it would be bad idea for QUIC or SPUD.

I do agree with Jana and Ryan that there is no such problem if the unique number is only used for a single pair of source and destination addresses. And I also agree that the proper time to study privacy-preserving multipath mechanisms is during the study of multipath.

-- Christian Huitema

From: QUIC [mailto:[email-masked]] On Behalf Of Jana Iyengar
Sent: Saturday, May 21, 2016 5:20 PM
To: Ryan Hamilton <[email-masked]>
Cc: Scharf, Michael (Nokia - DE) <[email-masked]>; [email-masked]
Subject: Re: [QUIC] QUIC privacy impact

Michael,

Just caught up on the SPUD thread, and I'd like to correct something you said there that I'll quote here for context:
"if there is now a new clear text identifier that just happens to be unique per subscriber. What a great improvement for privacy in the Internet! And even better that it seems compatible with QUIC..."

QUIC's connection ID is NOT unique per subscriber. It's per connection. As I said on the other thread, in the single-path case, it reveals no more informtion than TCP. In the multipath case, it effectively reveals no more than MPTCP, since the ID is used to tie the multiple, using MPTCP parlance, "sub-flows", together. It is possible to consider a different design that uses multiple connection IDs for the multiple sub-flows, but to be clear, that makes this new multipath strictly better than MPTCP at privacy-preservation.

At any rate, I wanted to make sure that we're talking about the same issue. I'll also note that it's plain wrong to use the term "clear text super cookie" in relation to the QUIC connection ID (see https://www.techopedia.com/definition/27310/super-cookie for what I think a supercookie is.)

- jana

On Sat, May 21, 2016 at 9:04 AM, Jana Iyengar <[email-masked]<mailto:[email-masked]>> wrote:

That's a design element that should and will definitely be discussed in the WG.

Specifically this applies to use of connection IDs during multipath, and I expect that conversation to happen when we discuss multipath.
On May 21, 2016 6:56 AM, "Ryan Hamilton" <[email-masked]<mailto:[email-masked]>> wrote:
Definitely.

On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
Is it planned to discuss potential privacy implications of the „QUIC connection identifier“ (also named “clear text super cookie” on the SPUD list)?

Thanks

Michael

From: QUIC [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of EXT Ted Hardie
Sent: Saturday, May 14, 2016 1:27 AM
To: [email-masked]<mailto:[email-masked]>; Jana Iyengar; Christian Huitema
Subject: [QUIC] Draft charter

Howdy,

regards,
Ted

_______________________________________________
QUIC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/quic

_______________________________________________
QUIC mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/quic

---

From: Göran Eriksson AP <[email-masked]>
Date: Sun, 22 May 2016 07:43:27 +0000

>I do agree with Jana and Ryan that there is no such problem if the unique
>number is only used for a single pair of source and destination
>addresses. 

So if the device move into an area with a new network and obtains another
host address, then a new connection id would be created by the client?

draft-tsvwg-quic-protocol-02 claims the connection id remain the same even
during migration: “QUIC can survive IP address changes and NAT
   re-bindings since the Connection ID remains the same across these
migrations.”. 

This does not fit together does it?

I must be missing something...

>And I also agree that the proper time to study privacy-preserving
>multipath mechanisms is during the study of multipath.

+1 And when considering the increased attention to end user privacy and
security in IETF and W3C, this may mean a renewed look at the these
aspects of multi path not covered in previous security considerations.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 22 May 2016 17:32:30 +0000

draft-tsvwg-quic-protocol-02 says:

  QUIC connections are identified by a 64-bit Connection ID, randomly
   generated by the client.  QUIC can survive IP address changes and NAT
   re-bindings since the Connection ID remains the same across these
   migrations.

So, can we agree that this statement is very, very vague?

For instance, could I write a QUIC implementation compliant to draft-tsvwg-quic-protocol-02 that e.g. uses a static and a random part of the connection ID, and e.g. stores the static part permanently on the user’s computer? Or, could I pick as a static part the MAC address? The total ID would still be random. I have difficulties to understand how this sort of ID generation would be different from a “clear text super cookie” and what is defined in the reference you provide.

I am sure that this is not what the current QUIC implementation does. But since we are in IETF context, talking about a potential standard, I am concerned what other implementers of a new protocol could do, and what use cases they could find for this ID.

And if there was some interesting use of having an entirely user-defined clear text value at some constant offset in the packet, for a widely used Internet transport protocol, I am pretty sure some implementers would not care about some MUSTs in an RFC saying “please, please, please select every bit in the ID randomly”.

Or do I miss something obvious?

Michael

From: Jana Iyengar [mailto:[email-masked]]
Sent: Sunday, May 22, 2016 5:20 AM
To: Ryan Hamilton
Cc: [email-masked]; Scharf, Michael (Nokia - DE)
Subject: Re: [QUIC] QUIC privacy impact

Michael,

- jana

Thanks

Michael

Howdy,

regards,
Ted

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 22 May 2016 17:33:36 +0000

Well, I believe this topic falls into RFC 7258, which states, amongst others:

   Those developing IETF specifications need to be able to describe how

   they have considered PM, and, if the attack is relevant to the work

   to be published, be able to justify related design decisions.  This

   does not mean a new "pervasive monitoring considerations" section is

   needed in IETF documentation.  It means that, if asked, there needs

   to be a good answer to the question "Is pervasive monitoring relevant

   to this work and if so, how has it been considered?"

     […]

   In particular, architectural decisions, including which existing
   technology is reused, may significantly impact the vulnerability of a
   protocol to PM.  Those developing IETF specifications therefore need
   to consider mitigating PM when making architectural decisions.
   Getting adequate, early review of architectural decisions including
   whether appropriate mitigation of PM can be made is important.
   Revisiting these architectural decisions late in the process is very
   costly.

As per RFC 7258 here the formal question:

Is pervasive monitoring relevant to the design choices made for the QUIC connection ID, and if so, how has it been considered?

A good place to answer may be a security considerations section in draft-tsvwg-quic-protocol.

In general, I personally believe that this topic should be addressed prior to the BoF and not after the WG is formed. But this formal question is above my IETF paygrade.

Michael

From: Jana Iyengar [mailto:[email-masked]]
Sent: Saturday, May 21, 2016 6:05 PM
To: Ryan Hamilton
Cc: [email-masked]; Scharf, Michael (Nokia - DE)
Subject: Re: [QUIC] QUIC privacy impact

Thanks

Michael

Howdy,

regards,
Ted

---

From: Brian Trammell <[email-masked]>
Date: Sun, 22 May 2016 23:39:05 +0200

hi Michael, all,

There are, of course, ways to make such a connection ID be useful as such to the endpoints without exposing that linkability to the network (off the top of my head, by having the connection ID given a 4-typle be algorithmically derivable from any other {4-tuple, connection-id} and a shared secret derived from the session key). If the point of this connection ID is supporting multipath, this would work. If the point of the connection ID is allowing on-path devices to associate multiple connections, then linkability is tautologically possible.

But the eventual protocol specification should make it clear that the former is the case (at least, I hope it is); the algorithm for deriving the connection ID would then need to be part of the spec as well.

Cheers,

Brian

> On 22 May 2016, at 19:33, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
> 
> On Fri, May 20, 2016 at 11:26 PM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Sun, 22 May 2016 21:54:28 +0000

Wouldn't some wording be useful in the proposed charter? E.g., user tractability and user location privacy is not mentioned for the security deliverables.

Michael

> -----Original Message-----
> From: Brian Trammell [mailto:[email-masked]]
> Sent: Sunday, May 22, 2016 11:39 PM
> To: Scharf, Michael (Nokia - DE)
> Cc: Jana Iyengar; Ryan Hamilton; [email-masked]
> There are, of course, ways to make such a connection ID be useful as
> such to the endpoints without exposing that linkability to the network
> (off the top of my head, by having the connection ID given a 4-typle be
> algorithmically derivable from any other {4-tuple, connection-id} and a
> shared secret derived from the session key). If the point of this
> connection ID is supporting multipath, this would work. If the point of
> the connection ID is allowing on-path devices to associate multiple
> connections, then linkability is tautologically possible.
> 
> But the eventual protocol specification should make it clear that the
> former is the case (at least, I hope it is); the algorithm for deriving
> the connection ID would then need to be part of the spec as well.
> 
> Cheers,
> 
> Brian
> 
> 
> 
> > Is pervasive monitoring relevant to the design choices made for the
> QUIC connection ID, and if so, how has it been considered?
> >
> > In general, I personally believe that this topic should be addressed
> prior to the BoF and not after the WG is formed. But this formal
> question is above my IETF paygrade.
> >
> > Michael
> >
> >
> > Specifically this applies to use of connection IDs during multipath,
> and I expect that conversation to happen when we discuss multipath.
> >
> connection identifier“ (also named “clear text super cookie” on the
> SPUD list)?
> >
> > Thanks
> >
> > Michael
> >
> >

---

From: Kyle Rose <[email-masked]>
Date: Sun, 22 May 2016 20:09:03 -0400

> There are, of course, ways to make such a connection ID be useful as such to the endpoints without exposing that linkability to the network (off the top of my head, by having the connection ID given a 4-typle be algorithmically derivable from any other {4-tuple, connection-id} and a shared secret derived from the session key).

I'm not sure this is sufficient in all cases. When roaming, active
connections can be correlated through traffic analysis, as one flow
will suddenly cease at the moment another becomes active; when load
balancing, the start and the end of the connection will cause all
flows to start and stop simultaneously. (Smoke => fire.)

If you want to achieve anonymity of flows, I think a necessary (but
probably still insufficient) constraint is for the connection ID in
every packet to appear unique to a passive observer.

That having been said, I'm still not sure that completely privacy on
the public internet (that is, at the routing layer) is really
possible: once your privacy requirements are strong enough, something
like TOR with added chaff to throw off traffic analysis may be the
only real option.

Kyle

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 23 May 2016 14:22:55 +1000

Shooting for perfect privacy is always going to fail.

What we should be aiming for is no worse than TCP -- having stable, well-understood behaviour is the important thing here. The Internet (and the Web) is a platform that people both design for and use with certain assumptions in mind; we shouldn't violate them without very carefully weighing the impact.

Making it better than TCP would be a good outcome too, of course.

It would be nice to have something in the charter stating "no worse than TCP" for privacy and possibly other properties as well.

Cheers,

> On 23 May 2016, at 10:09 AM, Kyle Rose <[email-masked]> wrote:
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Mon, 23 May 2016 09:28:23 +0200

Mark,

> Shooting for perfect privacy is always going to fail.

I totally agree

> It would be nice to have something in the charter stating "no worse than TCP" for privacy and possibly other properties as well.

This is exactly the type of wording that we should have in the charter 
for various mechanisms that already exist and are/will be included in QUIC.

For congestion control, QUIC should reuse the existing (single-path and 
multipath) TCP congestion control schemes.

For privacy, QUIC should not be worse than existing transport protocols 
(TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for 
security and it turned out to be good.

Same applies probably for the security features in relation with TLS 1.3 
and perhaps HTTP/2 for the API discussion.

Olivier

--

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 10:53:01 -0700

On Sat, May 21, 2016 at 8:44 PM, Christian Huitema <[email-masked]>
wrote:

> Just to be clear, I did use the term “super cookie” in the context of
> multi-path and mobility. That was triggered by the SPUD discussion, during
> which a proposition surfaced to use a QUIC-like connection ID for mobility
> and multipath, and to standardize that as part of the SPUD header. I think
> using the same statistically unique 64-bit number in the clear text
> envelope of packets sent from different IP addresses is a really bad idea.
> It is a bad idea for MP-TCP, and it would be bad idea for QUIC or SPUD.
>

I'll disagree that it's a really bad idea, but I'll agree that this is a
conversation worth having. And as you point out, we should and will talk
about this during the multipath conversation.

- jana

> number is only used for a single pair of source and destination addresses.
> And I also agree that the proper time to study privacy-preserving multipath
> mechanisms is during the study of multipath.
>
>
>
> -- Christian Huitema
>
>
>
>
>
>
>
> *From:* QUIC [mailto:[email-masked]] *On Behalf Of *Jana Iyengar
> *Sent:* Saturday, May 21, 2016 5:20 PM
> *To:* Ryan Hamilton <[email-masked]>
> *Cc:* Scharf, Michael (Nokia - DE) <[email-masked]>;
> [email-masked]
> *Subject:* Re: [QUIC] QUIC privacy impact
>
>
>
> Michael,
>
>
>
> At any rate, I wanted to make sure that we're talking about the same
> issue. I'll also note that it's plain wrong to use the term "clear text
> super cookie" in relation to the QUIC connection ID (see
> https://www.techopedia.com/definition/27310/super-cookie for what I think
> a supercookie is.)
>
>
>
> - jana
>
>
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 10:55:11 -0700

> I must be missing something...

The current version of QUIC does use the same connection ID, as you point
out. This is a design decision that will be revisited during the IETF
standardization of QUIC multipath.

> aspects of multi path not covered in previous security considerations.

+1.

- jana

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 11:01:50 -0700

On Sun, May 22, 2016 at 10:32 AM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> For instance, could I write a QUIC implementation compliant to
> draft-tsvwg-quic-protocol-02 that e.g. uses a static and a random part of
> the connection ID, and e.g. stores the static part permanently on the
> user’s computer? Or, could I pick as a static part the MAC address? The
> total ID would still be random. I have difficulties to understand how this
> sort of ID generation would be different from a “clear text super cookie”
> and what is defined in the reference you provide.
>
>
>
> I am sure that this is not what the current QUIC implementation does. But
> since we are in IETF context, talking about a potential standard, I am
> concerned what other implementers of a new protocol could do, and what use
> cases they could find for this ID.
>
>
>
> And if there was some interesting use of having an entirely user-defined
> clear text value at some constant offset in the packet, for a widely used
> Internet transport protocol, I am pretty sure some implementers would not
> care about some MUSTs in an RFC saying “please, please, please select every
> bit in the ID randomly”.
>
>
>

Yes. The fact that you can't keep stupid implementations from hurting user
privacy. The TCP ISN is unspecified, and it can always be used for packing
whatever user-privacy-revealing information you want. That would be very
very dumb, but it's not out of spec for TCP.

I'll agree that we can and should have text in the spec that says
implementations SHOULD not do stupid things.

- jana

> *Sent:* Sunday, May 22, 2016 5:20 AM
> *To:* Ryan Hamilton
> *Cc:* [email-masked]; Scharf, Michael (Nokia - DE)

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 11:36:44 -0700

I agree with the spirit of Mark's and Olivier's assessments. I'm happy to
add wording to the charter but we'd have to be careful. QUIC's comparisons
are not to TCP, MPTCP, SCTP, or TLS1.3 individually, since they all
implement different functions that are all combined in QUIC. I'm happy to
state something along the lines of QUIC using TLS1.3 should have privacy
and security properties that are no worse than a stack comprised of TLS1.3
over one of {TCP, MPTCP, or SCTP}.

Does that sound reasonable?

I'll point out that there's nothing in the current design of QUIC that runs
afoul of this statement (including use of the same connection ID for
multipath). Of course, we can make it better, so let's have that
conversation when specific design questions are being considered.

- jana

On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <
[email-masked]> wrote:

> What we should be aiming for is no worse than TCP -- having stable,
>> well-understood behaviour is the important thing here. The Internet (and
>> the Web) is a platform that people both design for and use with certain
>> assumptions in mind; we shouldn't violate them without very carefully
>> weighing the impact.
>>
>> It would be nice to have something in the charter stating "no worse than
>> TCP" for privacy and possibly other properties as well.
>>
>
> This is exactly the type of wording that we should have in the charter for
> various mechanisms that already exist and are/will be included in QUIC.
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 19:16:28 +0000

I am certainly not concerned about “stupid” implementations. I am concerned about implementations that understand how to “intelligently” leverage this identifier and this is the type of analysis I expect in a comprehensive security consideration section. Some of the malicious use if this ID may perhaps be classified by as an active attack on user privacy but still the attack vector seems to me quite different to what an attacker can do with similar means with TCP.

At first sight I see quite a number of additional problems compared to the TCP ISN:

·         As TCP stacks do not offer an API for setting the ISN, modification of the TCP ISN would require a kernel patch, administrator rights, etc. The barrier for that is high. The deployment model of a user space UDP protocol stack seems different to that.

·         The TCP ISN will not be conveyed over TCP/HTTP proxies and there are firewalls that randomize the ISN. So, using the TCP ISN as a covert channel or “clear text super cookie” would not work in many environments

·         The ISN only applies to the SYN and not to every packet, so at least monitoring of the ISN by a passive attack seems more difficult

·         There are only 32 bits (possibly some more when using other header fields)

·         I fail to understand how a passive attacker can use the ISN passively for user location tracking etc.

Anyway, I believe that the QUIC connection ID has to be carefully reviewed by better security experts than me, so I am certainly willing to learn if I miss something.

Michael

From: Jana Iyengar [mailto:[email-masked]]
Sent: Monday, May 23, 2016 8:02 PM
To: Scharf, Michael (Nokia - DE)
Cc: Ryan Hamilton; [email-masked]
Subject: Re: [QUIC] QUIC privacy impact

On Sun, May 22, 2016 at 10:32 AM, Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
draft-tsvwg-quic-protocol-02 says:

Yes. The fact that you can't keep stupid implementations from hurting user privacy. The TCP ISN is unspecified, and it can always be used for packing whatever user-privacy-revealing information you want. That would be very very dumb, but it's not out of spec for TCP.

I'll agree that we can and should have text in the spec that says implementations SHOULD not do stupid things.

- jana

Michael

From: Jana Iyengar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Sunday, May 22, 2016 5:20 AM
To: Ryan Hamilton
Cc: [email-masked]<mailto:[email-masked]>; Scharf, Michael (Nokia - DE)
Subject: Re: [QUIC] QUIC privacy impact

Michael,

- jana

Thanks

Michael

Howdy,

regards,
Ted

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 19:49:10 +0000

What is acceptable to me is „not worse than TCP and TLS 1.3 by default”. I fail to understand why the IETF should lower the standards for security and privacy known from TCP for any data transport in the fixed Internet.

It may make sense if users can opt in for additional protocol  features, e.g., similar to MPTCP and SCTP, e.g. on mobile devices. In that case, “after explicit opt-in not worse than TLS1.3 over one of {TCP, MPTCP, SCTP}” seems reasonable, provided it is opt-in.

Michael

From: Jana Iyengar [mailto:[email-masked]]
Sent: Monday, May 23, 2016 8:37 PM
To: Olivier Bonaventure
Cc: Mark Nottingham; Kyle Rose; Ryan Hamilton; Brian Trammell; Scharf, Michael (Nokia - DE); [email-masked]
Subject: Re: [QUIC] QUIC privacy impact

I agree with the spirit of Mark's and Olivier's assessments. I'm happy to add wording to the charter but we'd have to be careful. QUIC's comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 individually, since they all implement different functions that are all combined in QUIC. I'm happy to state something along the lines of QUIC using TLS1.3 should have privacy and security properties that are no worse than a stack comprised of TLS1.3 over one of {TCP, MPTCP, or SCTP}.

I'll point out that there's nothing in the current design of QUIC that runs afoul of this statement (including use of the same connection ID for multipath). Of course, we can make it better, so let's have that conversation when specific design questions are being considered.

- jana

On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <[email-masked]<mailto:[email-masked]>> wrote:
Mark,
Shooting for perfect privacy is always going to fail.

I totally agree

This is exactly the type of wording that we should have in the charter for various mechanisms that already exist and are/will be included in QUIC.

For congestion control, QUIC should reuse the existing (single-path and multipath) TCP congestion control schemes.

For privacy, QUIC should not be worse than existing transport protocols (TCP, Multipath TCP, SCTP). For Multipath TCP, we took this approach for security and it turned out to be good.

Same applies probably for the security features in relation with TLS 1.3 and perhaps HTTP/2 for the API discussion.

Olivier

--

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 23 May 2016 15:55:47 -0400

Hi Michael,

So like...could the identifier be used by a provider
to lessen culpability their culpability in implementing
the Digital Millennium Copyright Act?  The recent
$25 million fine against one provider provides a
major motivation toward mitigating unlawful used
of encrypted streams of their customers.

--tony

On 2016-05-23 3:16 PM, Scharf, Michael (Nokia - DE) wrote:
>
> I am certainly not concerned about “stupid” implementations. I am 
> concerned about implementations that understand how to “intelligently” 
> leverage this identifier and this is the type of analysis I expect in 
> a comprehensive security consideration section. Some of the malicious 
> use if this ID may perhaps be classified by as an active attack on 
> user privacy but still the attack vector seems to me quite different 
> to what an attacker can do with similar means with TCP.
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 20:03:57 +0000

I am not neither a QUIC nor a security expert. I just deal with the entirely ossified Internet running over legacy TCP ;-)

But, to me, this sort of question is valid and has to be answered in a security considerations section.

Michael

From: Tony Rutkowski [mailto:[email-masked]]
Sent: Monday, May 23, 2016 9:56 PM
To: Scharf, Michael (Nokia - DE); Jana Iyengar
Cc: [email-masked]; Ryan Hamilton
Subject: Re: [QUIC] QUIC privacy impact

Hi Michael,

--tony
On 2016-05-23 3:16 PM, Scharf, Michael (Nokia - DE) wrote:
I am certainly not concerned about "stupid" implementations. I am concerned about implementations that understand how to "intelligently" leverage this identifier and this is the type of analysis I expect in a comprehensive security consideration section. Some of the malicious use if this ID may perhaps be classified by as an active attack on user privacy but still the attack vector seems to me quite different to what an attacker can do with similar means with TCP.

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 13:36:01 -0700

If your point is that there should be a Security Considerations section in
the QUIC protocol draft, point taken, and I agree that there should be one
that discusses privacy considerations as well. I think my only argument for
now is that this discussion can wait until after the wg is formed.

A bit more inline:

On Mon, May 23, 2016 at 12:16 PM, Scharf, Michael (Nokia - DE) <
[email-masked]> wrote:

> leverage this identifier and this is the type of analysis I expect in a
> comprehensive security consideration section. Some of the malicious use if
> this ID may perhaps be classified by as an active attack on user privacy
> but still the attack vector seems to me quite different to what an attacker
> can do with similar means with TCP.
>
>
>
> ·         As TCP stacks do not offer an API for setting the ISN,
> modification of the TCP ISN would require a kernel patch, administrator
> rights, etc. The barrier for that is high. The deployment model of a user
> space UDP protocol stack seems different to that.
>
To be clear, we don't rely on TCP for privacy and security properties, we
rely on TLS for these things. Most TLS implementations live in userspace,
often inside applications. I think you'd agree that it's tenuous at best to
argue that a userspace transport is any more vulnerable than TLS.

> ·         The TCP ISN will not be conveyed over TCP/HTTP proxies and
> there are firewalls that randomize the ISN. So, using the TCP ISN as a
> covert channel or “clear text super cookie” would not work in many
> environments
>
·         The ISN only applies to the SYN and not to every packet, so at
> least monitoring of the ISN by a passive attack seems more difficult
>
> ·         I fail to understand how a passive attacker can use the ISN
> passively for user location tracking etc.
>
I was trying to point out that there are cleartext fields in TCP, and are
visible to a passive attacker, just as the connection ID is in QUIC. I
don't want to argue these specific points since I don't want us to go
astray from the core point below:

Anyway, I believe that the QUIC connection ID has to be carefully reviewed
> by better security experts than me, so I am certainly willing to learn if I
> miss something.
>

Absolutely, I agree. I expect that it will be reviewed by security experts
in the wg.

- jana

> *Sent:* Monday, May 23, 2016 8:02 PM
> *To:* Scharf, Michael (Nokia - DE)
> *Cc:* Ryan Hamilton; [email-masked]
>

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Mon, 23 May 2016 21:14:44 +0000

-1 on that user privacy can simply wait until the WG is formed

Michael

Sent: Monday, May 23, 2016 10:36 PM

If your point is that there should be a Security Considerations section in the QUIC protocol draft, point taken, and I agree that there should be one that discusses privacy considerations as well. I think my only argument for now is that this discussion can wait until after the wg is formed.

A bit more inline:

On Mon, May 23, 2016 at 12:16 PM, Scharf, Michael (Nokia - DE) <[email-masked]<mailto:[email-masked]>> wrote:
I am certainly not concerned about “stupid” implementations. I am concerned about implementations that understand how to “intelligently” leverage this identifier and this is the type of analysis I expect in a comprehensive security consideration section. Some of the malicious use if this ID may perhaps be classified by as an active attack on user privacy but still the attack vector seems to me quite different to what an attacker can do with similar means with TCP.

•         As TCP stacks do not offer an API for setting the ISN, modification of the TCP ISN would require a kernel patch, administrator rights, etc. The barrier for that is high. The deployment model of a user space UDP protocol stack seems different to that.
To be clear, we don't rely on TCP for privacy and security properties, we rely on TLS for these things. Most TLS implementations live in userspace, often inside applications. I think you'd agree that it's tenuous at best to argue that a userspace transport is any more vulnerable than TLS.

•         The TCP ISN will not be conveyed over TCP/HTTP proxies and there are firewalls that randomize the ISN. So, using the TCP ISN as a covert channel or “clear text super cookie” would not work in many environments

•         The ISN only applies to the SYN and not to every packet, so at least monitoring of the ISN by a passive attack seems more difficult

•         There are only 32 bits (possibly some more when using other header fields)

•         I fail to understand how a passive attacker can use the ISN passively for user location tracking etc.
I was trying to point out that there are cleartext fields in TCP, and are visible to a passive attacker, just as the connection ID is in QUIC. I don't want to argue these specific points since I don't want us to go astray from the core point below:

Absolutely, I agree. I expect that it will be reviewed by security experts in the wg.

- jana

Michael

From: Jana Iyengar [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Monday, May 23, 2016 8:02 PM
To: Scharf, Michael (Nokia - DE)
Cc: Ryan Hamilton; [email-masked]<mailto:[email-masked]>

- jana

Michael

Michael,

- jana

Thanks

Michael

Howdy,

regards,
Ted

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 14:31:56 -0700

> -1 on that user privacy can simply wait until the WG is formed

I may have missed it -- can you state the privacy concern precisely? I'm
happy to discuss a specific concern that you think needs to be addressed
before the BoF.

- jana

Michael
> *Sent:* Monday, May 23, 2016 10:36 PM
>

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 23 May 2016 21:34:49 +0000

>-1 on that user privacy can simply wait until the WG is formed
 
I am confused by this.  A WG gets formed to do things.  So putting privacy in the charter should be all that's needed, right?

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 24 May 2016 11:30:50 +1000

> On 24 May 2016, at 4:36 AM, Jana Iyengar <[email-masked]> wrote:
> 

SGTM, although some tweaking along the lines Michael suggests might help (it shouldn't be the case that we can e.g., treat MPTCP as a floor for privacy when multipath isn't in use).

Cheers,

> On Mon, May 23, 2016 at 12:28 AM, Olivier Bonaventure <[email-masked]> wrote:
> Mark,
>

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 19:07:44 -0700

On Mon, May 23, 2016 at 6:30 PM, Mark Nottingham <[email-masked]> wrote:

> > I agree with the spirit of Mark's and Olivier's assessments. I'm happy
> to add wording to the charter but we'd have to be careful. QUIC's
> comparisons are not to TCP, MPTCP, SCTP, or TLS1.3 individually, since they
> all implement different functions that are all combined in QUIC. I'm happy
> to state something along the lines of QUIC using TLS1.3 should have privacy
> SGTM, although some tweaking along the lines Michael suggests might help
> (it shouldn't be the case that we can e.g., treat MPTCP as a floor for
> privacy when multipath isn't in use).
>

I don't follow this line of thinking. MPTCP was explicitly designed with
the goal of being a drop-in replacement for TCP -- see the relevant section
in RFC 6182 <https://tools.ietf.org/html/rfc6182#section-2.2.1>. As a
co-author of that RFC, I know for fact that backward-compatibility with
applications was considered an important goal for MPTCP. Is the suggestion
here that MPTCP brings up privacy issues that make it not a drop-in
replacement for TCP? I would argue that the privacy properties of MPTCP are
a reasonable floor for QUIC. That is the current state of the art when it
comes to TCP with multipath operations.

To keep it simple, my suggestion for the wording is "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 MPTCP."

- jana

> Cheers,
>
>
> >
> > I'll point out that there's nothing in the current design of QUIC that
> runs afoul of this statement (including use of the same connection ID for
> > This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail. Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system. If you are not the
> intended recipient you are notified that disclosing, copying, distributing
> or taking any action in reliance on the contents of this information is
> strictly prohibited.
> >
>
> --

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 19:10:21 -0700

On Mon, May 23, 2016 at 7:07 PM, Jana Iyengar <[email-masked]> wrote:

> the goal of being a drop-in replacement for TCP -- see the relevant
> section in RFC 6182 <https://tools.ietf.org/html/rfc6182#section-2.2.1>.
> As a co-author of that RFC, I know for fact that backward-compatibility
> with applications was considered an important goal for MPTCP. Is the
> suggestion here that MPTCP brings up privacy issues that make it not a
> drop-in replacement for TCP? I would argue that the privacy properties of
> MPTCP are a reasonable floor for QUIC. That is the current state of the art
> when it comes to TCP with multipath operations.
>

I meant to say: "That is the current state of the art when it comes to TCP
with multipath operations, whether or not multiple paths are being used."

>> > It would be nice to have something in the charter stating "no worse
>> than TCP" for privacy and possibly other properties as well.
>> >
>> > Same applies probably for the security features in relation with TLS
>> 1.3 and perhaps HTTP/2 for the API discussion.
>> >
>> > Olivier
>> >
>> > --
>> >

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 May 2016 03:22:40 +0000

On Monday, May 23, 2016 4:10 PM, Jana Iyengar wrote:
> On Mon, May 23, 2016 at 7:07 PM, Jana Iyengar <mailto:[email-masked]> wrote:
>> On Mon, May 23, 2016 at 6:30 PM, Mark Nottingham <mailto:[email-masked]> wrote:
…
>>> SGTM, although some tweaking along the lines Michael suggests might help (it shouldn't be
>>>  the case that we can e.g., treat MPTCP as a floor for privacy when multipath isn't in use).
>>
>> I don't follow this line of thinking. MPTCP was explicitly designed with the goal of being a 
>> drop-in replacement for TCP -- see the https://tools.ietf.org/html/rfc6182#section-2.2.1. 
>> As a co-author of that RFC, I know for fact that backward-compatibility with applications
>> was considered an important goal for MPTCP. Is the suggestion here that MPTCP brings up
>> privacy issues that make it not a drop-in replacement for TCP? 

Yes. This was actually discussed during the MPTCP meeting in BA. MPTCP uses a simple clear-text token to link multiple paths together, and that has significant privacy implications. There is no definitive solution yet, but the "bis" version of MPTCP could address that.

>> I would argue that the privacy properties of MPTCP are a reasonable floor for QUIC. That is 
>> the current state of the art when it comes to TCP with multipath operations.
>
> I meant to say: "That is the current state of the art when it comes to TCP with multipath operations, 
> whether or not multiple paths are being used."

It is the previous state of the art, but we sure wish to progress that. 

> To keep it simple, my suggestion for the wording is "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 MPTCP."

Make that "as good as a stack composed of TLS1.3 using TCP" and everybody will be happy.

-- Christian Huitema

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 May 2016 05:58:32 +0000

> I am confused by this.  A WG gets formed to do things.  So putting
> privacy in the charter should be all that's needed, right?

My point is that user privacy has to (also) be a first-class citizen in the protocol design.

I will be fine with a charter that guarantees user privacy "as good as a stack composed of TLS1.3 using TCP". 

Having some sort of security consideration section would perhaps help to better understand what such wording in reality may imply for protocol design choices, but, indeed, finally the charter wording is what matters.

Michael

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 May 2016 09:30:15 +0300

> On 24 May 2016, at 8:58 AM, Scharf, Michael (Nokia - DE) <[email-masked]> wrote:
> 
> I will be fine with a charter that guarantees user privacy "as good as a stack composed of TLS1.3 using TCP”. 

I’d rather go with “TLS” rather than “TLS 1.3” because TLS 1.3 is still a moving target.
> Having some sort of security consideration section would perhaps help to better understand what such wording in reality may imply for protocol design choices, but, indeed, finally the charter wordi…

IMO the charter wording on this does not matter much. If the output document of the working group has poor privacy or security properties, anyone reading it could object even if the charter was entirely silent on these topics. Same goes for efficiency, congestion control and any other property that is part of good engineering.

The utility of a charter is in limiting the scope of a working group’s work by defining the deliverables. It is not in stating generic desirable properties of those deliverables, and privacy is desirable in any protocol. If we had specific requirements like “messages should not exceed 140 bytes”, that would be OK to state in the charter, but “the protocol should be secure” is not.

Yoav

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 23:32:02 -0700

>
>
> Yes. This was actually discussed during the MPTCP meeting in BA. MPTCP
> uses a simple clear-text token to link multiple paths together, and that
> has significant privacy implications. There is no definitive solution yet,
> but the "bis" version of MPTCP could address that.

I'm aware of the cleartext token, but if the MPTCP wg has agreed to fix
this in a bis document, doesn't that automatically raise the privacy bar
that QUIC needs to meet if we say "QUIC must be at least as good as MPTCP"?

> It is the previous state of the art, but we sure wish to progress that.

It is the current state of the art until we have something better. QUIC
could certainly move this state forward, but nevertheless, MPTCP is the
IETF's latest multipath solution. Note that I'm not saying that QUIC should
be exactly as good as MPTCP, just that it should be at least as good as
MPTCP. This is a minimum bar -- you are arguing that this minimum is too
low, but I really think that's a discussion in the wg when we need to
discuss multipath, not a charter one when we're trying to lay ground rules.

> Make that "as good as a stack composed of TLS1.3 using TCP" and everybody

How does this apply to multipath?

My higher-order point is that making MPTCP the bar is consistent with where
the IETF is right now with transport. I am totally for discussing the
merits of raising this bar in QUIC, but it seems like this discussion
belongs in the wg, where we can debate the cost and merits of doing better,
and I'm looking forward to that conversation. The charter is laying out
what the minimum bar is, and the higher-order goal is to say that we won't
do worse than X, where X is the state of the art for IETF-TCP. This is
currently MPTCP.

I could go with what Mark and Michael suggested; something like: "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.)"

What do folks think?
- jana

---

From: Jana Iyengar <[email-masked]>
Date: Mon, 23 May 2016 23:36:18 -0700

+1.

I will be fine with a charter that guarantees user privacy "as good as a
> stack composed of TLS1.3 using TCP".
>

Please take a look at the text that I've proposed in the other email... I
hope that's satisfactory.

- jana

> Having some sort of security consideration section would perhaps help to
> better understand what such wording in reality may imply for protocol
> design choices, but, indeed, finally the charter wording is what matters.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 May 2016 07:04:11 +0000

MPTCP is experimental right now and may be partly a moving target. As far as I know, SCTP is mainly deployed in controlled environments signaling environments, in which user privacy is not a concern. TCP is the Internet standard transport for most applications and most notably the Web.

So the bar for security and privacy is TCP, in my point of view. Actually, there is no need to mention MPTCP at all. If lowering of security and privacy standards compared to TCP is required, as mentioned before, the charter could mention that the protocol design can foresee additional, entirely optional additional protocol features, on an opt-in basis.

Michael

From: Jana Iyengar [mailto:[email-masked]]
Sent: Tuesday, May 24, 2016 8:32 AM
To: Christian Huitema
Cc: Mark Nottingham; Olivier Bonaventure; Scharf, Michael (Nokia - DE); Kyle Rose; Ryan Hamilton; Brian Trammell; [email-masked]
Subject: Re: [QUIC] QUIC privacy impact

I'm aware of the cleartext token, but if the MPTCP wg has agreed to fix this in a bis document, doesn't that automatically raise the privacy bar that QUIC needs to meet if we say "QUIC must be at least as good as MPTCP"?

It is the current state of the art until we have something better. QUIC could certainly move this state forward, but nevertheless, MPTCP is the IETF's latest multipath solution. Note that I'm not saying that QUIC should be exactly as good as MPTCP, just that it should be at least as good as MPTCP. This is a minimum bar -- you are arguing that this minimum is too low, but I really think that's a discussion in the wg when we need to discuss multipath, not a charter one when we're trying to lay ground rules.

How does this apply to multipath?
My higher-order point is that making MPTCP the bar is consistent with where the IETF is right now with transport. I am totally for discussing the merits of raising this bar in QUIC, but it seems like this discussion belongs in the wg, where we can debate the cost and merits of doing better, and I'm looking forward to that conversation. The charter is laying out what the minimum bar is, and the higher-order goal is to say that we won't do worse than X, where X is the state of the art for IETF-TCP. This is currently MPTCP.

I could go with what Mark and Michael suggested; something like: "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.)"

What do folks think?
- jana

-- Christian Huitema

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 24 May 2016 13:07:18 +0000

>So the bar for security and privacy is TCP, in my point of view.
>Actually, there is no need to mention MPTCP at all. If lowering of
>security and privacy standards compared to TCP is required, as mentioned
>before, the charter could mention that the protocol design can foresee
>additional, entirely optional additional protocol features, on an opt-in
>basis.

I am trying to understand what you are saying here; a) does it mean that
user should “opt-in” to additional features and b) is multi path such an
additional “feature”?

Regards
Göran

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 09:22:35 -0700

> are at least as good as a stack composed of TLS1.3 using TCP (or MPTCP when

I disagree with the implication that MPTCP or even TCP is good enough.
It's been a little while, we've learned a few things about the world
and how to design protocols that retain important things like privacy
and security without sacrificing other goals, like performance.

This text sets a pretty low bar.  Too low perhaps.  But I don't know
for sure right now because I don't have the entire design space mapped
out.  And a charter discussion isn't the place for that (thanks
Rich!).  How about we not try to decide the outcome of the discussion
and simply say that we will design for the optimum tradeoff between
functionality, performance, security and privacy.  In other words, we
will do our jobs.

I propose: "This work will address security and privacy issues arising
from the protocol design." and leave it at that.

---

From: "Scharf, Michael (Nokia - DE)" <[email-masked]>
Date: Tue, 24 May 2016 17:18:25 +0000

Without knowing the protocol mechanism and specifically the security and privacy considerations, how should I be able to answer this?

Yet, for enabling/disabling multipath, I would suggest something equivalent to RFC 6897 Section 4.5 and possibly something like REQ1 in Section 5.2 in the same RFC (the latter is related to TAPS).

I am an author of RFC 6897 and thus maybe I am biased here. But there was pretty strong consensus in the working group on those two sections, i.e., that there must be a way to turn on and off multipath. Does this make sense to you?

Michael

-----Original Message-----
From: Göran Eriksson AP [mailto:[email-masked]] 
Sent: Tuesday, May 24, 2016 3:07 PM
To: Scharf, Michael (Nokia - DE); Jana Iyengar; Christian Huitema
Cc: Olivier Bonaventure; Kyle Rose; Ryan Hamilton; Mark Nottingham; Brian Trammell; [email-masked]
Subject: Re: [QUIC] QUIC privacy impact

>security and privacy standards compared to TCP is required, as 
>mentioned before, the charter could mention that the protocol design 
>can foresee additional, entirely optional additional protocol features, 
>on an opt-in basis.

I am trying to understand what you are saying here; a) does it mean that user should “opt-in” to additional features and b) is multi path such an additional “feature”?

Regards
Göran

---

From: Erik Nygren <[email-masked]>
Date: Tue, 24 May 2016 13:36:48 -0400

> from the protocol design." and leave it at that.

+1

(and we can always reference rfc6973 if we want to, although that may be
implicit)

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 24 May 2016 19:07:27 +0000

>On Tue, May 24, 2016 at 12:22 PM, Martin Thomson
><[email-masked]> wrote:
>
>

+1. Kind of like referring to something like rfc6973 signalling the intent
to go that extra mile.

If HTTP/2 mapping on QUIC is included in the WG, I propose considering a
minor addition to clarify security and privacy issues concerns using QUIC
as a standalone protocol as well as HTTP/2 in combination with QUIC. Would
for some reason also QUIC for WebRTC be included (later), then obviously
the WG would need to look at that mapping as a separate topic:

"This work will address security and privacy issues arising from the
[NEW]transport[/NEW] protocol design [NEW]as well as the mapping of the
HTTP/2 application protocol and extensions on the transport
protocol[/NEW]”.

---

From: Göran Eriksson AP <[email-masked]>
Date: Tue, 24 May 2016 20:39:59 +0000

>
>Don't be too specific.  It creates the sense that there are exceptions.
>
>RFC 6973 is great, but we don't need citations for it or we will have
>to add 3552 as well.

Advice from a wiser one, :-). See the problem with the proposals. Tnx.

---

From: Martin Thomson <[email-masked]>
Date: Tue, 24 May 2016 12:57:17 -0700

---

From: Olivier Bonaventure <[email-masked]>
Date: Tue, 24 May 2016 22:53:24 +0200

> from the protocol design." and leave it at that.

I think that it is useful to specify a reasonable expectation that is 
not unrealistic. Otherwise, we might end up in never ending discussions 
within the working group.

Olivier

--

---

From: Christian Huitema <[email-masked]>
Date: Tue, 24 May 2016 21:06:15 +0000

On Tuesday, May 24, 2016 1:53 PM, Olivier Bonaventure wrote:
> >> I could go with what Mark and Michael suggested; something like:
> >> "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.)"
...
> I think that it is useful to specify a reasonable expectation that is not
> unrealistic. Otherwise, we might end up in never ending discussions within the
> working group.

Au contraire. Any discussion in the WG will require that proponent of a "more private" option propose a design. There may be good reasons to reject a proposed design, if it is for example way too complicated, or too unreliable. But such designs should not be pre-emptively ruled out by some provision of the charter.  I think Martin has the right formulation.

-- Christian Huitema

---

From: Kyle Rose <[email-masked]>
Date: Tue, 24 May 2016 17:19:58 -0400

> unrealistic. Otherwise, we might end up in never ending discussions within
> the working group.

But right now it's ok?

Charter formation doesn't seem like the right place to constrain the
space of security and privacy properties with references to existing
protocols, the relationships to QUIC of which aren't yet fully
understood and the precise meanings of which are not clear. (E.g., is
"as good as a stack composed of TLS1.3 using TCP" even well defined?)

OTOH, I think we can all agree that QUIC needs to "address security
and privacy issues", and can pursue clarification of the implications
of that statement within the WG via rough consensus.

+1 to Martin's proposal to keep the wording in the charter high-level.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 May 2016 07:49:11 +1000

The point of including something like this in a charter is to serve as a contract between the WG and the rest of the community; it states the expectations upon the work, so everyone's on the same page. 

It also gives the chair(s) a way to short-circuit unproductive discussions, if they stray past the expressed limits. Given the scope of this work, I think any and all such advice we can get into the charter will be helpful.

That doesn't mean it has to be design-in-charter; it only needs to define a floor. I think the text Jana came up with served that purpose well. We can always exceed it, based upon justifications other than the charter.

Cheers,

> On 25 May 2016, at 7:19 AM, Kyle Rose <[email-masked]> wrote:
>

---

From: Jana Iyengar <[email-masked]>
Date: Fri, 27 May 2016 18:10:33 -0700

I agree with Mark's point about the charter being a contract between the WG
and the rest of the community. It's reasonable to say that the current
state of what the IETF has produced so far is the floor from where we start
in this WG.

On Tue, May 24, 2016 at 2:49 PM, Mark Nottingham <[email-masked]> wrote:

> The point of including something like this in a charter is to serve as a
> contract between the WG and the rest of the community; it states the
> expectations upon the work, so everyone's on the same page.
>
> It also gives the chair(s) a way to short-circuit unproductive
> discussions, if they stray past the expressed limits. Given the scope of
> this work, I think any and all such advice we can get into the charter will
> be helpful.
>
> That doesn't mean it has to be design-in-charter; it only needs to define
> a floor. I think the text Jana came up with served that purpose well. We
> can always exceed it, based upon justifications other than the charter.
>
> Cheers,
>
>
> not

---

From: Jim Roskind <[email-masked]>
Date: Sat, 28 May 2016 10:49:07 -0700

I've tried to read the whole thread... but I don't think I saw items that
would address following concerns about the charter.

My general perspective is that QUIC was designed to exploit the tight
integration of numerous protocol elements that were traditionally separated
into layers.  Traditional layering included TCP handling
congestion/reliability, independent of TLS handling privacy and
authentication, independent of HTTP handling of request/response pairs
(multiplexed in HTTP/2). QUIC deviates from that pattern at the highest
level, when stream data is (usually) placed into separate UDP packets
(despite multiplexing), with independent decryption (usually) for each
stream fragment. Even QUIC's basic connection establishment tightly binds
awareness of all 3 traditional layers.

Other tight integration points in QUIC include the way the packet sequence
number is used as a basis for the crypto IV for packet decryption, while
also being used for N/ACK reliability (congestion(?) detection?)
notification. Those sequence numbers were also integrated into the
definition of the initial FEC strategy. Further, the rebundling of data
(rather than retransmission of packets with old sequence numbers) to
establish reliable transmission, then simplified the crypto use of the
sequence number as an IV (only a small fixed window could ever be
outstanding, and highly delayed packets could be safely/naturally discarded
by a decryption authentication failure).

Contrary to that tight-integration perspective that I've held for QUIC,
some of the charter suggests that numerous elements can be teased apart or
addressed separately.

a) Congestion control: I would expect that additional data (optionally)
transmitted as part of the core protocol would be critical to evolution of
congestion control.  Examples would include (optionally) better time
stamping; better understanding of received vs lost vs reconstructed (via
FEC) packets. Even the decision to send ACK data in standard packets in the
company of stream data represents a (optional??) point of integration.  The
charter appears to leave congestion control to documents external to the
wire spec, which surprises me.

b) FEC: The quote "specific FEC scheme definitions are out of scope"
concerned me.  Although I would not like new/novel FEC inventions to be
studied by the WG, I would absolutely expect that very specific FEC
definitions, which made the protocol workable at a wire spec level (i.e.,
what do you do with FEC related information to recover a packet or
information?? What extra data fields in the packets would be needed to
relate packets to FEC groups(?)?).

Although I spent years of my life designing, justifying, and working to
deploy QUIC, I'm new to the IETF, so I'd like to better understand the
planned (apparent) separation shown above... or understand why it doesn't
run contrary to the above perspective.

Thanks,

Jim

---

From: Ted Hardie <[email-masked]>
Date: Tue, 31 May 2016 14:07:35 -0700

Hi Jim,

Sorry for the belated reply--catching up after the long weekend. Reply at
the bottom.

> run contrary to the above perspective.
So, the basic thining here is that the IETF builds building blocks, and
that when they are successful they tend to see a lot of re-use.  When
bringing this charter forward, the proponents looked at which building
blocks would likely get reused and how, and we tried to structure the work
both to enable future use and to reinforce the current interplay among
application, cryptographic protection, and transport features.

One piece that we saw as a re-usable building block was the cryptographic
handshake--sharing that with TLS 1.3 seemed to us to make sense both for
QUIC and TLS.

A second piece was the core transport work, which is re-usable across a
number of potential using applications.  We certainly didn't intend by that
to create a specific layering.  Rather, we wanted to make it easy for new
protocols to describe how they mapped their exchanges onto the mechanisms
of QUIC, by having all the mappings (including the original HTTP mapping)
be related to the core mechanisms.

The third piece was that process of describing a specific application's use
of the transport and cryptographic mechanisms.  Having a worked example of
that for a well-known application will help ensure that later applications
that want to re-use it will know which pieces are derived from QUIC and
which from other using applications.

To give an example:  imagine someone wanted to implement DPRIVE-like DNS
privacy by running  DNS over QUIC.  If we define QUIC as tightly bound to
its current application, the result will look a great deal like DNS over
HTTP (certainly possible, e.g. by making GET requests for DNS URIs).  But
if we enable new mappings, it will end up looking much more like DNS over a
scalable, non-blocking, cryptographically protected UDP transport.  The
un-needed HTTP-isms won't creep in as easily.  Admittedly, you might get
the latter result starting from the tightly bound version and ruthlessly
cutting and replacing, but you'd probably see the result as a sister
protocol to the original, rather than as a different use of the same.

The latter seemed preferable, at least to me.  There is a real danger here
of shipping the org chart, and one of the reasons we wanted to keep the
work in a single working group was to avoid drift between protocol
mechanisms in different areas of work.  I personally think that's the right
balance, but this is the part of the IETF process where that construction
gets discussed.

Just my thoughts on this,

regards,

Ted

---

From: Tim Wicinski <[email-masked]>
Date: Tue, 31 May 2016 20:51:09 -0400

On 5/31/16 5:07 PM, Ted Hardie wrote:
> privacy by running  DNS over QUIC.  If we define QUIC as tightly bound
> to its current application, the result will look a great deal like DNS
> over HTTP (certainly possible, e.g. by making GET requests for DNS
> URIs).  But if we enable new mappings, it will end up looking much more
> like DNS over a scalable, non-blocking, cryptographically protected UDP
> transport.  The un-needed HTTP-isms won't creep in as easily.
> Admittedly, you might get the latter result starting from the tightly
> bound version and ruthlessly cutting and replacing, but you'd probably
> see the result as a sister protocol to the original, rather than as a
> different use of the same.

I've had this exact same conversation about a year ago (if not longer) 
with Jim.  He gave me some very useful advice on how to approach the 
problem.

But a protocol without the HTTP-isms makes more sense (but I'm a bit 
biased on the DNS side).

tim

---

From: Christian Huitema <[email-masked]>
Date: Wed, 1 Jun 2016 01:11:49 +0000

On Tuesday, May 31, 2016 5:51 PM, Tim Wicinski wrote:
> > To give an example:  imagine someone wanted to implement DPRIVE-like
> > DNS privacy by running  DNS over QUIC.  If we define QUIC as tightly
> > bound to its current application, the result will look a great deal
> > like DNS over HTTP (certainly possible, e.g. by making GET requests
> > for DNS URIs).  But if we enable new mappings, it will end up looking
> > much more like DNS over a scalable, non-blocking, cryptographically
> > protected UDP transport.  The un-needed HTTP-isms won't creep in as easily.
> I've had this exact same conversation about a year ago (if not longer) with Jim.
> He gave me some very useful advice on how to approach the problem.
> 
> But a protocol without the HTTP-isms makes more sense (but I'm a bit biased
> on the DNS side).

I think that QUIC really has two layers. There is a bottom layer that manages the transmission of encrypted packets, the detection of errors, and possibly the forward error correction. Then there is an upper layer that manages the multiplexing of streams, and that cooperates with the bottom layer to manage retransmissions. 

Currently, the two layers are tied in multiple ways. The encryption layer cannot function without passing the stream 1 packets to the TLS machinery. The stream management frames share a number space with the error management frames. The per connection receive window is managed as the aggregate of the per stream receive window. But these are in fact simple problems, and it should be possible to disentangle the error detection layer and the stream management layer.

After that, yes, there are quite a few possible innovations. The stream abstraction works well for HTTP 2.0, but I would rather use a transaction-based logic for DPRIVE, and maybe something different still for real-time multi-media. Or, if we think of multi-path, I could see a stream layer being multiplexed over two separate lower layers, managed as two separate connections. 

The whole point of defining a user mode transport is to enable this kind of innovation!

-- Christian Huitema

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 1 Jun 2016 12:03:15 +1000

Hi Christian,

> On 1 Jun 2016, at 11:11 AM, Christian Huitema <[email-masked]> wrote:
> 

This makes me wonder if QUIC is anything but a collection of functions that can be assembled by an application; as it is, the charter carves off crypto into TLS; FEC and congestion control are defined externally; multi-path is an extension. If streams are also optional, what's left? Loss recovery?

I'm not against such a modular approach, but standardising it IMO will present some real challenges. Enough to make me wonder if just defining QUIC as HTTP/2-over-UDP is better; other applications could reuse its primitives as they like. It might not be as tidy, but it's a lot more workable...

Cheers,

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 31 May 2016 23:20:24 -0700

Christian, Mark,

I'll start off by agreeing with Christian that QUIC is functionally
separable into "layers" (for lack of a better word). But this is not new.
Any transport that tries to separate application semantics from
network-level functions such as loss recovery and congestion control is
bound to be complex enough to be implementing these separable functions.
SCTP, SST, QUIC, are all good examples of this general idea, and that's
because these are all relatively complex transports. They are different
however in the boundaries that they collapse. (From this point of view,
QUIC is actually closer to SST than it is to SCTP.)

Bryan Ford and I did some transport decomposition work a while ago (you may
be familiar with it), and here's a section of an architectural draft we
wrote in 2009 that is relevant here:
https://tools.ietf.org/html/draft-iyengar-ford-tng-00#section-3.
Specifically, it separates the functions you mention into multiple
connection contexts, with multiple streams stacked on top of multiple
connection contexts.

So, it seems architecturally sensible (at least to me) to think about these
functions separately. That said, any protocol instantiation of these
functions will appropriately collapse these layering boundaries for
efficiency. The real question here is whether the particular set of
transport functions that QUIC implements and the set of "layering"
boundaries that QUIC collapses result in something powerful enough to be
useful and general enough to be extensible. In other words, IMO, the
question about QUIC ought to be whether it is specific enough to provide
performance benefits for particular applications, and general enough to
allow more applications to extend it in the future.

The answer to the first question is a resounding yes. We have running
deployed code and we have presented data about the benefits of QUIC for
HTTP traffic. The answer to the second question is something we'll only
know by trying. The charter is currently scoped to pursue the first
question first -- by building QUIC for HTTP as the first application. The
QUIC wg can and should continue chasing more application mappings after
HTTP, to see how general QUIC ends up being. If  QUIC falls short of a next
application that we thought might fit, that's an argument for either
refitting QUIC, or for building a different protocol that collapses these
functional boundaries differently, and maybe even chooses different
functional components. I think this is a perfectly reasonable outcome that
we should anticipate. DPRIVE or DNS may not fit on top of QUIC, and that's
fine (*).

I think this is also exactly how we should pursue new transport work at the
IETF. I would strongly argue against generalizing QUIC too much before
building it for HTTP. I am very wary of building a "kitchen-sink" transport
that tries to satisfy several applications at once. At the same time, I
would not start by strait-jacketing QUIC to be only for HTTP. The core
primitives are not going to be universally useful, but they will be
undoubtedly more generally useful than just for HTTP. The document division
in the charter captures this thinking, and I think that it's workable.

Just my thoughts.

(*) - In principle, I think you can do this though. QUIC, like SST, has
lightweight streams. You can map a transactional app by mapping a stream to
each transaction... and this has some really nice properties for the
application. But I don't want to rathole on designing QUIC for DNS here.

- jana

On Tue, May 31, 2016 at 7:03 PM, Mark Nottingham <[email-masked]> wrote:

> > I think that QUIC really has two layers. There is a bottom layer that
> manages the transmission of encrypted packets, the detection of errors, and
> possibly the forward error correction. Then there is an upper layer that
> manages the multiplexing of streams, and that cooperates with the bottom
> layer to manage retransmissions.
> >
> > Currently, the two layers are tied in multiple ways. The encryption
> layer cannot function without passing the stream 1 packets to the TLS
> machinery. The stream management frames share a number space with the error
> management frames. The per connection receive window is managed as the
> aggregate of the per stream receive window. But these are in fact simple
> problems, and it should be possible to disentangle the error detection
> layer and the stream management layer.
> >
> > After that, yes, there are quite a few possible innovations. The stream
> abstraction works well for HTTP 2.0, but I would rather use a
> transaction-based logic for DPRIVE, and maybe something different still for
> real-time multi-media. Or, if we think of multi-path, I could see a stream
> layer being multiplexed over two separate lower layers, managed as two
> separate connections.
> >
> This makes me wonder if QUIC is anything but a collection of functions
> that can be assembled by an application; as it is, the charter carves off
> crypto into TLS; FEC and congestion control are defined externally;
> multi-path is an extension. If streams are also optional, what's left? Loss
> recovery?
>
> I'm not against such a modular approach, but standardising it IMO will
> present some real challenges. Enough to make me wonder if just defining
> QUIC as HTTP/2-over-UDP is better; other applications could reuse its
> primitives as they like. It might not be as tidy, but it's a lot more
> workable...
>
> Cheers,
>
> --