Re: Getting to a First Implementation Draft

[Ian Swett <[e-mail]>]

Fixing the transport parameters sounds like a good simplification to me.

I pushed for transferring some information with the 1RTT keys in a late
draft, which likely resulted in the inconsistency.  My logic is that you
haven't really shown the handshake works unless you use the output of it.

Transferring data on a non-0 stream requires an application of some sort.
Do you have any suggestions for what that would be?  Or were you thinking
something of simple like "ping" and "pong"?

On Sun, May 14, 2017 at 2:11 PM, Patrick McManus <[e-mail]>
wrote:

> I don't really know how I feel about this wiki page.. without ratholing
> too deeply on it I think that while it tries to facilitate testing and
> interop, it treads pretty significantly into the land of project management
> which is squarely out of bounds for the working group. I'm willing to see
> how it goes but that's my concern - I would rather the WG focuses on the
> complete picture while providing more of a forum for pair (or more) wise
> testing.
>
> anyhow wrt specifics -  ekr points out the 2 major inconsistencies.. tbh I
> would require exporters and the ability to do at least one non-0 stream. At
> that point you have a hello world milestone, which is always the first
> stage worthy of a toast. Its ok by me if the transport params are just
> profiled.
>
> On Sat, May 13, 2017 at 2:54 PM, Eric Rescorla <[e-mail]> wrote:
>
>> A few comments on this proposed list:
>>
>> > Integration with TLS 1.3 handshake - The basic 1-RTT mode must be
>> > supported. TLS exporters are not needed, nor are session
>> > tickets. Basic key exchange is sufficient and implementations can
>> > use any certificate. All MTI algorithms listed in TLS 1.3 are
>> > expected.
>>
>> I note that this and the transport parameters and HRR stuff below
>> necessitate the generic changes to the TLS library to permit adding
>> extra extensions. I wonder if it might make life better to just have a
>> canned set of parameters for now. It's not that it's a lot of work,
>> it's just that it's not critical path otherwise.
>>
>>
>> > Packet protection - All post handshake packets must be sent with
>> > 1RTT keys and packet protection.
>>
>> This is inconsistent with not requiring exporters above. As far
>> as I can tell, if you're not doing NST, you don't need post-handshake
>> packets anyway here, so you can probably skip this.
>>
>>
>>
>> On Wed, May 10, 2017 at 9:53 PM, Mark Nottingham <[e-mail]> wrote:
>>
>>> Previously, we've mentioned an intention to have a First Implementation
>>> Draft -- that is, an Internet-Draft that we feel is suitable for
>>> implementers to write code to, for the purposes of interoperability testing
>>> and gathering feedback -- shortly after the Paris interim.
>>>
>>> Due to the size and complexity of HTTP-over-QUIC, implementing all four
>>> drafts for this purpose on a reasonable timeline isn't workable.
>>>
>>> Instead, the editors have identified a subset of functionality that they
>>> believe will serve as a suitable starting point. See:
>>>   https://github.com/quicwg/base-drafts/wiki/First-Implementation-Draft
>>>
>>> They've also identified the set of issues that we believe will be
>>> necessary to have proposals for before Paris; see:
>>>   https://github.com/quicwg/base-drafts/milestone/1
>>>
>>> If all goes well, the plan is to have a set of drafts out (very) soon
>>> that do so; then, we can discuss them and the First Implementation Draft
>>> Candidate in the lead-up to and during the Paris interim.
>>>
>>> After Paris, we'll make any necessary adjustments to the documents and
>>> publish another set, which will be the First Implementation Draft.
>>>
>>> Please comment / raise concerns / make suggestions on-list.
>>>
>>> Regards,
>>>
>>> --
>>> Mark Nottingham   https://www.mnot.net/
>>>
>>>
>>
>