Subject: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc

From: Sean Turner <[email-masked]>
Date: Wed, 22 Jul 2020 14:55:19 -0400

Hi!

The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3" have asked for adoption of their draft as a WG item.  Please state whether you support adoption of this draft as a WG item by posting a message to the TLS list by 2359 UTC 06 August 2020.  Please include any additional information that is helpful in understanding your position.

NOTE:
We discussed this draft at IETF 105 in connection with draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to progress draft-tschofenig-tls-dtls-rrc after we progressed draft-ietf-tls-dtls-connection-id. That time is now.

Thanks,
Chris, Joe, and Sean

[0] https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb-cid-00

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Jul 2020 19:07:49 +0000

Not much of a DTLS user, but I respect that the authors are.  I support adoption and will review it.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 23 Jul 2020 10:32:48 +1000

I'm OK with adoption.  

That said, I believe that this falls a long way short of addressing the attacks that I'm aware of.  But that assumes we share an understanding about what those attacks are.  To begin with, we probably need a clearer description of goals.  

To give an idea, address validation in QUIC is much more complex than is proposed here, for reasons I believe to be good.  If this document does less than QUIC, it needs to justify that.

On Thu, Jul 23, 2020, at 04:55, Sean Turner wrote:
> Hi!
> 
> The authors of "Return Routability Check for DTLS 1.2 and DTLS 1.3" 
> have asked for adoption of their draft as a WG item.  Please state 
> whether you support adoption of this draft as a WG item by posting a 
> message to the TLS list by 2359 UTC 06 August 2020.  Please include any 
> additional information that is helpful in understanding your position.
> 
> NOTE:
> We discussed this draft at IETF 105 in connection with 
> draft-ietf-tls-dtls-connection-id [0]. The plan at the time was to 
> progress draft-tschofenig-tls-dtls-rrc after we progressed 
> draft-ietf-tls-dtls-connection-id. That time is now.
> 
> Thanks,
> Chris, Joe, and Sean
> 
> [0] 
> https://datatracker.ietf.org/meeting/105/materials/slides-105-tls-sessb-cid-00
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Achim Kraus <[email-masked]>
Date: Thu, 23 Jul 2020 08:18:00 +0200

Hello Martin,
Hello list,

 > That said, I believe that this falls a long way short of addressing
the attacks that I'm aware of.  But that assumes we share an
understanding about what those attacks are.  To begin with, we probably
need a clearer description of goals.

Fully agreed. Unfortunately, that discussion seems to be either not
public, or, somehow, stale.

https://github.com/tlswg/dtls-conn-id/pull/71

So, if you have any update, please provide the details, where to find it.

 > To give an idea, address validation in QUIC is much more complex than
is proposed here, for reasons I believe to be good.  If this document
does less than QUIC, it needs to justify that.

I disagree. QUIC (as any other technology) sticks to use-cases, and the
therefore the definitions there are also depend on the use-case.

https://github.com/quicwg/base-drafts/blob/master/draft-ietf-quic-transport.md#address-validation

"Address validation ensures that an endpoint cannot be used for a
traffic amplification attack. In such an attack, a packet is sent to a
server with spoofed source address information that identifies a victim.
If a server generates more or larger packets in response to that packet,
the attacker can use the server to send more data toward the victim than
it would be able to send on its own.

The primary defense against amplification attack is verifying that an
endpoint is able to receive packets at the transport address that it
claims."

In my opinion, the primary defense depends on the use-case.

1. Just don't sent anything back is the very primary defense.

That will not work for all use-cases, therefore the secondary defense is

2. Just don't sent back more than received.

(Considering DDoS results in a combination of the primary and secondary
defense, means only send back responses, limited by size and number.)

That again limits also the use-cases, therefore the third defense is
then the

3. "primary defense" of QUIC.

The difference between QUIC and RRC could analyzed from both ends.
The one may justify, why they don't consider something and therefore do
less. The others may also justify, why they consider something
additionally, and therefore do more.

In the end, it's more the question, who is intended to invest the time.

best regards
Achim Kraus

---

From: Sean Turner <[email-masked]>
Date: Fri, 31 Jul 2020 20:55:05 -0400

Just a reminder that this WG adoption call is still ongoing.

spt

> On Jul 22, 2020, at 14:55, Sean Turner <[email-masked]> wrote:
> 
> Hi!
>