Subject: Re: Consensus Calls on Recent Transport/TLS Issues

From: Mark Nottingham <[email-masked]>
Date: Tue, 4 Jun 2019 10:00:15 +1000

Hearing no pushback, consensus declared.

Cheers,

> On 28 May 2019, at 3:33 pm, Mark Nottingham <[email-masked]> wrote:
> 
> The following issues have proposals for resolution, and discussion so far seems to support consensus to accept them. If you object, please do so on the issue or in response to this message (changing the Subject appropriately!).
> 
> * #2732 - Reusing SRTs  ( PR#2733)
> * #2580 - Is path validation a SHOULD or a MUST?  (PR#2637)
> * #2689 - Checking duplicate TPs is onerous   (PR#2691)
> * #2192 - Optimistic ACK in early handshake  (close with no action)
> * #2471 - Stateless Reset lacks Normative Text  (PR#2574)
> * #2581 - Bring back AEAD_AES_128_CCM_8  (PR#2743)
> * #2552 - Saving a round-trip time in the initial handshakes with retry  (close with no action; mark issue as quicv2)
> * #2394 - Spoofed retry token attack on IP authentication  (close with no action)
> * #2308 - Handling of coalesced packets with decryption errors creates DoS opportunity  (PR#2747)
> * #2267 - Loss of only two packets can lead to an unrecoverable situation  (PR#2673)
> * #2441 - Peers that only terminate a single connection on an IP/port cannot migrate with 0-byte CIDs  (close with no action; mark issue as quicv2)
> * #2214 - Simultaneous key update can lead to deadlock  (PR#2673)
> * #2458 - Client MUST use 1-RTT packets if it reads 1-RTT packets  (PR#2461)
> * #2672 - Transport error codes would be smaller and more consistent as a varint  (PR#2680)
> * #2582 - Attacks Against Address Migration  (PR#2637)
> * #2579 - Path validation should be done even for what looks like NAT rebinding  (PR#2637)
> * #2360 - 0-RTT flow control limits can't be increased  (PR#2461)
> 
> Absent any pushback, we'll declare consensus at the end of the week.
> 
> Cheers,
> 
> --
> Mark Nottingham   https://www.mnot.net/
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 13 Jun 2019 13:14:00 +0100

On 28/05/2019 06:33, Mark Nottingham wrote:
> *

Could someone explain why the new change is safe relative to RFC6298?

I think the proposed text was:

... 1 second initial handshake timeout as recommended in
  {{?RFC6298}}.

  A connection MAY use the delay between sending a PATH_CHALLENGE and 
receiving
  a PATH_RESPONSE to seed initial_rtt for a new path, but the delay 
SHOULD NOT
  be considered an RTT sample."

... Maybe I am wrong, but I interpret RFC6298 as saying the seed value 
should be 1.5 x larger than this RTT value?

(To account for RTT variance.)

Gorry

---

From: "Martin Thomson" <[email-masked]>
Date: Fri, 14 Jun 2019 07:40:08 +1000

On Thu, Jun 13, 2019, at 22:14, Gorry Fairhurst wrote:
> .... 1 second initial handshake timeout as recommended in
>   {{?RFC6298}}.
> 
> .... Maybe I am wrong, but I interpret RFC6298 as saying the seed value 

This is good feedback.

I've opened https://github.com/quicwg/base-drafts/issues/2789

I don't think that this is critical, because the seed will be erased after the first RTT sample arrives.  But we should allow for some increase in the RTT on the path and being slightly more conservative might reduce the rate that packets hit those new paths.