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
Am 23.07.20 um 02:32 schrieb Martin Thomson:
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
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
