Subject: 2 Points of First Implementation Draft we might clarify

From: Patrick McManus <[email-masked]>
Date: Wed, 28 Jun 2017 13:51:10 -0700

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

---

From: Ian Swett <[email-masked]>
Date: Wed, 28 Jun 2017 16:53:38 -0400

Those both seem like good changes to me.

On Wed, Jun 28, 2017 at 4:51 PM, Patrick McManus <[email-masked]>
wrote:

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

---

From: Ian Swett <[email-masked]>
Date: Wed, 28 Jun 2017 17:10:42 -0400

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?

---

From: Martin Thomson <[email-masked]>
Date: Wed, 28 Jun 2017 14:12:49 -0700

> Would only supporting 18 cause problems for anyone?

Anyone using OpenSSL would have a real hard time.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 28 Jun 2017 14:13:35 -0700

and now we see the reason we have a problem :)

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jun 2017 15:42:53 -0700

My understanding was that BoringSSL had a -20 branch, as NSS does. Is that
incorrect?

-Ekr

---

From: Nick Harper <[email-masked]>
Date: Wed, 28 Jun 2017 15:50:05 -0700

https://boringssl.googlesource.com/boringssl/+refs does not show a -20 branch.

---

From: Steven Valdez <[email-masked]>
Date: Wed, 28 Jun 2017 23:44:45 +0000

While there was some work on draft 20 during the last IETF Hackathon, the
code is far from complete and still needs lots of tests and the
implementation of additional parts of the draft 20 changes, which
unfortunately won't happen for a while due to other issues*.

In general, it sounds like many TLS implementations at the very least have
a copy of the draft 18 code, from the previous IETF Hackathons (NSS,
OpenSSL, BoringSSL, etc) and it also sounds like at least other parties on
the TLS WG list (implementations and tools, Wireshark, Apple, etc) have
draft 18 reviewed in some form.

-Steven

* We've had a lot of issues actually deploying TLS 1.3 in the wild, and
most of our focus has been on gathering information on the ecosystem
intolerance and how to avoid it, and will likely continue prioritizing that
for the near future so we can give feedback to the TLS WG.

---

From: Jana Iyengar <[email-masked]>
Date: Wed, 28 Jun 2017 17:00:09 -0700

> Anyone using OpenSSL would have a real hard time.

Is anyone planning to use OpenSSL for the interop?

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jun 2017 00:48:18 +0000

> Anyone using OpenSSL would have a real hard time.

Well, not a real hard time.  Our current master is at 20, but the -18 version is tagged, so you'd be able to do it if necessary.

I hope it's not necessary; if this adds pressure to get the blockages unstuck...

---

From: Tatsuhiro Tsujikawa <[email-masked]>
Date: Thu, 29 Jun 2017 09:54:14 +0900

> Is anyone planning to use OpenSSL for the interop?
​I originally planed to use OpenSSL, but it turns out that it does not have
TLSv1.3 exporter yet.
I can live with boringssl (-18) for the first implementation draft.

Best regards,
Tatsuhiro Tsujikawa​

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 28 Jun 2017 17:58:26 -0700

I don't think it's disastrous to use -18, as that's what people have
generally fielded.

If/when people feel comfortable in their -20 branches, it would be good to
change to that, however.

-Ekr

On Wed, Jun 28, 2017 at 5:54 PM, Tatsuhiro Tsujikawa <[email-masked]>
wrote:

>> On Wed, Jun 28, 2017 at 2:12 PM, Martin Thomson <[email-masked]
>> > wrote:
>>
> ​I originally planed to use OpenSSL, but it turns out that it does not
> have TLSv1.3 exporter yet.

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 29 Jun 2017 01:01:02 +0000

OpenSSL has the exporter now, but it’s in master (draft 20) not the draft 18 branch.

---

From: Kazuho Oku <[email-masked]>
Date: Fri, 30 Jun 2017 15:58:50 -0700

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.

-- 
Kazuho Oku