Subject: [AVT] RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use

From: "Karl Norrman \(KI/EAB\)" <[email-masked]>
Date: Thu, 27 Apr 2006 14:28:23 +0200

Hello!

You have a point in that there are specialized environments where a 
NULL-MAC potentially could be acceptable after a proper threat/risk 
analysis.

Do other people on this list consider this a valuable addition to
the draft? 

Regards,
Karl

> -----Original Message-----
> From: Dallard, Nigel [mailto:[email-masked]] 
> Sent: den 27 april 2006 11:33
> To: Karl Norrman (KI/EAB)
> Cc: [email-masked]; [email-masked]
> Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use
> 
> > From: Karl Norrman (KI/EAB) [mailto:[email-masked]]
> 
> > The ROC needs to be integrity protected to ensure that it is not 
> > maliciously modified or subject to transmission bit errors 
> en route.  
> > If the receiver starts using a ROC that has been modified during 
> > transmission, the receiver will be out of synch.
> > Since in "normal" SRTP operation, the ROC is never transmitted 
> > in-band, an unprotected transmission of ROC would therefore _add_ a 
> > vulnerability that is -_not_ present in RFC3711.
> 
> Hi there Karl,
> 
> I accept what you are saying, however, in the particular 
> application I am concerned about...
> 
> 1. Forward error protection is dealt with at a lower level in 
> the protocol stack. It should be a very rare occurrence that 
> an erroneous ROC value reaches the descramber in the ROC. The 
> worst-case scenario would be that the receiver would be out 
> of sync for R packets. The broadcaster has the ability to 
> trade the impact of such loss of sync against bit-rate by 
> varying the value of R.
> 
> 2. Malicious modification is not necessarily a concern in a 
> broadcast environment. Your TV does not, today, authenticate 
> the source of the TV signal.
> 
> I believe that if the system/network operator, having 
> performed a risk assessment (along the lines of that 
> described in Section 9 of RFC3711, for example), would prefer 
> to trade bit-rate against the possibility of loss of ROC sync 
> or the ability of receivers to authenticate the source of his 
> signals, he should be able to do so.
> 
> > You are correct when you say that it is necessary to 
> include the MAC 
> > on each R:th packet.  If one is worried about the bandwidth 
> > consumption of a MAC of 80 bits per R:th packet, one could put the 
> > length of the MAC (n_tag parameter in SRTP) to something less, e.g.,
> > 32 bits.
> 
> Yes, I understand this. I'd like to effectively set n_tag to 0  :-)
> 
> Cheers,
> 
> Nigel
> 
> 
> 
> ** Nigel Dallard                 e-mail: [email-masked]  ** 
> ** Senior Member                    www: http://www.nds.com  ** 
> **   of Technical Staff             tel: +44 23 8030 7151    ** 
> ** NDS Ltd, Southampton, UK.     mobile: +44 7881 913151     ** 
> 
> This email message and any attachments thereto are intended 
> only for use by the addressee(s) named above, and may contain 
> legally privileged and/or confidential information. If the 
> reader of this message is not the intended recipient, or the 
> employee or agent responsible to deliver it to the intended 
> recipient, you are hereby notified that any dissemination, 
> distribution or copying of this communication is strictly 
> prohibited. If you have received this communication in error, 
> please immediately notify the [email-masked] and destroy 
> the original message
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Randell Jesup <[email-masked]>
Date: Thu, 27 Apr 2006 16:30:45 -0400

>Do other people on this list consider this a valuable addition to

NULL-MAC definitely has uses, especially in low-bitrate channels.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]