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

Achim Kraus <achimkraus@gmx.net> Thu, 23 July 2020 06:18 UTC

Return-Path: <achimkraus@gmx.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A2D3A08B7 for <tls@ietfa.amsl.com>; Wed, 22 Jul 2020 23:18:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gmx.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOPuHx_hcmQN for <tls@ietfa.amsl.com>; Wed, 22 Jul 2020 23:18:10 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9414E3A08B3 for <tls@ietf.org>; Wed, 22 Jul 2020 23:18:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1595485082; bh=MA4hs0LgUV2apd9QaGCgKrKUJ4X3aBq6TU1EGsKKZS4=; h=X-UI-Sender-Class:Subject:To:References:From:Date:In-Reply-To; b=HW4p0cMgJQ8PdZ0lAdpDZaOr75QTtn/+hAzm0NGdwEva6418e0y1jQfQO/fG56hph 9fN/s7HqrXKuyCWvpGKNvm0/fN2aGpBxLyrJgN2vFasylOxncbI3F5UO8W6rVNSg6F 3xDar5L3Z4yTNoO2cNuXszVFNbmrOJgZf7NGCLjw=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Received: from [192.168.178.45] ([178.10.250.83]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MpUUw-1kb6Yw1I20-00pwyq; Thu, 23 Jul 2020 08:18:02 +0200
To: tls@ietf.org, Martin Thomson <mt@lowentropy.net>
References: <0A9203D5-C4F3-4AA8-B59E-7D63E4650B3B@sn3rd.com> <401eb156-e8de-482a-92c5-aa423e211b5d@www.fastmail.com>
From: Achim Kraus <achimkraus@gmx.net>
Message-ID: <a8f9d79e-9337-053c-231c-441072e2e6d9@gmx.net>
Date: Thu, 23 Jul 2020 08:18:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0
MIME-Version: 1.0
In-Reply-To: <401eb156-e8de-482a-92c5-aa423e211b5d@www.fastmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K1:QG/wSLUjMy8+ynkp42ZjaBqQbFUK9c/YW/F9WVPdYAKvcHnxoWm 03X3zjx9QZlYLj90qmdMggE/U5nbV8WxkpVAp0PR7tdYvXluJygGup9m4plGPUmA8JApYDP 2PKb3pGoe7b4fgm6/zqcqBqIV87TuYNj2V1Qz1wtBRNjAzIH4Dc9b4AscmNa+D9jNp5rRGm vAfAo/4nHuDDVZaJ8S+kg==
X-UI-Out-Filterresults: notjunk:1;V03:K0:pKuAfop3H7I=:qjnHJbFpM4FeANEQ6W0C/o s583Rkv388Y29XP3nSIGMEfAKI4dFaxAjO+Izd+Ck+9D24jJ0ZTfoTqFGxAhxkL0M0nJxofHG sE8uCF0tfnCRs94l+ri5l3fC57to2+NrI0zFRKwvrU/mbTP0BA9UrabTTwK/4Cb2PBXIRTF9r vNkytJtuOfTHfCDG1JXgVGaMzmRVNbnX4q4eAStD5JlmjxbNXECHyZC0qVItUfa5UTaCnhuJF 65fUjzfW6hXIKG9SM0+MLo7BJqZLwE6G2N/0TUEK3Bf8n/cHjPTI/DeKNq4G7xtEuERKzEVrs SkRVdYOTKdJHyAGHgT8dxZfp2WWTWxpIxbTVLpKgvdYaKcVv/hnDpvU2UO+SlvpGIJbQLfygY lYuLT3f7CpGPjaj1069z17r+S2vpgusgJBFlbVPG+ejQLOT1nXGSeN6oi2B91j5/VGvq0TxAr EX7pGdqHXiDrqX9dhipJ7/z5TaGu2UfC6lQhaVllFW0s7zMXCu6PlIYYK1/XQKndJA2QKzXBZ mmkbM4k3wS1t8bF7WVbKWhowpR4AhJCUOzvYsz22hKCfjxCSOZ4HDsYGCB2eYC+WOsHYbOr0U ZLwiiwieofP3vnRiPEED7Xw21/Q+HtRkfaBjAacNDvXY7QXLA50c8ENzkLO+bR+1hqsTuoaWO CFwBOZzP2KJXd6pzqdthvBHiMEbumjV+3sH97WYApSeCsaHxqLAuuNp+0kxA7xAwP2VCNxvqP czwGVxmzwr5T5BEIL/WqU2PB+mBzT4W0euLEvGKzNnwMtqokGA+DOQWJdN6bEjyI9IuHLNQHF 6Gq8RO8gYTeX0UilFMRs/ohiZGNrAAd6PPXYnzi3SovFoVkWub9V1aGctc/D6I3DPD6co4dyu 0MDxec1t4zh7eJfIAzVuvCJ3bOn7noMgyhC205p/pTUNbl/tTfBuv13lW8Ms0pjv4BmRY5iLb ar6UmOtq1qQ0Y8PHW48p8MjwN/TTRdJV+LX7iqo8PwnQ5Wr/Zu8h6wx2KuozGbqxu3gEREaEf 6lWRSDJNix9ULlGAfh5LEsgZsIY3crTK8FQqBA5gYq36YRX/ImQYAGh+wcKinFJp6upfpf99n EnWWE5oZtz0USk5QkEscjS3jN77lTfSQVQFifhEQYXqmQ7Sf80zk+CVdQP4mxShWz9NyNYAB+ dfIQQwCDka+KL7Y2S60s1UsxkdhnE88hOaqj9ML42XBYWrv6UYqJqlM/gjL9uLkFHS1EmHltn oXwdqV//jbyHBueANGpKTPH1H52Mo5lntCbNarQ==
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/hfg-H27ZsAB4OUuuUChRqQ6UEhk>
Subject: Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jul 2020 06:18:11 -0000

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
>