Subject: [quicwg/base-drafts] This seems like tuning (#4020)

From: Lars Eggert <[email-masked]>
Date: Wed, 19 Aug 2020 07:31:17 -0700

(Broken out of #3214.)

> Servers that do not support a particular version
>   are unlikely to be able to decrypt the payload of the packet.
>   Servers SHOULD NOT attempt to decode or decrypt/
- This seems like tuning? Or is the intention to protect the endpoint from an attack, please explain the SHOULD.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020

---

From: Mike Bishop <[email-masked]>
Date: Wed, 19 Aug 2020 12:49:30 -0700

> The first packet for an unsupported version can use different semantics and
encodings for any version-specific field.  In particular, different packet
protection keys might be used for different versions.  Servers that do not
support a particular version are unlikely to be able to decrypt the payload of
the packet.  Servers SHOULD NOT attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet, provided that
the packet is sufficiently long.

I'm having trouble seeing what's needed here.  The endpoint has received a packet professing to be in a version it does not understand.  It can't know the semantics or encoding of any field there -- and the paragraph already explains that.  Yes, I'm sure there are potential attacks in interpreting a packet of unknown provenance and unknown semantics against a different set of semantics and expectations, but I'm not convinced we need to explain them.  The text recommends sending a Version Negotiation packet, which seems like the only sensible response.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020#issuecomment-676626863

---

From: Marten Seemann <[email-masked]>
Date: Thu, 20 Aug 2020 01:41:18 -0700

This refers to [5.2.2 Server Packet Handling](https://quicwg.org/base-drafts/draft-ietf-quic-transport.html#name-server-packet-handling).

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020#issuecomment-677462649

---

From: Lars Eggert <[email-masked]>
Date: Mon, 24 Aug 2020 23:57:44 -0700

@gorryfair?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020#issuecomment-679841646

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 25 Aug 2020 02:11:05 -0700

I'm looking for two things:

(i) I think this ought to clarify the intention for the SHOULD, I suspect it is clear to those working on this part, but not clear to me why this is a recommendation - i.e., specifically can you give me a use-case of why the Server would otherwise *USE* information from a packet from an unknown version, unless the intention is to say the server shouldn't waste resources to do try to do this? 
(ii) I think this implies understanding of Section 14.1 later in the spec, and a ref would help.

So...
* Is it equally true that..  
"Servers MUST NOT use the contents of a packet with an unknown version, and SHOULD NOT decrypt this packet, but instead send a Version Negotiation packet, provided that
the packet is sufficiently long (see Section 14.1)."?

* Or perhaps simply explain something like: 
"Servers SHOULD NOT commit resources to attempt to decode or decrypt a packet from an
unknown version, but instead send a Version Negotiation packet, provided that
the packet is sufficiently long (see Section 14.1)."?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020#issuecomment-679905159

---

From: Mike Bishop <[email-masked]>
Date: Tue, 25 Aug 2020 08:54:40 -0700

Fundamentally, it's a caution against assumptions which could prove incorrect, such as "this looks like an unencrypted TLS ClientHello, so I can go find the field that contains...."  The server will either process information in a way that could be used maliciously, or the server will generate a response that won't be understood by the client.  Ideally, this would be a MUST, except that it's entirely unenforceable by the client what the server does internally.

Perhaps the right solution here is to remove the normative language with regard to that piece:

> The first packet for an unsupported version can use different semantics and encodings for any version-specific field. In particular, different packet protection keys might be used for different versions. Servers that do not support a particular version are unlikely to be able to decrypt the payload of the packet. Servers SHOULD respond with a Version Negotiation packet, provided that the ~~packet~~ **datagram** is sufficiently long.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020#issuecomment-680112377

---

From: Gorry Fairhurst <[email-masked]>
Date: Tue, 25 Aug 2020 09:05:05 -0700

That approach seems fine.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020#issuecomment-680118557

---

From: Jana Iyengar <[email-masked]>
Date: Tue, 25 Aug 2020 15:19:20 -0700

Closed #4020 via #4053.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/4020#event-3692134892