Subject: [AVT] SRTP Store-and-Forward thoughts

From: Richard Barnes <[email-masked]>
Date: Mon, 27 Jul 2009 18:01:59 +0200

I hesitated to comment on the SRTP store-and-forward drafts in the 
meeting today because I hadn't read the list traffic in a while.  But 
having taken a look at the list since the meeting, I would like to make 
a few comments.

My initial observation is that none of the comments on the mailing list 
are supportive of this document -- they all find that the proposed use 
cases fail to motivate the proposed mechanism.  (Except, of course, for 
the authors' comments.)  Given that, and the fact that these drafts have 
been presented a few times, it's tempting to invoke the "few-strikes-and 
you're-out" rule, e.g., as embodied in the DISPATCH charter:
"
Reconsideration of proposals which have failed to gather consensus
will be prioritized behind proposals for new work which have not
yet been considered. In general, requests for reconsideration
should only be made once a proposal has been significantly
revised.
"
The store-and-forward proposals have *not* been significantly revised, 
so it would seem that they don't really merit further consideration by 
the WG.

Looking at the merits of the drafts, there are still significant issues. 
  Ignoring for the moment whether the use cases are relevant, the 
proposed solution isn't a very efficient one given the stated 
requirements.  Consider for instance key management:  The 
store-and-forward mechanism requires the e2e endpoints to establish 
their keys with a half-round-trip protocol.  This effectively requires 
that the endpoints have either a shared key or each others' public keys. 
  Either way, they have enough key to do S/MIME, which is a much simpler 
way to securely transport information through untrusted intermediaries. 
  On the other hand, as Ekr pointed out back in April, just assuming 
that the endpoints have that much key material (as they would in a 
secure email system) is a really big assumption.

Perhaps the authors should try to see what it would take to implement 
the use cases with existing technologies.  If it's difficult or 
impossible to do so, then it will help the authors make a better case 
for the complexity of their solution, and if not, then maybe they could 
produce a BCP documenting their findings.  Either way, without that 
analysis, the currently-proposed store-and-forward mechanism doesn't 
seem worth the requirements it imposes.

--Richard

---

From: "Hannes Tschofenig" <[email-masked]>
Date: Mon, 27 Jul 2009 19:11:23 +0300

I agree with Richard. 

I was puzzled about the work being proposed as well. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of Richard Barnes
>Sent: 27 July, 2009 19:02
>To: AVT WG
>Subject: [AVT] SRTP Store-and-Forward thoughts
>
>I hesitated to comment on the SRTP store-and-forward drafts in 
>the meeting today because I hadn't read the list traffic in a 
>while.  But having taken a look at the list since the meeting, 
>I would like to make a few comments.
>
>My initial observation is that none of the comments on the 
>mailing list are supportive of this document -- they all find 
>that the proposed use cases fail to motivate the proposed 
>mechanism.  (Except, of course, for the authors' comments.)  
>Given that, and the fact that these drafts have been presented 
>a few times, it's tempting to invoke the "few-strikes-and 
>Reconsideration of proposals which have failed to gather 
>consensus will be prioritized behind proposals for new work 
>which have not yet been considered. In general, requests for 
>reconsideration should only be made once a proposal has been 
>significantly revised.
>"
>The store-and-forward proposals have *not* been significantly 
>revised, so it would seem that they don't really merit further 
>consideration by the WG.
>
>
>  Ignoring for the moment whether the use cases are relevant, 
>the proposed solution isn't a very efficient one given the 
>stated requirements.  Consider for instance key management:  
>The store-and-forward mechanism requires the e2e endpoints to 
>establish their keys with a half-round-trip protocol.  This 
>effectively requires that the endpoints have either a shared 
>key or each others' public keys. 
>  Either way, they have enough key to do S/MIME, which is a 
>much simpler way to securely transport information through 
>untrusted intermediaries. 
>  On the other hand, as Ekr pointed out back in April, just 
>assuming that the endpoints have that much key material (as 
>they would in a secure email system) is a really big assumption.
>
>Perhaps the authors should try to see what it would take to 
>implement the use cases with existing technologies.  If it's 
>difficult or impossible to do so, then it will help the 
>authors make a better case for the complexity of their 
>solution, and if not, then maybe they could produce a BCP 
>documenting their findings.  Either way, without that 
>analysis, the currently-proposed store-and-forward mechanism 
>doesn't seem worth the requirements it imposes.
>
>--Richard
>
>
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www.ietf.org/mailman/listinfo/avt
>