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

On Mon, Sep 12, 2016 at 5:50 PM, Ryan Hamilton <rch@google.com> wrote:

> 
>
>
> On Mon, Sep 12, 2016 at 4:39 PM, Eric Rescorla <ekr@rtfm.com> 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.
>

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

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

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

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

-Ekr

Cheers,
>
> 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 <
>> spencerdawkins.ietf@gmail.com> wrote:
>>
>>> Hi, Alissa,
>>>
>>> On Thu, Sep 1, 2016 at 8:47 AM, Alissa Cooper <alissa@cooperw.in> 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
>>> QUIC@ietf.org
>>> https://www.ietf.org/mailman/listinfo/quic
>>>
>>>
>>
>> _______________________________________________
>> QUIC mailing list
>> QUIC@ietf.org
>> https://www.ietf.org/mailman/listinfo/quic
>>
>>
>