Subject: Gen-ART LC review of draft-ietf-lemonade-streaming-09

From: "Spencer Dawkins" <[email-masked]>
Date: Fri, 6 Mar 2009 16:29:10 -0600

I have been selected as the General Area Review Team (Gen-ART)
reviewer for this draft (for background on Gen-ART, please see
http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html).
Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-lemonade-streaming-09
Reviewer: Spencer Dawkins
Review Date: 2009-03-06
IETF LC End Date: 2009-03-12
IESG Telechat date: (not known)

Summary: Almost ready for publication as Informational. A couple of nits 
(forwarded for the editor, not part of Gen-ART reviews), and a couple of 
minor questions.

Comments:

1.  Introduction

   Email clients on resource and/or network constrained devices, such as
   mobile phones, may have difficulties in retrieving and/or storing
   large attachments received in a message.  For example, on a poor
   network link, the latency required to download the entire attachment

Spencer (nit): s/attachment/attachment before displaying any of it/, 
perhaps? The sentence seems to say the user won't download the entire 
attachment under any conditions, but that's probably not what it should 
say...

   may not be acceptable to the user.  Conversely, even on a high-speed
   network, the device may not have enough storage space to secure the
   attachment once retrieved.

3.1.  Overview of Mechanism

   The proposed mechanism has the following steps:

   1.  Client determines from MIME headers of a particular message that
       a particular message part (attachment) should be streamed to the
       user.  Note that no assumptions are made about how/when/if the
       client contacts the user of the client about this decision.  User
       input MAY be required in order to initiate the proposed
       mechanism.

Spencer (minor): this MAY doesn't smell 2119 to me...

3.2.  Media Server Discovery

   There is also a scenario where media server discovery would improve
   the security of the streaming mechanism, by avoiding the use of
   completely anonymous URLs.  For example, the client could discover a
   media server address that was an authorised user of the IMAP server
   for streaming purposes, which would allow the client to generate a
   URL, which was secure in that it could *only* be accessed by an
   entity that is trusted by the IMAP Server to retrieve content.  The
   issue of trust in media servers is discussed more fully in Section 4

Spencer (nit): missing period after "4".

   Example values of the /shared/mediaServers METADATA entry:

   "<sip:[email-masked]:5060>:stream;<sip:annc@
   ms1.example.net:5060>;<sips:[email-masked]:5061>"

   "<sip:[email-masked]:5060>;<sip:192.0.2.41:5060>;<sips:annc@
   192.0.2.42:5060>:stream"

Spencer (minor): Hmm. The paragraph that talked about line wrapping in 
section 2 was specifically about S: and C:, and that doesn't apply here. Is 
this clear enough for the target reader? At a minimum, I see people 
indenting continuation lines in other specs...

3.7.  Client Use of the Media Server MSCML IVR Service

   Since the playcollect request is used purely for its VCR
   capabilities, there is no need for the media server to perform DTMF
   collection, therefore the playcollect attributes "firstdigittimer",
   "interdigittimer" and "extradigittimer" SHOULD all be set to "0ms",
   which will have the effect of causing digit collection to cease
   immediately the media has finished playing.

Spencer (minor): "immediately the" is missing a word... if I could guess 
which word, this would be a nit.

3.8.  Media Server Use of IMAP Server

   If the media server is configured as an authorized user of the IMAP
   server, it SHOULD authenticate to the IMAP server using the
   credentials for that user.  This document does not go into the
   details of IMAP authentication, but the authentication SHOULD NOT use
   the LOGIN command over a non-encrypted communication path.

Spencer (minor, because I'm not your security reviewer): I'm struggling why 
this last statement is SHOULD NOT with no qualifications... if you tell me 
that this is normal practice in the e-mail community, I'll be quiet, but 
this would worry me if I saw it happening.

4.  Security Considerations

   o  However, since the media server will retrieve content from an IMAP
      server on the users behalf, the issue of security between the IMAP

Spencer (nit): s/users/user's/

      server and the media server also needs to be considered.  A client
      has no way of determining (programatically at least) the security
      of the exchanges between the media server and the IMAP server.
      However, it can determine, using the "stream" token that is part
      of the media server discovery mechanism described in Section 3.2,
      that the media server has a pre-existing authentication
      relationship with the IMAP server for the purposes of retrieving
      content using IMAP URLs.  The IMAP server administrator may put
      pre-requisites on media server administrator before this
      relationship can be established, for example to guarantee the
      security of the communication between the media server and the
      IMAP server.

>From IDNits: (Yeah, I know my working group has pre-RFC5378 work, too..)

  Miscellaneous warnings:
  ----------------------------------------------------------------------------

  == The document seems to lack a disclaimer for pre-RFC5378 work, but was
     first submitted before 10 November 2008.  Should you add the 
disclaimer?
     (See the Legal Provisions document at
     http://trustee.ietf.org/license-info for more information.).

     trust-12-feb-2009 Section 6.c.iii text:
     "This document may contain material from IETF Documents or IETF
      Contributions published or made publicly available before November
      10, 2008.  The person(s) controlling the copyright in some of this
      material may not have granted the IETF Trust the right to allow
      modifications of such material outside the IETF Standards Process.
      Without obtaining an adequate license from the person(s)
      controlling the copyright in such materials, this document may not
      be modified outside the IETF Standards Process, and derivative
      works of it may not be created outside the IETF Standards Process,
      except to format it for publication as an RFC or to translate it
      into languages other than English."

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  == Outdated reference: A later version (-01) exists of
     draft-ncook-urlauth-accessid-00

  == Outdated reference: draft-daboo-imap-annotatemore has been published as
     RFC 5464

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 10 Mar 2009 07:12:44 -0500

Hi, Neil,

Thanks for the quick response (so I can still remember writing the review 
:-)...

Deleting stuff we agree on - I think my suggestion here

>> Spencer (minor, because I'm not your security reviewer): I'm  struggling 
>> why this last statement is SHOULD NOT with no  qualifications... if you 
>> tell me that this is normal practice in the  e-mail community, I'll be 
>> quiet, but this would worry me if I saw it  happening.
>
> You're right, I actually took this verbatim from an earlier version of 
> the IMAP URL RFC, but I notice the latest version has removed this  text. 
> There is no particular need for it in this doc either, as the  base IMAP 
> RFCs cover the perils of using non-encrypted communication  channels 
> adequately enough, and as such it's not a security concern of  this doc. 
> So I lean towards removing the sentence completely, or  simply lowercasing 
> the SHOULD NOT.

is removing the sentence.

My biggest concern was whether the media server might be configured with MY 
IMAP credentials, and might decide it was a good idea to send MY IMAP 
credentials "in the clear". If that's possible, I'd hope for MUST NOT, but 
you're probably saying that this spec is not the right place to fight the 
battle of clear-text security credentials, even for IMAP, and I can see that 
being the case.

Thanks,

Spencer

---

From: Dave Cridland <[email-masked]>
Date: Tue, 10 Mar 2009 12:21:59 +0000

On Tue Mar 10 12:12:44 2009, Spencer Dawkins wrote:
> My biggest concern was whether the media server might be configured  
> with MY IMAP credentials,

Ah, no, it's referring to the media server's credentials, not yours.

It (probably) doesn't know yours, or at least only knows them  
sufficient for you to authenticate to it.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 10 Mar 2009 07:26:35 -0500

Hi, Dave,

Ah - then this really does reduce to a general IMAP-wide "don't send 
credentials over unencrypted channels" warning, that more appropriately 
belongs somewhere else.

Thanks!

Spencer

>> My biggest concern was whether the media server might be configured  with 
>> MY IMAP credentials,
>
> It (probably) doesn't know yours, or at least only knows them  sufficient 
> for you to authenticate to it.
>
> Dave.
> --

---

From: Neil Cook <[email-masked]>
Date: Mon, 9 Mar 2009 23:11:34 +0000

Spencer,

thanks for these comments, I broadly agree with most of them. I've  
replied specifically inline below, and if you agree will update the  
draft accordingly.

Neil

On 6 Mar 2009, at 22:29, Spencer Dawkins wrote:

> Summary: Almost ready for publication as Informational. A couple of  
> nits (forwarded for the editor, not part of Gen-ART reviews), and a  
> couple of minor questions.
>
> Comments:
>
> 1.  Introduction
>
> perhaps? The sentence seems to say the user won't download the  
> entire attachment under any conditions, but that's probably not what  
> it should say...
>
I'm okay with changing this.

> Spencer (minor): this MAY doesn't smell 2119 to me..

You're right, that should simply be a lowercase may.

> Spencer (nit): missing period after "4".

Nod.

> Spencer (minor): Hmm. The paragraph that talked about line wrapping  
> in section 2 was specifically about S: and C:, and that doesn't  
> apply here. Is this clear enough for the target reader? At a  
> minimum, I see people indenting continuation lines in other specs...

Well to be fair - this is showing the value of an entry stored on the  
IMAP server, not showing a protocol exchange. However I can add some  
text saying that the lines below are wrapped for clarity, and add an  
extra space at the start of the line.

> Spencer (minor): "immediately the" is missing a word... if I could  
> guess which word, this would be a nit.

"after" is the word we're looking for here I think :)

> Spencer (minor, because I'm not your security reviewer): I'm  
> struggling why this last statement is SHOULD NOT with no  
> qualifications... if you tell me that this is normal practice in the  
> e-mail community, I'll be quiet, but this would worry me if I saw it  
> happening.

You're right, I actually took this verbatim from an earlier version of  
the IMAP URL RFC, but I notice the latest version has removed this  
text. There is no particular need for it in this doc either, as the  
base IMAP RFCs cover the perils of using non-encrypted communication  
channels adequately enough, and as such it's not a security concern of  
this doc. So I lean towards removing the sentence completely, or  
simply lowercasing the SHOULD NOT.

> Spencer (nit): s/users/user's/

Nod.

> From IDNits: (Yeah, I know my working group has pre-RFC5378 work,  

Will fix the nits below.

---

From: Neil Cook <[email-masked]>
Date: Tue, 10 Mar 2009 12:27:38 +0000

Spencer,

agreed.

I'll update the draft based on your comments, and update the repository,

thanks,

Neil

On 10 Mar 2009, at 12:12, Spencer Dawkins wrote:

> Hi, Neil,
>
> Thanks for the quick response (so I can still remember writing the  
> review :-)...
>
>>> qualifications... if you tell me that this is normal practice in  
>>> the  e-mail community, I'll be quiet, but this would worry me if I  
>>> saw it  happening.
>>
>> You're right, I actually took this verbatim from an earlier version  
>> of the IMAP URL RFC, but I notice the latest version has removed  
>> this  text. There is no particular need for it in this doc either,  
>> as the  base IMAP RFCs cover the perils of using non-encrypted  
>> communication  channels adequately enough, and as such it's not a  
>> security concern of  this doc. So I lean towards removing the  
>> sentence completely, or  simply lowercasing the SHOULD NOT.
>
> with MY IMAP credentials, and might decide it was a good idea to  
> send MY IMAP credentials "in the clear". If that's possible, I'd  
> hope for MUST NOT, but you're probably saying that this spec is not  
> the right place to fight the battle of clear-text security  
> credentials, even for IMAP, and I can see that being the case.
>
> Thanks,
>
> Spencer