Subject: [siprec] Keying of recording session

From: Cullen Jennings <[email-masked]>
Date: Tue, 28 Sep 2010 07:16:59 -0600

Why does the recording session need to use different keys?

---

From: Leon Portman <[email-masked]>
Date: Tue, 28 Sep 2010 15:49:54 +0200

Two main reasons:
1. We don't want escrow original conversation (CS) keys to SRS
2. Current interpretation of PCI compliance (Payment Card Industry) is that you need to have separate keys for separate conversations (for example 128 bit for CS and 256 for RS, because it is a choke point)

Leon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Tuesday, September 28, 2010 3:17 PM
To: [email-masked]
Subject: [siprec] Keying of recording session

Why does the recording session need to use different keys? 
_______________________________________________
siprec mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/siprec

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 30 Sep 2010 11:05:22 +0200

Personally I am not sure I understand the answers Leon gives, but I will wait for Cullen's reaction. Anyway, I have opened ticket #44 on this question. Please continue discussions on that new thread. 

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Leon Portman
> Sent: 28 September 2010 14:50
> To: Cullen Jennings; [email-masked]
> Subject: Re: [siprec] Keying of recording session
> 
> Two main reasons:
> 2. Current interpretation of PCI compliance (Payment Card 
> Industry) is that you need to have separate keys for separate 
> conversations (for example 128 bit for CS and 256 for RS, 
> because it is a choke point)
> 
> Leon
> 
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 30 Sep 2010 07:16:36 -0600

So I think Leon's point is there are cases where you need the keys to be different and I agree with him on that. But there also cases where they are huge advantages to having the keys be the same. I think the solution should support both. I imagine different will likely be the default but the folks that are recording telepresence conference call are simply not going to use different keys - if they solution mandates different keys, they will not use this solution. They have too much traffic to easily decrypt and re-encrypt it all. 

I would suggest updating the requirements to say the solution MUST support different keys, and MAY/SHOULD/or/MUST support shared keys. I don't care about if it is MAY/SHOULD/orMUST because I have no idea what they words mean in requirement document to start with.