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.