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 |