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

[Ryan Hamilton <[e-mail]>]

​​


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

> I had a few comments on the draft charter:
>
> > There is emerging implementation and deployment experience with QUIC, a
> > UDP-based protocol that provides a stream-multiplexing encrypted
> transport.
> > Based on that implementation and deployment experience, the QUIC working
> group
> > will provide a standards track specification generalizing the design
> described
> > in the initial set of draft-tsvwg-quic-protocol, draft-tsvwg-quic
> -loss-recovery,
> > and related documents.
>
> "initial set" is ungrammatical here. Strike it.
>
>
> > Key goals for QUIC are:
> >
> > - Minimizing connection establishment and overall transport latency for
> > applications, starting with HTTP/2;
> > - Providing multiplexing without head-of-line blocking;
> > - Enabling deployment over unmodified Internet paths; and
> > - Enabling multipath and forward error correction extensions.
>
> I would like to see a security objective here, as I think we all agree
> that it's a first-class priority.
>
> - Providing secure transport by default using TLS 1.3.
>

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

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

Cheers,

Ryan



>
> > This work will ensure that
> > QUIC using TLS1.3 has security and privacy properties that are at least
> as good
> > as a stack composed of TLS1.3 using TCP (or MPTCP when using multipath).
>
> This "QUIC using TLS 1.3" language is a little weird. I would just say
> "QUIC". I believe MT provided a similar comment.
>
>
>
> > The third focus area will describe mappings between specific
> applications???
> > semantics and the transport facilities of QUIC. The first mapping will
> be a
> > description of HTTP/2 semantics using QUIC, specifically with the goal
> of
> > minimizing web latency using QUIC. This mapping will accommodate the
> extension
> > mechanisms defined in the HTTP/2 specification. Upon completion of that
> mapping,
> > additional protocols may be added by updating this charter to include
> them.
>
> I'm not sure this should be in QUIC so much as HTTP. Minimally it somehow
> needs to be in cooperation and I don't see anything here. I certainly don't
> want this to preclude a mapping of only HTTP/2's transport facilities.
>
> -Ekr
>
>
> On Thu, Sep 1, 2016 at 7:02 AM, Spencer Dawkins at IETF <
> [e-mail]> wrote:
>
>> Hi, Alissa,
>>
>> On Thu, Sep 1, 2016 at 8:47 AM, Alissa Cooper <[e-mail]> wrote:
>>
>>> Alissa Cooper has entered the following ballot position for
>>> charter-ietf-quic-00-01: Yes
>>>
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>>
>>>
>>>
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/charter-ietf-quic/
>>>
>>>
>>>
>>> ----------------------------------------------------------------------
>>> COMMENT:
>>> ----------------------------------------------------------------------
>>>
>>> What is the status of these PRs?
>>> https://github.com/IETF-QUIC/Charter/pulls
>>
>>
>> I checked two of the PRs. One looks like it's reflected in the
>> datatracker, but the other does not. I'll make sure the proponents think
>> the datatracker text reflects what they want to go with, before this goes
>> for external review.
>>
>> Spencer
>>
>> _______________________________________________
>> QUIC mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/quic
>>
>>
>
> _______________________________________________
> QUIC mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/quic
>
>