Subject: Re: [AVT] Store and Forward - looking for more feedback (draft-mattsson-srtp-store-and-forward-03)

From: "Dan Wing" <[email-masked]>
Date: Tue, 17 Nov 2009 16:15:38 -0800

> -----Original Message-----
> From: Rolf Blom [mailto:[email-masked]] 
> Sent: Tuesday, September 15, 2009 4:48 AM
> To: Roni Even
> Cc: 'Dan Wing'; 'IETF AVT WG'
> Subject: Re: [AVT] Store and Forward - looking for more 
> feedback (draft-mattsson-srtp-store-and-forward-03)
> 
> Hi Dan, Roni
> 
> Thanks for the comments, Please see some answers below.
> 
> /Rolf
> 
> Roni Even wrote: 
> 
> 	Hi Dan,
> 	Thanks for the feedback.
> 	On the first point, this can be discussed if we decide 
> that AVT would like
> 	to take this work as part of the charter update. 
> 	
> 	Regards
> 	Roni Even
> 	AVT co-chair
> 	
> 	
> 	  
> 
> 		-----Original Message-----
> 		From: Dan Wing [mailto:[email-masked]]
> 		Sent: Wednesday, September 09, 2009 4:12 AM
> 		To: 'Roni Even'; 'IETF AVT WG'
> 		Subject: RE: [AVT] Store and Forward - looking 
> for more feedback
> 		(draft-mattsson-srtp-store-and-forward-03)
> 		
> 		My top-level concerns with 
> draft-mattsson-srtp-store-and-forward-03 /
> 		draft-naslund-srtp-saf-02
> 		
> 		* from an RAI perspective, the mechanism only 
> works for SRTP.
> 		(This is probably fine from AVT's perspective.)
> 		That is, it does not provide privacy of other 
> messages that
> 		an operator might store and forward, such as 
> SIP MESSAGEs.
> 		A mechanism using S/MIME could provide decryption keys
> 		and replay protection that would be decipherable only by
> 		the intended recipient, for any sort SIP method and for
> 		SRTP-encrypted media.
> 		
> 		I expect this is an AD-level issue to consider.
> 		    
> 
> It is correct that the SRTP SaF only works for RTP, as the 
> intention was to have a profile that can work with streaming 
> media. There may very well be a need to have mechanisms that 
> work for non-streaming media, but we believe that is out of 
> scope for this work.
> 
> 		
> 		* The draft needs to describe how key management is
> 		performed.  Specifically, the calling party needs a
> 		mechanism to obtain the called party's public key; I
> 		don't know how to build a device that does that --
> 		what protocol do I use?  Security Descriptions wouldn't
> 		be suitable.  DTLS-SRTP wouldn't be suitable, either (as
> 		the actual called party is offline [or refusing 
> to answer],
> 		otherwise you wouldn't be leaving them voicemail!).  I
> 		think this means I need MIKEY-RSA-R, but I 
> don't know how
> 		that would work when the called party is 
> offline.  So that
> 		leaves me guessing there is some other protocol that I
> 		need to implement, or that I load the public keys into
> 		my contact list (which means we don't need an on-the-
> 		wire protocol to obtain the called party's public key).
> 		    
> 
> We have followed the same model as for SRTP, to keep the key 
> management separated. However, we could very well add some 
> key management considerations into the draft and clarify the 
> requirements on the key management protocol. An example of a  
> key management protocol that would work is MIKEY (using one 
> of the key push mechanisms). 

Can you add that to the draft?  My purpose is simple:  I want
text in the draft so that when a customer says "wow, that store-
and-forward SRTP looks great.  Which products have it?" we
can quickly say "only our XYZ product supports the type of keying
required by Section X.Y of the store-and-forward RFC."  Otherwise
it's a half-hour-long discussion of (unstated) keying requirements
to accomplish store-and-forward SRTP.

-d

> 
> 		
> 		-d
> 		
> 		
> 		    
> 
> 			-----Original Message-----
> 			From: [email-masked] 
> [mailto:[email-masked]] On
> 			Behalf Of Roni Even
> 			Sent: Monday, August 10, 2009 2:57 AM
> 			To: 'IETF AVT WG'
> 			Subject: [AVT] Store and Forward - 
> looking for more feedback
> 			
> 			Hi,
> 			
> 			Store and forward was first presented 
> in IETF 72 (Dublin)
> 			since then there was progress in the 
> individual drafts but
> 			the AVT chairs are not sure how to 
> continue with the work.
> 			
> 			We had a presentation on the current 
> status in IETF 75 but
> 			there were not many comments. The 
> people that commented on
> 			the mailing list were not in the room.
> 			
> 			
> 			
> 			The AVT chairs would like to get 
> feedback on this work so
> 			that they can form an opinion about how 
> to go forward with this work.
> 			
> 			Since it has been active for a year it 
> looks like we will
> 			need to decide if there is enough 
> support for having this
> 			work as a WG item or look at other directions
> 			
> 			
> 			
> 			Thanks
> 			
> 			Roni Even
> 			
> 			AVT co-chair
> 			
> 			
> 			      
> 
> 	
> 	_______________________________________________
> 	Audio/Video Transport Working Group
> 	[email-masked]
> 	https://www.ietf.org/mailman/listinfo/avt
> 	
> 	  
> 
> 
> -- 
> Rolf Blom, Ph.D. Expert, Mobile Communications Security, 
> Ericsson Research
> Postal address: Ericsson AB, SE-164 80 STOCKHOLM, Sweden
> Tel: +46 10 713 17 07,  GSM: +46 70 757 2092,  Fax: +46 8 757 01 35
> 
> 
> This communication is confidential and intended solely for the
> addressee(s). Any unauthorized review, use, disclosure or distribution
> is prohibited. If you believe this message has been sent to you 
> in error, please notify the sender by replying to this transmission 
> and delete the message without disclosing it. Thank you.
> 
> E-mail including attachments is susceptible to datacorruption, 
> interruption, unauthorized amendment, tampering and viruses, and 
> we only send and receive e-mails on the basis that we are not 
> liable for any such corruption, interception, amendment, tampering
> or viruses or any consequences thereof.
>