Skip to main content

Goals for Internet Messaging to Support Diverse Service Environments
draft-ietf-lemonade-goals-05

Revision differences

Document history

Date Rev. By Action
2012-08-22
05 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2005-02-10
05 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2005-02-09
05 Amy Vezza IESG state changed to Approved-announcement sent
2005-02-09
05 Amy Vezza IESG has approved the document
2005-02-09
05 Amy Vezza Closed "Approve" ballot
2005-02-09
05 Ted Hardie State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Ted Hardie
2005-02-09
05 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2005-02-01
05 Sam Hartman
[Ballot discuss]
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 …
[Ballot discuss]
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.
2005-01-20
05 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2005-01-19
05 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2005-01-17
05 Sam Hartman
[Ballot discuss]
1) This document proposes to make transcoding of media and other
  modification of messages significantly more common than is common
  today.  …
[Ballot discuss]
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.
2005-01-17
05 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded for Sam Hartman by Sam Hartman
2005-01-07
05 (System) Removed from agenda for telechat - 2005-01-06
2005-01-06
05 Sam Hartman State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman
2005-01-06
05 Bert Wijnen [Ballot Position Update] New position, No Objection, has been recorded for Bert Wijnen by Bert Wijnen
2005-01-06
05 Harald Alvestrand
[Ballot 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 …
[Ballot 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.
2005-01-06
05 Harald Alvestrand [Ballot Position Update] New position, No Objection, has been recorded for Harald Alvestrand by Harald Alvestrand
2005-01-06
05 Margaret Cullen [Ballot Position Update] New position, No Objection, has been recorded for Margaret Wasserman by Margaret Wasserman
2005-01-06
05 Bill Fenner [Ballot Position Update] New position, No Objection, has been recorded for Bill Fenner by Bill Fenner
2005-01-06
05 Allison Mankin [Ballot Position Update] New position, No Objection, has been recorded for Allison Mankin by Allison Mankin
2005-01-05
05 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2005-01-05
05 Michelle Cotton IANA Comments:  We understand this document to have NO IANA Actions.
2005-01-04
05 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded for Russ Housley by Russ Housley
2005-01-03
05 Scott Hollenbeck [Ballot Position Update] New position, No Objection, has been recorded for Scott Hollenbeck by Scott Hollenbeck
2004-12-30
05 Ted Hardie Placed on agenda for telechat - 2005-01-06 by Ted Hardie
2004-12-30
05 Ted Hardie State Changes to IESG Evaluation from Publication Requested by Ted Hardie
2004-12-30
05 Ted Hardie [Ballot Position Update] New position, Yes, has been recorded for Ted Hardie
2004-12-30
05 Ted Hardie Ballot has been issued by Ted Hardie
2004-12-30
05 Ted Hardie Created "Approve" ballot
2004-12-30
05 (System) Ballot writeup text was added
2004-12-30
05 (System) Last call text was added
2004-12-30
05 (System) Ballot approval text was added
2004-12-23
05 Ted Hardie Draft Added by Ted Hardie in state Publication Requested
2004-12-19
05 (System) New version available: draft-ietf-lemonade-goals-05.txt
2004-10-11
04 (System) New version available: draft-ietf-lemonade-goals-04.txt
2004-07-20
03 (System) New version available: draft-ietf-lemonade-goals-03.txt
2004-02-18
02 (System) New version available: draft-ietf-lemonade-goals-02.txt
2003-10-27
01 (System) New version available: draft-ietf-lemonade-goals-01.txt
2003-06-24
00 (System) New version available: draft-ietf-lemonade-goals-00.txt