Subject: [lemonade] IESG Goals comments

From: "Glenn Parsons" <[email-masked]>
Date: Wed, 19 Jan 2005 12:57:26 -0500

Folks,

Here are some IESG comments on the Goals draft.

We will be discussing this later today at the Lemonade interim. 

Cheers,
Glenn.

Date and Time:	2005-01-17, 18:56:01
Version:	05
Commented by:	Hartman, Sam
State before Comment:	0
State after Comment:	0
Comment:
	1) This document proposes to make transcoding of media and other
  modification of messages significantly more common than is common
  today.  No thought has been given to how this interacts with the
  deployability of S/MIME, PGP and other end-to-end mechanisms.  For
  the most part the security community seems to have held its
  collective nose when examining smtp conneg, hoping that it won't
  get used much.  I think that's the wrong approach to take with
  lemonade.  I believe there's a central architectural issue that
  needs to be decided on a scope greater than one working group.  How
  do we balance the needs of security against the needs of diverse
  messaging environments.  
I see three options.  First, we can decide that it is critical that
security be end-to-end and that systems like S/MIME are incompatible
with lemonade.  Second we can decide that we want to provide
mechanisms so lemonade servers have access to the long-term keys
needed to decrypt messages.  A third option is to look at giving
lemonade servers keys to individual messages as the MUA  wants the
messages manipulated.  
I don't think the lemonade group is the appropriate place to make this
architectural decision, although I believe it has important input to
give.  Possible stakeholders include the IAB, IESG, security area and
lemonade working group.    I don't know how best to address this
issue; I don't have enough experience on the IESG to know how we get
all the right people together in a situation like this.
2) There is a presumption in the document and unfortunately the
    charter that smtp conneg is the right place to do content
    transformation for low-end devices.  This seems to presume that a
    single message store will either be accessed by low-end or more
    normal devices.  Perhaps for servers run by the phone providers
    that's true.  However it seems like if you solve the content
    transformation issues at the IMAP layer rather than the SMTP
    layer, you can support dual use servers used both by low-end and
    less constrained clients.  You only convert if the client cannot
    handle the current format of the message.  If SMTP conneg is going
    to be the desired way of handling this, more explanation is
    needed.  In addition, the document should either explain how
    dual-use servers will work or why they are not being handled.
3) The trust model is unclear.  Sections 6.1.2.5, 6.2.2 both discuss
  trusted clients.  For each operation involving trust, explain who
  the trusting party is, who the trusted party is and why it is
  reasonable to assume that there is a trust relationship between the
  parties.  For the last part, it is probably sufficient to show that
  the parties will be run by the same administrative agent.
4) Section 6.1.2.4 seems at least partially inconsistent with IMAP4.
    In IMAP, flags are typically used to indicate that a message is
    scheduled for deletion.  Why is it appropriate to change these
    semantics and require special mailbox support?
5) Section 7.2 assumes that it is an application layer issue to
  provide support for getting back to the right state in a session in
  case of network failure.  First, IMAP is not the only application
  where this is an issue.  SMTP will have the same problem sending
  large messages.  Second, please explain why the application layer
  is the right place to solve this problem for this usage profile.
  Things that spring to my mind include a shim proxy that allows
  authentication and connection to an existing session.
6) Section 6.1.1.1 discusses a requirement for streaming.  The charter
  says that this requirement will be addressed by using an external
  streaming protocol not by extending IMAP.  No discussion of session
  security between the two protocols is made.  From a security
  requirements standpoint I would expect that facilities to integrate
  external streaming protocol are sufficient such that if I have
  confidentiality for my IMAP session  and  desire confidentiality
  for my streaming session  that these two sessions will be
  cryptographically bound together.  I consider it an absolute
  requirement that  any authentication sufficient to get you
  confidentiality for the IMAP session be sufficient to get you
  confidentiality for the streaming session.  
In the interests of showing that this requirement is possible to meet
I present two approaches.  One is to negotiate the confidentiality
keys for the streaming session as part of IMAP.  This seems similar to
what happens with SIP.  Another is to make sure the streaming protocol
supports the same confidentiality technologies as IMAP (TLS and SASL)
and to require that the same authenticated identities be used for both
sessions.
7) The security considerations section is very weak.  It should
    discuss the security implications of the architectural changes
    implied by this proposal.  There are significant security
    implications of having the message store or MTA re-interpret
    messages.

> Date and Time: 2005-01-06, 08:31:00 
> Version: 05 
> Commented by: Alvestrand, Harald 
> State before Comment: 0 
> State after Comment: 0 
> Comment: Reviewed by Mark Allman, Gen-ART
> 
> His review:
> 
> This one seems ready to go to me.  Nicely written.  We should do more of
> these "why we are doing this" sort of documents. 
> 
> 
> 
_______________________________________________
lemonade mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/lemonade