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

"Kraus Achim (INST/ECS4)" <Achim.Kraus@bosch-si.com> Wed, 10 July 2019 13:28 UTC

Return-Path: <Achim.Kraus@bosch-si.com>
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 2552512010C for <tls@ietfa.amsl.com>; Wed, 10 Jul 2019 06:28:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 l2oZTIs-p34Y for <tls@ietfa.amsl.com>; Wed, 10 Jul 2019 06:28:18 -0700 (PDT)
Received: from de-out1.bosch-org.com (de-out1.bosch-org.com [139.15.230.186]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 402561200DE for <tls@ietf.org>; Wed, 10 Jul 2019 06:28:18 -0700 (PDT)
Received: from si0vm1947.rbesz01.com (unknown [139.15.230.188]) by si0vms0216.rbdmz01.com (Postfix) with ESMTPS id 45kKkl0JX8z1XLG79; Wed, 10 Jul 2019 15:28:15 +0200 (CEST)
Received: from si0vm2082.rbesz01.com (unknown [10.58.172.176]) by si0vm1947.rbesz01.com (Postfix) with ESMTPS id 45kKkl08MTz6CjR2y; Wed, 10 Jul 2019 15:28:15 +0200 (CEST)
X-AuditID: 0a3aad16-4b5ff70000005941-ec-5d25e7ee7ea0
Received: from si0vm1949.rbesz01.com ( [10.58.173.29]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by si0vm2082.rbesz01.com (SMG Outbound) with SMTP id AE.97.22849.EE7E52D5; Wed, 10 Jul 2019 15:28:14 +0200 (CEST)
Received: from SI-MBX2033.de.bosch.com (si-mbx2033.de.bosch.com [10.3.230.36]) by si0vm1949.rbesz01.com (Postfix) with ESMTPS id 45kKkk5FxFz6Cjg8W; Wed, 10 Jul 2019 15:28:14 +0200 (CEST)
Received: from SI-MBX2033.de.bosch.com (10.3.230.36) by SI-MBX2033.de.bosch.com (10.3.230.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.1713.5; Wed, 10 Jul 2019 15:28:14 +0200
Received: from SI-MBX2033.de.bosch.com ([fe80::e8d2:d090:af15:3320]) by SI-MBX2033.de.bosch.com ([fe80::e8d2:d090:af15:3320%4]) with mapi id 15.01.1713.007; Wed, 10 Jul 2019 15:28:14 +0200
From: "Kraus Achim (INST/ECS4)" <Achim.Kraus@bosch-si.com>
To: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, "tls@ietf.org" <tls@ietf.org>
Thread-Topic: draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC)
Thread-Index: AdU2NXH6l5nrxsDQQh2DGNc/pbIIBAA6VytA
Date: Wed, 10 Jul 2019 13:28:14 +0000
Message-ID: <e3bc5e3d0d334f73bde172efc9150719@bosch-si.com>
References: <VI1PR08MB5360A60F2F16D354DA6F9FD2FAF10@VI1PR08MB5360.eurprd08.prod.outlook.com>
In-Reply-To: <VI1PR08MB5360A60F2F16D354DA6F9FD2FAF10@VI1PR08MB5360.eurprd08.prod.outlook.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.22.83.209]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA22TYUwbdRjG+d8d5eh2cj1a+tpRozdZjGZY2IgIy/SLbvHLzJxMHeiOcWur 0JJeu7EZtZpJZtVJaseQbYwthehcy9YlWuk6Rjs0oGy64dYSI64UxhAkw2RjiUHvOFj7wS+X 5573fs/7f9+7I3HGRepIs8XO2yxcLatQEsoyn371XzcLqgxdQ2tK4y0DWOnsZRd6Ftt4qu0U 2uj13sNexF5Trqvha827eNuT67crTVdcn2fVD7INYWeCcKJv810omwR6LQz5xhSSZugWDO40 c7I+j8B9VO9CSlFPI7ja/RMh31xA0D0/vUAo6DJwt0ezJK2mN8NnM+4FnUu/DPHGOYXsV8Cl 6S9FmBR1MXguUpJN0AXQN/c7kjRFl8PM/nFCblwJv12/iUs6m64C/y/BhRhE6+H06csLPk5r ITB+N1MegAbvOdkHWgO3RucX/Yeh/1IIyc8XQuygRyHrJ6Dz+J+43FcF/V8kiSaU15oW25qG tKYhrWlIOyJOIo1gNuyqKzaUFhfaqnlhr6GocIe1LoDk95MXRB0DOyMII1EElZAYq6Eafiyo Yh6ottbsMXGC6Q2bo5YXWB2V//MLlUzufVtwVNeZBcFstUQQkDirps5vWFnFUDXcnr28zSpj EbSCJFgtZSQ3VTK0kbPzb/F8PW9bqpaTJAtUu/iFMCobb+Qbdppr7UtlVk+hjIwMJi+9kt4W I7MjaA25XOz9phRBCfVcnWA2LuIPyjiz5KbQAbSJbLp19ARO9va1idf4jPcEzhAWq4XXaanG cTGLliiTw3L/NLp8imLFATVphVTiJIohErG5VIkELxd/gtQ5gFohrU61aKagYq/I0L/mQqyR gq7RjxEEzn6PINFxAIM/mp04+IddOMx5ZghoCX+YCYGvwpkQSvyTCW2JJgVc+OZKFkyOBEno ORQjYe5i4zL49/1ry8Af8FFw8lg3BRPzx3Jgf8KfI3rncuBGeJgG98QRFfQlOxk4sy/MwEg8 zoB77IgaPujyqSEU7FVDbCqqgZbmTi20eaPaSXHHmLjjd19lpR3bOfv/7HjRTQ2ncyJP8JHm 7bd7d4ce4uKzvUb3c/N/b10XuftDz9jVbTeS6+8kH/VlHf7unvN5f8U+Olr+TPsnfd7B/tsq 74bBLY6Rr4dXxZpWHqJGK7CDT6+eyvd8+nrhSz0hw9BHw2WvJDZ37Pa85/JvPWCbeOftoR0l Y09Fr005Zh9LFvUk1l7XZxzGcZolBBNX9DhuE7j/ANSwwh+dBAAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/MkwRdvkQamGNRil0A-DKN6mt8OE>
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: Wed, 10 Jul 2019 13:28:22 -0000

Hi Hannes,

there was already a short discussion about that topic, see
https://github.com/tlswg/dtls-conn-id/issues/64.

I also created a new issue https://github.com/tlswg/dtls-conn-id/issues/69,
because I got aware of a pitfall (record reordering with address changes) close to that original issue.


---------------------------
https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00#section-1

"This attack is possible because the
network and transport layer identifiers, such as source IP address
and source port numbers, are not integrity protected and
authenticated by the DTLS record layer."

FMPOV 

"This attack is possible because the
network and transport layer identifiers, such as source IP address
and source port numbers, could not be integrity protected and
authenticated by the DTLS record layer." 

Doing so would break NATs, so I think it's better to express, that it is not possible to protect them.

---------------------------
https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00#section-3

"Furthermore, when using CID, anti-replay protection MUST be enabled.
This is to ensure that a man-on-the-middle attacker sending a
previously captured record with a modified source IP address and port
will not be able to successfully pass the above check (since the
datagram is very likely discarded on receipt - if it falls outside
the replay window)."

With my new issue https://github.com/tlswg/dtls-conn-id/issues/69 above, 
I think this could be relaxed to keep the highest "epoch/sequence_number" and 
the address MUST only be updated, if the received record has a higher order according
that "epoch/sequence_number".

I'm not sure, maybe it's unusual, but I would mention 
https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-05 as example.

---------------------------
https://tools.ietf.org/html/draft-tschofenig-tls-dtls-rrc-00#section-4


"Return Routability Check    -------->
      (cookie)
      Src-IP=B
      Dst-IP=Z"

FMPOV, if a peer uses TLS12_CID records, all records should use that format and use the inner type to differentiate that type.

https://github.com/tlswg/dtls-conn-id/blob/master/draft-ietf-tls-dtls-connection-id.md#the-connection_id-extension

"If DTLS peers have negotiated the use of a CIDs ...
the new record layer format with the tls12_cid content type defined in {{dtls-ciphertext}} MUST be used."

"Return Routability Check    -------->
      <CID=100>
      (cookie)
      Src-IP=B
      Dst-IP=Z"

Adding "<CID=100>" should point to that.


As I wrote in https://github.com/tlswg/dtls-conn-id/issues/64, if the heartbeat is
used as an inner type send in a TLS12_CID record, it may be also used for that check. 
Are there reasons not using the heartbeat? If not, I'm also not sure, if a new 
record_type pays off (Simon asked this also on his e-mail).

Mit freundlichen Grüßen / Best regards

Achim Kraus

Engineering Cloud Services 4 Bosch IoT Hub (INST/ECS4)

Von: TLS <tls-bounces@ietf.org> Im Auftrag von Hannes Tschofenig
Gesendet: Dienstag, 9. Juli 2019 11:06
An: tls@ietf.org
Betreff: [TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC)

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.