Re: 2 Points of First Implementation Draft we might clarify

[Kazuho Oku <[e-mail]>]

I'd prefer draft-18 since that's the version we support in picotls.

If others prefer to -20, maybe I can prepare that before Prague though.

2017-06-28 14:10 GMT-07:00 Ian Swett <[e-mail]>:
> I've been informed that BoringSSL doesn't yet support draft 20 and won't
> until we understand how to get middleboxes to stop hating TLS 1.3 over TCP,
> so from a practical perspective, it would be much easier for us to support
> 18.
>
> Would only supporting 18 cause problems for anyone?
>
> On Wed, Jun 28, 2017 at 4:53 PM, Ian Swett <[e-mail]> wrote:
>>
>> Those both seem like good changes to me.
>>
>> On Wed, Jun 28, 2017 at 4:51 PM, Patrick McManus <[e-mail]>
>> wrote:
>>>
>>> Hi All - First, its really amazing to see nascent quic implementations
>>> emerging from primordial soup over the last couple of weeks. I can count at
>>> least 5 that have been mentioned on email, chat, or twitter trying to do
>>> real interop. Its all a giant morass of work in progress of course - but
>>> this is exciting and I take it as a very good sign.
>>>
>>> A couple things have come up
>>>
>>> 1] The implementation milestone wiki should probably specific a draft
>>> version of TLS 1.3. Both -18 and -20 have been in common use (depending on
>>> what TLS library you are using) and this leads to a common interop failure.
>>> Presumably this isn't a problem we will have with the second milestone when
>>> the TLS WG will have settled on a final revision. I would argue for -20
>>> simply because its a later marker on the march of forward progress.
>>>
>>> 2] the text on connection_close doesn't indicate which peer does the
>>> close, or really when. If we want to do un-attended endpoint testing it
>>> might be a useful thing to profile. e.g. "the server sends connection close
>>> on a timer 2 seconds after the handshake is complete".. or something.
>>>
>>> -Patrick
>>>
>>>
>>>
>>
>



-- 
Kazuho Oku