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

From: "Piron Laurent" <[email-masked]>
Date: Tue, 2 May 2006 10:20:53 +0200

Dear all,

Nagravision is an active actor in the broadcast world. We are currently
active in the DVB-CBMS and OMA BCAST groups. While DVB-CBMS is
considering using the draft-lehtovirta-srtp-rcc-01.txt, OMA BCAST did
already make the choice of using it. This solution is also used in 3GPP2
BCMCS and 3GPP MBMS. Thus in order to reach a nice harmonization between
specifications and allow sharing of streams between systems, DVB is
looking at this draft as other bodies did already made this choice.

We consider that the proposition of Nigel is a good addition to the
draft:

- This draft provides a very nice solution to carry the ROC to a client
in a broadcast only system, where there is no return path and where a
client can joint at any time and needs the ROC (among other parameters)
to properly get access.

- Currently authentication is not used in broadcast TV systems. Indeed,
no pay-TV systems mandate the use of authentication. Using
authentication is an operational decision (as encrypting content is an
operational decision in fact). No standard does mandate that content
shall be authenticated.

- RFC3711 does not require the use of authentication, it is recommended.
Thus requiring the authentication to allow carrying the ROC modifies the
way this RFC is used, while there is no direct link between the ROC and
authentication. Thus, the proposed additional mode only makes a clear
distinction between having authentication and carrying the ROC value
in-band.

Please note that we do not say that authentication is of no need, we
just want to see it optional as it is currently in RFC3711 while
allowing to carry ROC in-band which is a very useful feature.

Best regards

  Laurent

------------------------------------------
Laurent Piron
CTO office - New Technologies
Nagravision SA, Case Postale 134
1033 Cheseaux, Switzerland
+41 21 732 05 37

> From: Karl Norrman (KI/EAB) [mailto:[email-masked]]
> Sent: 27 April 2006 13:28
> To: Dallard, Nigel
> Cc: [email-masked]; [email-masked]
> Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use
> 
> 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:NDallard at ndsuk.com] 
> Sent: den 27 april 2006 11:33
> To: Karl Norrman (KI/EAB)
> Cc: avt at ietf.org; msec at securemulticast.org
> Subject: RE: [MSEC] draft-lehtovirta-srtp-rcc-01.txt for broadcast use
> 
> > From: Karl Norrman (KI/EAB) [mailto:karl.norrman at ericsson.com]
> 
> > 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: ndallard at ndsuk.com  ** 
> ** 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 postmaster at nds.com and destroy 
> the original message
> 
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec