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

[Spencer Dawkins at IETF <[e-mail]>]

Hi, Eric,

On Tue, Sep 13, 2016 at 11:52 AM, Eric Rescorla <[e-mail]> wrote:

>
>
> On Mon, Sep 12, 2016 at 5:50 PM, Ryan Hamilton <[e-mail]> wrote:
>
>> ​​
>>
>>
>> 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.
>>
>
> 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.
>

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

- Provide always-secure transport

and

- Provide always-secure transport using TLS

Would either of those say what you're saying?

Thanks,

Spencer


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