Subject: [TLS] WGLC for draft-ietf-tls-dtls-connection-id-06

From: Joseph Salowey <[email-masked]>
Date: Mon, 15 Jul 2019 10:19:10 -0700

This the working group last call for draft-ietf-tls-dtls-connection-id-06.
The diff between the version that was last called (-03) and the current
version can be found here:
https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-06.txt&url1=draft-ietf-tls-dtls-connection-id-03

Please focus your review on the changes since the previous last call and
send comments to the list by July 22, 2019.

Thanks,

C,S & J

---

From: "Kraus Achim (INST/ECS4)" <[email-masked]>
Date: Tue, 16 Jul 2019 13:01:17 +0000

Hello Joe,
Hello List,

with the issues https://github.com/tlswg/dtls-conn-id/issues/64 reported by Thomas Fossati, 
and the mail from Hannes Tschofenig  (see http://ietf.10.n7.nabble.com/draft-tschofenig-tls-dtls-rrc-00-DTLS-Return-Routability-Check-RRC-td599108.html), 
I’m not sure, what the intended scope of "draft-ietf-tls-dtls-connection-id-06.txt" according this issues should be.

I would prefer to have the basic advice, to apply some kind of filter against modified replay attacks (either the 
DTLS 1.2 Anti-Replay protection, https://tools.ietf.org/html/rfc6347#section-4.1.2.6, or other means, see
proposal https://github.com/tlswg/dtls-conn-id/issues/69 ) in the "draft-ietf-tls-dtls-connection-id", 
instead of including that to an additional RFC together with the more complex "on-path adversary" scenario.

"An on-path adversary can also black-hole traffic or create a reflection attack against third parties because a DTLS peer has no	
 means to distinguish a genuine address update event (for example, due	to a NAT rebinding) from one that is malicious.  
This attack is of	concern when there is a large asymmetry of request/response message	sizes."

I would prefer either to remove the "black-hole traffic", because that is not related to DTLS 1.2 CID, or extend it into a 
more general statement, which clarifies, that it's not related to CID.

Mit freundlichen Grüßen / Best regards 

Achim Kraus

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

Von: TLS <[email-masked]> Im Auftrag von Joseph Salowey
Gesendet: Montag, 15. Juli 2019 19:19
An: <[email-masked]> <[email-masked]>
Betreff: [TLS] WGLC for draft-ietf-tls-dtls-connection-id-06

This the working group last call for draft-ietf-tls-dtls-connection-id-06.  The diff between the version that was last called (-03) and the current version can be found here: https://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-dtls-connection-id-06.txt&url1=draft-ietf-tls-dtls-connection-id-03

Please focus your review on the changes since the previous last call and send comments to the list by July 22, 2019.  

Thanks,

C,S & J

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 17 Jul 2019 11:33:20 -0400

These changes look fine.  Mostly.

I'm really concerned about shipping a protocol that enables the sorts of attacks that connection IDs enable.  I think that we should discuss that issue when we meet.  I know that Hannes' new draft is an attempt to tackle this issue, but that's a long way from being done.  If we ship a spec with this hole, it will only be usable in certain narrow contexts, like with ICE, where this really isn't a concern anyway.

This is something we are grappling with in QUIC too.  A good design that handles migration to new network paths is non-trivial.  Adding a connection ID is just the smallest and easiest part.  But it leaves the protocol in the worst possible state.  Functionally, you can move to a new path.  And everything works fine, unless you have an attacker.  But without any further defense, you are completely exposed to that attacker, both to the connection being denied service and to being used for amplification attacks.

Nit: Search for "use the with" in the newly added text.

On Mon, Jul 15, 2019, at 13:19, Joseph Salowey wrote:
> This the working group last call for 
> draft-ietf-tls-dtls-connection-id-06. The diff between the version that 
> was last called (-03) and the current version can be found here: 
> Please focus your review on the changes since the previous last call 
> and send comments to the list by July 22, 2019. 
> 
> Thanks,
> 
> C,S & J
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Thomas Fossati <[email-masked]>
Date: Wed, 17 Jul 2019 16:41:52 +0000

On 17/07/2019, 16:33, "TLS on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:
> I'm really concerned about shipping a protocol that enables the sorts
> of attacks that connection IDs enable.  I think that we should discuss
> that issue when we meet.  I know that Hannes' new draft is an attempt
> to tackle this issue, but that's a long way from being done.  If we
> ship a spec with this hole, it will only be usable in certain narrow
> contexts, like with ICE, where this really isn't a concern anyway.

I share the same worry that the document as it is at the moment creates
a dangerous situation if implemented in isolation, i.e. without RRC.

Originally I had proposed the text in [1].  The two MUSTs in that PR
should counter the man-on-the-side attacks described in [2].  They are
self-contained, cheap and effective countermeasures that an endpoint can
implement unilaterally.

This was before RRC was drafted.  Those paragraphs have now been moved
there; however, I think they really belong to conn-id.

My suggestion is we move that section back and point to RRC for the
"final" solution.  This doesn't give complete internal coherency to
conn-id -- which is indeed suboptimal -- but the recommendation to
provide peer address update call-backs provides at least a way out and
looks to me like the least worse solution given where we are.

Cheers, t

[1] https://github.com/tlswg/dtls-conn-id/pull/65/files
[2] https://github.com/tlswg/dtls-conn-id/issues/64#issue-448307810

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: Thomas Fossati <[email-masked]>
Date: Thu, 18 Jul 2019 22:09:56 +0000

> looks to me like the least worse solution given where we are.

Just FYI, the current state of the confab between Achim, Philippe and
myself is captured at:
https://github.com/tlswg/dtls-conn-id/compare/master...thomas-fossati:address-validation-take-2

cheers, t

---

From: Thomas Fossati <[email-masked]>
Date: Thu, 18 Jul 2019 22:12:07 +0000

cheers, t