Subject: Handling consensus on design issues identified during AD Review

From: Lars Eggert <[email-masked]>
Date: Tue, 20 Oct 2020 15:32:11 +0300

Hi,

we are getting very close to publishing a new set of drafts that address Magnus' AD Review comments and will then be taken to IETF Last Call.

The vast majority of changes were editorial, but there were three "design" issues that changed the protocol in non-editorial ways, for which we need to confirm WG consensus. These issues are:

* #4183 Handshake failure (infinite ping-pong) when path MTU is asymmetric
  https://github.com/quicwg/base-drafts/issues/4183

* #4216 Connection Migration Failure when Path MTU is asymmetric
  https://github.com/quicwg/base-drafts/issues/4216

* #3701 The QUIC-TLS draft should define anti-forgery limits for packet lengths up to 2^16
  https://github.com/quicwg/base-drafts/issues/3701

The resolutions for these issues are linked from the respective issue pages, and will be merged into the text of the upcoming draft revisions, together with the editorial changes.

Instead of performing a separate WG Last Call and further delaying the start of the IETF Last Call, we've agreed with our AD to judge WG consensus on these design changes as part of the IETF Last Call.

Thanks,
Lars and Lucas

---

From: Kazuho Oku <[email-masked]>
Date: Tue, 20 Oct 2020 23:32:41 +0900

Thanks to chairs / editors / ADs for pushing the draft forward.

My comments inline.

2020年10月20日(火) 21:32 Lars Eggert <[email-masked]>:

> Hi,
>
> we are getting very close to publishing a new set of drafts that address
> Magnus' AD Review comments and will then be taken to IETF Last Call.
>
> The vast majority of changes were editorial, but there were three "design"
> issues that changed the protocol in non-editorial ways, for which we need
> to confirm WG consensus. These issues are:
>

Just to make sure, the solution is #4188 (merged on GitHub).
https://github.com/quicwg/base-drafts/pull/4188

>   https://github.com/quicwg/base-drafts/issues/4216

The solution is #4226 (open on GitHub).
https://github.com/quicwg/base-drafts/pull/4226

* #3701 The QUIC-TLS draft should define anti-forgery limits for packet
> lengths up to 2^16

The solution is #4175 (merged on GitHub).
https://github.com/quicwg/base-drafts/pull/4175

Regarding #4183 and #4216, I have a tiny preference, in short, I think
#4253 (PR #4254) should be merged as part of the pair.
https://github.com/quicwg/base-drafts/pull/4254

The two issues cover the same problem: how to fail when the MTU of the path
in one direction is below 1200 bytes. Both say "MUST pad to datagrams to at
least 1200 bytes," and that's fine. OTOH, #4183 says that a receiver MAY
close the connection if the sender fails to meet the padding requirement.
#4216 does not provide guidance to the receiver side.

For #4216, it is my understanding that we have to state that the receiver
MUST NOT try to enforce the behavior of the sender, as the size of UDP
datagrams is not authenticated. Ignoring unauthenticated signal is the
basis of a secure transport protocol. That in turn raises the question on
if the guidance that we adopted in #4183 (i.e. MAY close) has been correct.
To be precise, it is questionable if Initial packets are "authenticated,"
as they are not protected by keys only known to the endpoints. But still,
it sticks out from the design principle of a secure transport protocol.

That's why I think we should merge #4254 alongside the other two, so that
we'd be principled, that we'd have less rules.

>
> The resolutions for these issues are linked from the respective issue
> pages, and will be merged into the text of the upcoming draft revisions,
> together with the editorial changes.
>
> Instead of performing a separate WG Last Call and further delaying the
> start of the IETF Last Call, we've agreed with our AD to judge WG consensus
> on these design changes as part of the IETF Last Call.
>
> Thanks,
> Lars and Lucas
>

-- 
Kazuho Oku

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 21 Oct 2020 01:40:46 +1100

Kazuho has identified the set of changes that I too think we should take.  Thanks Kazuho.

On Wed, Oct 21, 2020, at 01:32, Kazuho Oku wrote:
> The two issues cover the same problem: how to fail when the MTU of the 
> path in one direction is below 1200 bytes. Both say "MUST pad to 
> datagrams to at least 1200 bytes," and that's fine. OTOH, #4183 says 
> that a receiver MAY close the connection if the sender fails to meet 
> the padding requirement. #4216 does not provide guidance to the 
> receiver side.
> 
> For #4216, it is my understanding that we have to state that the 
> receiver MUST NOT try to enforce the behavior of the sender, as the 
> size of UDP datagrams is not authenticated. Ignoring unauthenticated 
> signal is the basis of a secure transport protocol. That in turn raises 
> the question on if the guidance that we adopted in #4183 (i.e. MAY 
> close) has been correct. To be precise, it is questionable if Initial 
> packets are "authenticated," as they are not protected by keys only 
> known to the endpoints. But still, it sticks out from the design 
> principle of a secure transport protocol.
> 
> That's why I think we should merge #4254 alongside the other two, so 
> that we'd be principled, that we'd have less rules.
> 
> > 
> >

---

From: Ian Swett <[email-masked]>
Date: Tue, 20 Oct 2020 10:44:49 -0400

I agree, thanks Kazuho.

On Tue, Oct 20, 2020 at 10:41 AM Martin Thomson <[email-masked]> wrote:

> > > we are getting very close to publishing a new set of drafts that
> address Magnus' AD Review comments and will then be taken to IETF Last Call.
> > >
> > > The vast majority of changes were editorial, but there were three
> "design" issues that changed the protocol in non-editorial ways, for which
> we need to confirm WG consensus. These issues are:
> > >