Re: Handling consensus on design issues identified during AD Review

[Ian Swett <[e-mail]>]

I agree, thanks Kazuho.

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

> 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:
> > Thanks to chairs / editors / ADs for pushing the draft forward.
> >
> > My comments inline.
> >
> > 2020年10月20日(火) 21:32 Lars Eggert <[e-mail]>:
> > > 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
> >
> > Just to make sure, the solution is #4188 (merged on GitHub).
> > https://github.com/quicwg/base-drafts/pull/4188
> >
> > > * #4216 Connection Migration Failure when Path MTU is asymmetric
> > >   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
> > >   https://github.com/quicwg/base-drafts/issues/3701
> >
> > 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
>
>