Re: [TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC)

Simon Bernard <contact@simonbernard.eu> Tue, 09 July 2019 12:47 UTC

Return-Path: <contact@simonbernard.eu>
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 54F01120145 for <tls@ietfa.amsl.com>; Tue, 9 Jul 2019 05:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 Y54SwUTKxeLc for <tls@ietfa.amsl.com>; Tue, 9 Jul 2019 05:47:33 -0700 (PDT)
Received: from 4.mo6.mail-out.ovh.net (4.mo6.mail-out.ovh.net [87.98.184.159]) (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 201AC1200FE for <tls@ietf.org>; Tue, 9 Jul 2019 05:47:32 -0700 (PDT)
Received: from player731.ha.ovh.net (unknown [10.108.35.197]) by mo6.mail-out.ovh.net (Postfix) with ESMTP id 0FD4B1D0F1F for <tls@ietf.org>; Tue, 9 Jul 2019 14:47:28 +0200 (CEST)
Received: from simonbernard.eu (134.163-14-84.ripe.coltfrance.com [84.14.163.134]) (Authenticated sender: contact@simonbernard.eu) by player731.ha.ovh.net (Postfix) with ESMTPSA id EF92E7A12BA3; Tue, 9 Jul 2019 12:47:24 +0000 (UTC)
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>
References: <VI1PR08MB5360A60F2F16D354DA6F9FD2FAF10@VI1PR08MB5360.eurprd08.prod.outlook.com>
From: Simon Bernard <contact@simonbernard.eu>
Message-ID: <2d58dc10-6fa1-2d2c-bf84-52fdb3a60a69@simonbernard.eu>
Date: Tue, 09 Jul 2019 14:47:19 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1
MIME-Version: 1.0
In-Reply-To: <VI1PR08MB5360A60F2F16D354DA6F9FD2FAF10@VI1PR08MB5360.eurprd08.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------A40820CA195EE05CDA1D524A"
Content-Language: en-US
X-Ovh-Tracer-Id: 10151113563571566833
X-VR-SPAMSTATE: OK
X-VR-SPAMSCORE: -100
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduvddrgedvgdehlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/KGaKWyxYStoLJoh_alP6V0zEBno>
Subject: Re: [TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (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: Tue, 09 Jul 2019 12:47:36 -0000

Hi,

   Should "return_routability_check" use flight retransmission [1] ?

> Should the heartbeat message be re-used instead of the proposed new 
> message exchange? 

   It sounds really similar, except that if heartbeat failed we 
terminate the connection and for "return_routability_check" we update 
the peer address.

   Must heartbeat message be authenticated and encrypted using the 
currently active security context ? reading the RFC[2] it's not clear to me.

   heartbeat RFC also explains how to handle heartbeat message during 
handshake. Maybe this RFC should clarify this too.

Simon

[1] https://tools.ietf.org/html/rfc6347#section-4.2.4
[2] https://tools.ietf.org/html/rfc6520

Le 09/07/2019 à 11:05, Hannes Tschofenig a écrit :
>
> Hi all,
>
> working on the DTLS connection id drafts we noticed that there is one 
> security aspect, which could benefit from an extra mitigation technique.
>
> The issue is that an on-path adversary could intercept and modify the 
> source IP address  (and the source port) of a DTLS datagram.  Even if 
> receiver checks the authenticity and freshness of the packet, the 
> recipient is fooled into changing the CID-to-IP/port association. This 
> can lead to black-holed or redirected traffic. Of course, an on-path 
> adversary can do lots of things to traffic and the problem is 
> self-fixing but it still lead us to work on a solution in form of a 
> return-routability check.
>
> Here is the draft:
>
> https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00
>
> Ciao
>
> Hannes
>
> IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose 
> the contents to any other person, use it for any purpose, or store or 
> copy the information in any medium. Thank you.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls