Issue818 tls #830

ekr · 2017-08-26T17:28:37Z

No description provided.

juberti · 2017-08-26T18:13:28Z

tools/gen_examples.py

@@ -412,9 +414,11 @@ def simple_example(draft):
      'ice_pwd': 'mqyWsAjvtKwTGnvhPztQ9mIf', 'dtls_dir': 'passive' }
  ]
  fp1 = '19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2'
+  tid1 = '91bbf309c0990a6bec11e38ba2933cee'


Can these simply be monotonically increasing integers, for simplicity?

They are required to have 120 bits of entropy, so they have to be long. but I could do H(integer) if you like.

oh, ok. Do you know why? The dtls-sdp document doesn't provide any rationale for this.

See cdh4u/draft-dtls-sdp#36

Luckily, we don't need to decide this for this document/PR because clearly long is OK. Do you want me to change them to be H(integer)?

juberti · 2017-08-26T18:14:20Z

draft-ietf-rtcweb-jsep.xml

@@ -3540,12 +3540,12 @@ candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host

              <t>tls-id value, which MUST be set according to
              <xref target="I-D.ietf-mmusic-dtls-sdp" />, Section 5. If
-              this is a re-offer and the tls-id value is different
+              this is a re-offer or a response to a re-offer
+              and the tls-id value is different


If the remote DTLS id changes, and the local side is not performing an ICE restart, what then?

That's apparently forbidden:
When a new DTLS association is established over an unordered
transport, in order to disambiguate any packets associated with the
newly established DTLS association, at least one of the endpoints
MUST allocate a completely new set of ICE candidates which were not
recently used for any other DTLS association. This means the
answerer cannot initiate a new DTLS association unless the offerer
initiated ICE restart [I-D.ietf-ice-rfc5245bis]. If the answerer
wants to initiate a new DTLS association, it needs to initiate an ICE
restart and a new offer/answer exchange on its own. However, an ICE
restart does not by default require a new DTLS association to be
established.

So the answerer can change the tls-id, even if the offerer did not, but only if ICE is already restarting.

Seems kind of strange to permit this corner case; do you know what the thinking is here?

No, I do not.

OK. I would suggest that we should instead explode if the TLS id changes on the remote side during an ICE restart and the offerer didn't change it.

so not sure I care about the following case but consider it ... the browser is using webrtc to connect to a farm of servers that are all streaming the music on hold or a football game or whatever ... session is set up and browser does an ICE restart as the wifi interface just came up on mobile device browser is running on. The offer does not change tls-id. Now the call lands on a new server and it needs new TLS session. The answer replies with a new tls-id. Seems like this should be OK

fluffy · 2017-08-28T00:22:39Z

In section 5.10, the text that says to tear down the old TLS connections seems like it needs a tweek. For the case of a PR_ANS, I would expect it to not get torn down until the resources are freed when the ANS happens.

fluffy

see comments

ekr · 2017-09-01T16:39:24Z

See: cdh4u/draft-dtls-sdp#37

ekr · 2017-09-29T15:15:35Z

We had a call to discuss and I think reached resolution on the SDP issue. I will prepare a PR and send to the list for approval. Separately we need to close on tls-id size, but that need not hold JSEP if we are willing to have the examples use the longer size (which we all agree is permitted)

ekr · 2017-09-29T15:55:37Z

Update: we had a call to discuss this and I think have resolution on the SDP semantics. I will prepare a PR for that and send to lists. Separately, we have to discuss the S

juberti · 2017-10-06T16:05:18Z

draft-ietf-rtcweb-jsep.xml

@@ -3041,6 +3041,12 @@ candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host
            section is bundled into another m= section, it still MUST
            NOT contain any ICE credentials.</t>

+            <t>Each "a=tls-id" line MUST stay the same unless the
+            offeror's "a=tls-id" line changed, in which case a new


juberti · 2017-10-06T16:06:01Z

draft-ietf-rtcweb-jsep.xml

@@ -3041,6 +3041,12 @@ candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host
            section is bundled into another m= section, it still MUST
            NOT contain any ICE credentials.</t>

+            <t>Each "a=tls-id" line MUST stay the same unless the
+            offeror's "a=tls-id" line changed, in which case a new
+            "a=tls-id" line MUST be added, as described in


A new line? Or a new value?

juberti · 2017-10-07T19:33:22Z

draft-ietf-rtcweb-jsep.xml

-              present, MUST be the same as in the offer.</t>
+              values. Note that although JSEP requires that answers
+              change the tls-id value if and only if the offerer does,
+              answerer, non-JSEP answerers are permitted to change the


remove 'answerer,'

juberti · 2017-10-07T19:37:05Z

draft-ietf-rtcweb-jsep.xml

+              change the tls-id value if and only if the offerer does,
+              answerer, non-JSEP answerers are permitted to change the
+              tls-id as long as the offer contained an ICE restart.
+              Thus, JSEP implementations which process DTLS data prior


This applies to fingerprint changes as well; suggest moving this to 5.11, where we talk about the need to start a new DTLS connection if either the tls-id or fingerprint changes.

ekr

Juberti, PTAL

ekr · 2017-10-09T18:05:19Z

draft-ietf-rtcweb-jsep.xml

-              present, MUST be the same as in the offer.</t>
+              values. Note that although JSEP requires that answers
+              change the tls-id value if and only if the offerer does,
+              answerer, non-JSEP answerers are permitted to change the


ekr · 2017-10-09T18:06:43Z

draft-ietf-rtcweb-jsep.xml

@@ -3041,6 +3041,12 @@ candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host
            section is bundled into another m= section, it still MUST
            NOT contain any ICE credentials.</t>

+            <t>Each "a=tls-id" line MUST stay the same unless the
+            offeror's "a=tls-id" line changed, in which case a new
+            "a=tls-id" line MUST be added, as described in


ekr added 2 commits August 26, 2017 10:14

Update draft to correct use of tls-id. Fixes rtcweb-wg#818

2433ee2

Fix tls-id examples

841796e

ekr requested review from fluffy and juberti August 26, 2017 17:28

juberti reviewed Aug 26, 2017

View reviewed changes

fluffy reviewed Sep 1, 2017

View reviewed changes

Update to match WG discussion

888ed0f

fluffy approved these changes Oct 6, 2017

View reviewed changes

juberti requested changes Oct 7, 2017

View reviewed changes

Justin's comments

03c6b74

ekr commented Oct 9, 2017

View reviewed changes

juberti added 2 commits October 9, 2017 18:26

Fix typo

6932794

Tweak wording

f1f9fac

juberti approved these changes Oct 10, 2017

View reviewed changes

juberti merged commit e0a7461 into rtcweb-wg:master Oct 10, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue818 tls #830

Issue818 tls #830

ekr commented Aug 26, 2017

juberti Aug 26, 2017

ekr Aug 26, 2017

juberti Aug 26, 2017

juberti Aug 31, 2017

ekr Sep 1, 2017

juberti Aug 26, 2017

ekr Aug 26, 2017

juberti Aug 26, 2017

ekr Aug 31, 2017

juberti Aug 31, 2017

fluffy Sep 1, 2017 •

edited

fluffy commented Aug 28, 2017

fluffy left a comment

ekr commented Sep 1, 2017

ekr commented Sep 29, 2017

ekr commented Sep 29, 2017

juberti Oct 6, 2017

juberti Oct 6, 2017

ekr Oct 9, 2017

juberti Oct 7, 2017

ekr Oct 9, 2017

juberti Oct 7, 2017

ekr left a comment

ekr Oct 9, 2017

ekr Oct 9, 2017

Issue818 tls #830

Issue818 tls #830

Conversation

ekr commented Aug 26, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffy Sep 1, 2017 • edited

Choose a reason for hiding this comment

fluffy commented Aug 28, 2017

fluffy left a comment

Choose a reason for hiding this comment

ekr commented Sep 1, 2017

ekr commented Sep 29, 2017

ekr commented Sep 29, 2017

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ekr left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

fluffy Sep 1, 2017 •

edited