Open Pluggable Edge Services (OPES) SMTP Use Cases
draft-ietf-opes-smtp-use-cases-06

[Ballot discuss]
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.

RH> Draft -04 addresses my end-to-end encryption comment; however, the
RH> digital signature comment was not addressed.

[Ballot discuss]
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.

RH> Sraft -04 addresses my end-to-end encryption comment; however, the
RH> digital signature comment was not addressed.

[Ballot discuss]
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).
           
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.

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.

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.


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

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.

[Ballot 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.

[Ballot 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.

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.


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.


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

[Ballot 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.

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.

- 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)?

- 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?

- 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!

[Ballot discuss]
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.