Re: Handling consensus on design issues identified during AD Review

[Martin Thomson <[e-mail]>]

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