Subject: IESG discussion of draft-ietf-opes-smtp-use-cases-03

From: "Martin Stecher" <[email-masked]>
Date: Tue, 20 Sep 2005 11:00:40 +0200

Hi,

IESG is discussing the SMTP use cases draft.
There have been some comments and the current status is "IESG Evaluation
- Defer".
See
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=
12800&rfc_flag=0

Find below by personal notes and thoughts regarding these comments.
Some are pretty easy to address, some may need some discussion.

Regards
Martin

> Date and Time: 2005-09-09, 18:04:22 
> Version: 03 
> Commented by: Russ Housley 
> Comment: 
>   Section 4.5, Secure Email handling, raises security considerations
>   that are not discussed in the security considerations section.  The
>   security considerations section essentially says that RFC 3837
covers
>   all of the things that need to be said.  However, RFC 3837 does not
>   discuss the placement of cryptographic keys in the OPES server that
>   would be needed to implement the services described in section 4.5.
> 
>   RFC 3837 says:
>   >
>   > Generally, OPES services cannot be applied to data protected with
>   > end-to-end encryption methods because the decryption key cannot be
>   > shared with OPES processors without compromising the intended
>   > confidentiality of the data.  This means that if the endpoint
>   > policies permit OPES services, the data must either be transmitted
>   > without confidentiality protections or an alternative model to
end-
>   > to-end encryption must be developed, one in which the
confidentiality
>   > is guaranteed hop-by-hop.  Extending the end-to-end encryption
model
>   > is out of scope of this work.
> 
>   Please discuss end-to-end encryption in the security considerations.
> 
>   Please discuss the addition of digital signatures by the OPES server
>   in the security considerations. 

On one hand we handle this only as a collection of use cases and want to
follow Spencer's advice to write:
 > this document contains only use cases and defines no protocol 
 > operations. Security considerations for protocols that appear in
these 
 > use cases are documented in the corresponding protocol specifications
On the other hand, Russ is also right that this use case (4.5) is
somehow
special. When creating the protocol specification guide we may not
revisit
this exact use case and the security considerations raised by it.
So, we could change the security considerations section in something
like:
  Application-independent security considerations are documented in
  application-agnostic OPES specifications [5]. This document contains
only
  use cases and defines no protocol operations. Security considerations
for
  protocols that appear in these use cases are documented in the
corresponding
  protocol specifications.
  Use case 4.5 "Secure Email handling" is special in this regard because
it
  requires the extension of the end-to-end encryption model which is out
of
  scope of OPES protocol specifications. Implementation of such a
service
  raises security issues (such as availability and storage of
cryptographic
  keys) that must be addressed regardless of whether the implementation
happens
  within an MTA or within an OPES callout server.
 
------------------------------------------------------------------------
-------

> Date and Time: 2005-09-14, 06:50:59 
> Version: 03 
> Commented by: Brian Carpenter 
> State before Comment: 0 
> State after Comment: 0 
> Comment: Nits from Gen-ART review by Spencer Dawkins:
> 
> I found a few nits, probably AUTH-48, but just to write them down now:
> 
> - In the last paragraph of the Introduction, there were just a few too

>   many pronouns for me to easily parse
> 
>   This work focuses on SMTP based services that want to modify command
>   values and those that want to block commands by defining an error
>   response that the MTA should send in response to the response it
>   received.

And indeed contains an error (one of the "response"s should be a
"command".
Can revise to:
    This work focuses on SMTP based services that want to modify command
    values or want to block SMTP commands. In order to block a command
    the service will provide an error message that the MTA should use in
    response to the command it received.

> 
> I wasn't sure what "those" and "it" were actually pointing to (I could
guess, but I'd be guessing).
> 
> - OCP isn't expanded on first use.

Will add.

> 
> - The text under Figure 3 refers to "the MTA (the OPES processor)",
but there are three MTAs
>   in Figure 3, all with OCP callout servers. Should this have been
plural,
>   or was the reference to one of the three MTAs (and, if so, which
one)?

While an email could pass serveral MTAs that operate as an OPES
processor, the OPES standard case
is handled that only has a single OPES processor and a single callout
server in the message flow.
Figure 3, though, wants to show the different deployment options in a
typical chain of mail
servers and gateways with different roles as MTA, MSA, MDA.
Seems that we need to make this clear in the text.

> 
> - In Section 4.1, one of the actions is "The attachment is removed by
an error message" -
>   should this be "replaced by an error message"? "removed, and an
error message generated"?
>   Or did I misunderstand?

Yes, it should be "replaced". Will replace removed with replaced ;-)

> 
> - In Section 5, I think what you're saying is "this document does not
describe any new
>   protocol functionality, it only shows use cases for OPES with SMTP,
so does not introduce
>   any new security considerations beyond current considerations for
SMTP and OPES" - sorry,
>   but we see enough "no new security considerations" that we get
suspicious quickly! 

See proposal above for a revised security considerations section.

------------------------------------------------------------------------
-------

> Date and Time: 2005-09-15, 01:14:47 
> Version: 03 
> Commented by: Bill Fenner 
> State before Comment: 0 
> State after Comment: 0 
> Comment: I'm not sure I can reconcile the first sentence of the last
paragraph
> of section 3 with the first sentence of section 3.1:
> 
>   In this work the OPES processor may be any agent that is
>   participating in SMTP exchanges, including an MSA, MTA, MDA, and
MUA.
> [...]
>   In this work an MTA is the OPES processor device that sits in the
>   data stream of the SMTP protocol.
> 

But the last sentence of section 3 says:
  "However, this document focuses on use cases in which the OPES
   processor is a mail transfer agent (MTA)."
That's why from section 3 on the draft only mentiones the MTA.
How to do it better?

> The first mail server in Figure 3 is both an MSA and an MTA; if the
OCP callout
> happens during the MSA's reception of the message from the MUA then
that seems
> to contradict the second of the above sentences.

See above. OPES processor can be any of the enumeration of the first
sentence
but the draft concentrates on MTAs to make things easier.

> 
> 
> Is there a reason for the ordering of OCP first or last in "OCP/SMTP"
vs. "HTTP/OCP"?
> [4] never seems to refer to itself as HTTP/OCP.

The ordering should be consistent, you are right.
Issue is that sometimes this is seen as a sub path notation as in the
profile
names we use in ocp (http://iana.org/opes/ocp/HTTP/request) and
sometimes as
in TCP/IP (TCP on top of IP) and so HTTP encapsulated in OCP.
I think we should consistently use OCP/SMTP and OCP/HTTP as an
abbreviation
for how also the iana profiles are defined.

> 
> 
> Do any of these use cases enable 'graylisting'?  4.8 seems close
except it seems to
> only mention permanent rejection. 
>

I think it is up to the callout server to implement either black- or
greylisting.
As it will provide an error message that the MTA should use as response
to the
RCPT command, that error could either be a permanent or a temporary
error.
Where does 4.8 limit on permanent rejection only? Because it writes "all
messages"?
But it depends on a policy as 4.8 describes and that could certainly
change
over time.

------------------------------------------------------------------------
-------

> Date and Time: 2005-09-15, 08:36:26 
> Version: 03 
> Commented by: Bert Wijnen 
> State before Comment: 0 
> State after Comment: 0 
> Comment: 
> In the example in sect 3.1.1 it uses IP addresses:
> 
>       C: HELO [192.168.0.138]
>       S: 250 mail.example.com Hello [192.168.0.138]
> 
> that do not conform to RFC3330 which sets aside a range
> of IP addresses (192.0.2.0/24) for use in examples. 

Will change to 
      C: HELO [192.0.2.138]
      S: 250 mail.example.com Hello [192.0.2.138]

------------------------------------------------------------------------
-------

> Date and Time: 2005-09-15, 10:14:16 
> Version: 03 
> Commented by: Sam Hartman 
> State before Comment: 0 
> State after Comment: 0 
> Comment: 
> I'm concerned that the architecture envisioned by this document does
> not support some of the IAB recommendations in RFC 3238.  I believe
> these recommendations are desirable and so I'm holding a discuss.
> 
> I have two concerns.  First, the document proposes that OPES focus on
> MTA behavior rather than MSA or MDA behavior.  This seems inconsistent
> with recommendation 2.1:
> 
>   (2.1) One-party consent: An OPES framework standardized in the IETF
>       must require that the use of any OPES service be explicitly
>         authorized by one of the application-layer end-hosts (that is,
either
>             the content provider or the client).

While OPES/SMTP focuses on MTAs, section 3 of RFC 3914 remains a
fundamental
OPES statement. Also defined in RFC 3835 which is the first normative
reference of this use cases draft. This is not explicitly repeated again
in
this use cases draft. In a deployment this would usually mean that the
MTA
is operated within the authorative domain that also the data consumer or
data provider belong to. Figure 3 also shows that a typical OPES
processor
is often a box that runs "MTA and MSA" or "MTA and MDA" and the text
also
reminds that "Which building block belongs to which authoritative domain
is an important question".

> I realize this recommendation is targeted at the web, but the email
> form of this recommendation would probably be something like an OPES
> SMTP binding standardized in the IETF MUST require that the OPES
> service is explicitly authorized by either the message sender or
> recipient.  It may be possible to do this while focusing on MTAs, but
> significant thought (not evident in this document) needs to be given
> to this issue.

As long as the MTA is within the provider administrative domain or the
consumer administrative domain, a service does not need to be explicitly
authorized by the message sender or recipient.
The delegation of authority as explained in section 3.1 of RFC 3835 is
application agnostic and valid not only for web but also email.

> 
> My second concern is that the document anticipates only a profile of
> OCP for SMTP, not a profile of SMTP for OPES.  The distinction is
> important.  The first case does not focus on describing or
> standardizing behavior changes to the SMTP server, only standardizing
> the interactions of the SMTP server with the OCP server.  I understand
> this approach was taken for HTTP; I think it is a mistake there and an
> even more critical mistake for SMTP.  Here are some issues where the
> SMTP server behavior needs to be considered.  First, the client needs
> to communicate its explicit authorization.  I can believe that servers
> may be preconfigured, but it seems that given the wide variety of MUAs
> out there, if explicit authorization is given, that mechanism needs to
> be standardized.

The HTTP draft (draft-ietf-opes-http) is a HTTP for OPES draft
(title: HTTP adaptation with OPES) and not a pure OCP/HTTP draft.
The OCP profile is handled in section 3 of that document and sections 
4 and 5 handle Tracing and Bypassing - other aspects of HTTP for OPES.
The same kind of approach has been planned for SMTP.

> 
> Second, I don't see how IAB recommendation 2.2 (the client must invoke
> OPES by IP address for client services) can be addressed without
> specifying changes to the SMTP server.

I cannot find this exact wording ("must invoke") in the considerations.
Recommendation 2.2 is handled in section 4 of RFC3914 in an application
agnostic way. IP addressing of OPES processors in SMTP are even simpler
than in HTTP as each OPES processor must put a Received header lines
into
the email that contain IP addresses and can be better used to address
an OPES processor than the Via HTTP header.

> 
> 
> Similarly, providing senders the required tracing information will
> require changes to the SMTP server beyond the OCP interactions.

Adding trace headers to an email message is a very simple requirement
for an OPES/SMTP processor. It can be done analogous to what has been
defined in the OPES/HTTP draft (draft-ietf-opes-http).

> 
> One possible response to this discuss is that these issues are out of
> scope for this document.  That's fine provided you tell me what
> document I can expect to review these issues in.  I believe that the
> review needs to be early enough that not too much is fixed and that if
> major questions come up they can be addressed.  As such, I recommend
> the answer not be the OCP SMTP document. 
> 
There will not be a OCP/SMTP but a OPES/SMTP document.
And yes, some of the issues will be done in OPES/SMTP as far as they are
analogous to what is defined in draft-ietf-opes-http.
Other issues have already been handled in application agnostic OPES
documents
(RFC 3914 and RFC 3835). 
This is out of scope for the use cases draft and we do not need yet
another
document but OPES/SMTP in my opinion.

---

From: jfcm <[email-masked]>
Date: Tue, 20 Sep 2005 12:40:48 +0200

Martin,
As you note it IESG is discussing the SMTP use cases draft. There 
have been some comments and the current status is "IESG Evaluation
- Defer". See 
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=12800&rfc_flag=0. 
You reviewed some of the comments I agree with you.

However you may guess that my position on Sam's comment is obviously 
totally different. I think Sam is right. But I stick to my 
compromise: the WG also follows more or less the IAB recommendations. 
The confusion is with IAB. The IAB recommendations tris to protect 
the current "mono-Internet" architecture when to support OPES, 
instead of documenting a "multi-Internet" architecture (architectural 
parameters switched from "mono" to "multi") actually based upon OPES 
and killing the middlebox patch.

The document Sam wants is therefore not to be asked to an Engineering 
WG but to an Architectural team. There is no problem to write such a 
document for the OPES case. But a global consistency is necessary and 
this is where it becomes a problem, because it is a new Internet version.

On can summarise it as:
                            +------+
      +-------+__OCP Link __| ones |__ OCP optional links __ +------+
end -| opes  |             +------+----+------+  +------+   | opes |- end
      +-------+ -------------- standard | opes |--| smtp |-- +------+
                                        +------+  +------+
Where ONES stands for my fancy pet Open Network(ed) Extended 
Services, i.e. the services to the end to end relations (protocol and 
content).

This fully supports:
- the end to end principles
- the protocol on the wire
- the dumb network approach
and replaces middleboxes with the power of a _parallel_ specialised 
protocol. Instead of using a single (mono-Internet) link the end to 
end process only uses multiples (multi-Internet) links. To show this 
is not a phenomena related to SMTP etc. but proper to OPES/ONES, the 
establishment of the OCP link needs an IP address: it can be found 
via the standard DNS using a dedicated ONES Class. The Domain Name 
being used _can_ be multi-class.

- when using class IN it resolves the standard link path (here MX)
- when using class ONES it resolves the concerned ONES IP address.

Sam is right. Another document is needed.
jfc