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

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 9 Jul 2019 09:05:36 +0000

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.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 09 Jul 2019 20:15:54 +1000

Hey Hannes,

This definitely looks like it needs attention.

This looks fairly lightweight, which is a good goal, but we have lots of experience with this in QUIC now that suggests that there are trivial denial of service attacks that can be mounted on simple designs.  Have you looked at the connection migration section in QUIC in any detail?  There are a few cases described there that don't appear to be covered in your proposed design.  

It's possible that you have a different threat model in mind, so maybe this doesn't apply.  We might be well served by having a discussion about that though.

On Tue, Jul 9, 2019, at 19:05, Hannes Tschofenig wrote:
>  
> 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:
> 
>  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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Simon Bernard <[email-masked]>
Date: Tue, 9 Jul 2019 14:47:19 +0200

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 :
> 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.
>

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Wed, 10 Jul 2019 13:28:14 +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 <[email-masked]> Im Auftrag von Hannes Tschofenig
Gesendet: Dienstag, 9. Juli 2019 11:06
An: [email-masked]
Betreff: [TLS] draft-tschofenig-tls-dtls-rrc-00 - DTLS Return Routability Check (RRC)

Hi all, 

Here is the draft:

Ciao
Hannes