You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Please add, that the other attacks could be applied "proactive" by an attacker.
But the attacks, changing the source address of a valid DTLS CID record, are passive attacks. The attacker must wait for such messages. That makes such attack in my opinion much less attractive.
A difference between (D)TLS and OSCORE is that in DTLS the updated address is used for all future records, while in OSCORE a new address is only used for responses to a specific request.
That depends on the roles.
A coap-server will usually also only send back the response to the last/current source address.
In my deployments, clients usually don't update the server's address using CID at all.
There is a difference in a description of a protocol, which offers symmetric function and is not coupled to other layers. And a real system, which can easily use such a coupling. Sure, someone may try a different approach, therefore draft-ietf-tls-dtls-rrc is on the way.
The text was updated successfully, but these errors were encountered:
(Due to lack of owner rights I could not transfer this repository and instead had to make a new one, I will manually create new issues there for any open issues).
Please add, that the other attacks could be applied "proactive" by an attacker.
But the attacks, changing the source address of a valid DTLS CID record, are passive attacks. The attacker must wait for such messages. That makes such attack in my opinion much less attractive.
That depends on the roles.
A coap-server will usually also only send back the response to the last/current source address.
In my deployments, clients usually don't update the server's address using CID at all.
There is a difference in a description of a protocol, which offers symmetric function and is not coupled to other layers. And a real system, which can easily use such a coupling. Sure, someone may try a different approach, therefore draft-ietf-tls-dtls-rrc is on the way.
The text was updated successfully, but these errors were encountered: