Subject: [rtcweb] Combining consent freshness and liveness

From: "Muthu Arul Mozhi Perumal (mperumal)" <[email-masked]>
Date: Wed, 13 Jun 2012 18:34:56 +0000

Taking a closer look at the "Combined Consent/Liveness Proposal II" (slide 16) from Eric's RTCWeb security presentation today, it seems to align closely with what said in WebEx -- determining consent freshness must be under the browser control and determining session liveness must be under the application control. If I understood correctly, the proposal is to have the consent timer Tc under the browser control and the packet receipt timer Tr under the application control. So, I full support it.

I can work with Eric to incorporate it into draft-muthu-behave-consent-freshness. However, I would like us to reach a (rough) consensus on whether the STUN transactions for consent freshness / liveness should include or omit the message integrity and thereby use the STUN Binding requests/responses or a new method.

Muthu

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 14 Jun 2012 08:29:41 +0200

On 06/13/2012 08:34 PM, Muthu Arul Mozhi Perumal (mperumal) wrote:
>
> Taking a closer look at the "Combined Consent/Liveness Proposal II" 
> (slide 16) from Eric's RTCWeb security presentation today, it seems to 
> align closely with what said in WebEx -- determining consent freshness 
> must be under the browser control and determining session liveness 
> must be under the application control. If I understood correctly, the 
> proposal is to have the consent timer Tc under the browser control and 
> the packet receipt timer Tr under the application control. So, I full 
> support it.
>
To the extent that I understand it (and my understanding is the same as 
yours), I agree.
>
> I can work with Eric to incorporate it into 
> draft-muthu-behave-consent-freshness. However, I would like us to 
> reach a (rough) consensus on whether the STUN transactions for consent 
> freshness / liveness should include or omit the message integrity and 
> thereby use the STUN Binding requests/responses or a new method.
>
As I've said before, I don't see a value in omitting the message 
integrity that offsets the (high) cost of introducing a new method. I 
think we should use the binding request/response.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 14 Jun 2012 09:08:18 -0700

On 13 June 2012 23:29, Harald Alvestrand <[email-masked]> wrote:
> As I've said before, I don't see a value in omitting the message integrity
> that offsets the (high) cost of introducing a new method. I think we should
> use the binding request/response.

While it was acknowledged that the security analysis didn't depend on
having the integrity check, I completely agree with Harald.  ...for at
least these reasons:
 * As discussed, the additional cost of introducing a method, which I
cannot emphasize enough is quite high.
 * Reusing the binding request allows browsers to interoperate with
existing ICE agents; even ICE-lite agents.  That's really important.

I'm sympathetic to the cost of calculating SHA-1, but is not so
expensive (either in terms of packets or in terms of CPU cycles) that
it warrants breaking these.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 14 Jun 2012 11:58:41 -0700

Agree that introducing a new method is not a good idea.  ICE has been implemented
and deployed, and so we should not be breaking interoperability without a very good
reason.  

The cost of SHA-1 computation is not a good enough justification for the pain a 
new method would cause. 

> Date: Thu, 14 Jun 2012 09:08:18 -0700
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]
> Subject: Re: [rtcweb] Combining consent freshness and liveness
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Tue, 19 Jun 2012 21:20:45 +0000

> The cost of SHA-1 computation is not a good enough justification for the pain a 

+1