Subject: Re: Last Call: draft-ietf-opes-smtp-security (Integrity, privacy and security in OPES for SMTP) to Informational RFC

From: Frank Ellermann <[email-masked]>
Date: Sat, 06 Jan 2007 21:42:42 +0100

The IESG wrote:

> <draft-ietf-opes-smtp-security-02.txt> as an Informational RFC

The "bypass" construct apparently includes what's also known as 
"challenge response scheme".  If that's the case it's net abuse,
unless the challenge is guaranteed to be sent to the originator.

The only relevant case where that's guaranteed I'm aware of is an
SPF PASS.  Even in that case some originators might consider the
challenge as abusive, but at least it's not unsolicited, and they
can stop their communication attempts with such OPES receivers.

But the general case is no SPF PASS, and then the challenge goes
most probably (near 90%) to innocent bystanders.

Frank

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Eliot Lear <[email-masked]>
Date: Sun, 07 Jan 2007 09:21:28 +0100

Frank,

I'd have to go further than what you wrote.  I believe the document 
should explicitly discuss interactions with DKIM, as that document is in 
front of the IESG at this time for approval as a Proposed Standard.  
Many modifications to a message will invalidate a DKIM signature.  It 
may be possible for an OPES agent to resign, but there are implications 
there too that should be discussed.

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Mon, 8 Jan 2007 11:15:32 -0800

At 9:21 AM +0100 1/7/07, Eliot Lear wrote:
>Frank,
>
>I'd have to go further than what you wrote.  I believe the document should explicitly discuss interactions with DKIM, as that document is in front of the IESG at this time for approval as a Proposed Standard.  Many modifications to a message will invalidate a DKIM signature.  It may be possible for an OPES agent to resign, but there are implications there too that should be discussed.
>
>Eliot

I don't think adding explicit interactions with DKIM is appropriate for this document,
which is a high-level informational document on the set of problems of adapting
OPES (developed in a bidirectional model) to SMTP, which has very different
usage. 

To tackle the the bypass question; the Bypass section says:

>3.2  Bypass in OPES/SMTP
>
>   If a mail message was rejected or could not be delivered (and a NDR
>   was sent), the originator of the message may want to bypass the OPES
>   system that blocked the message.
>
>   If the recipient of a message receives a mail with OPES trace
>   information, he may want to receive a non-OPES version of the
>   message.  Although there is no direct in-band request from the
>   recipient back to the OPES system, the recipient can contact the
>   sender and ask her to send the message again and to add a bypass
>   request for the OPES system.

Note that this implies that the receiver detects the use of OPES
by trace information.  How the recipient could contact the sender
is left undefined here.

>   An OPES system MAY also define out-of-band methods to request a
>   bypass, for example a web interface or an email message sent to it
>   that results in the creation of a white list entry for the sender/
>   recipient pair.  Examples for these out-of-band methods are email
>   systems that keep a copy of the original email in a quarantaine queue
>   and only send the recipient a block notification plus either a direct
>   link, or a digest notification with the ability to retrieve the
>   original message from quarantaine.

I assume that this is where Frank sees the potential for a challenge
response.  I have no comment on whether this is "net abuse", but
you could easily see the mailman spam quarantine system under
this model.  The spam checker puts the document in a quarantine
and one or more systems is used to prove that it out to get out.

This presumes, though, that the action is taken by the recipient,
not by the originator.  I do not see where the challenge/response
to the originator fits here.  Can Frank clarify?

>   OPES MUST implement methods to request a bypass but there cannot be a
>   guarantee that the bypass request will be approved.  The security
>   needs of the receiver or the receiver's network may demand that
>   certain filters must not by bypassed (such as virus scanners for
>   example).  In general, the receiver should be able to configure a
>   client centric OPES system, i.e. the receiver should be able to
>   indicate if he/she wants to receive a non-OPES version if it is
>   available.
>
>   Bypass requests could be added to the mail message or within the SMTP
>   dialog.  Bypass request data added to the mail message cannot bypass
>   OPES services that operate on other SMTP dialog commands, which are
>   sent before the mail message has been received (such as RCPT
>   commands).

Note that this high-level document does not propose any such protocol
mechanism.

>   Bypass request data sent at the beginning of a SMTP dialog may not
>   reach the OPES system if intermediate SMTP relays do not support
>   those bypass request commands and don't forward that information.

You could theoretically model the DKIM verification as an OPES-like action,
and require that the DKIM provide the same sort of bypass functionality;
it already provides trace functionality in ways that meet the opes-smtp
limits.  I don't think folks have done so so far, because they have not
seen the signer's actions as the actions of an intermediary.  The action
of an MTA in potentially rejecting mail on the application of a policy does
seem to fall into the same problem space.
				Ted

>>The "bypass" construct apparently includes what's also known as "challenge response scheme".  If that's the case it's net abuse,

---

From: Frank Ellermann <[email-masked]>
Date: Mon, 08 Jan 2007 21:10:29 +0100

> I don't think adding explicit interactions with DKIM is appropriate

If OPES sees the complete message (header + body) it could be used as
signer (conceptually somewhere between MSA and mailout) or verifier
(between MX and MDA, if it has DNS access).  That's no problem.

It would be bad if OPES removes or quarantines critical MIME parts
needed for a verifier behind OPES.  Or if it manipulates parts of the
header required for DKIM.  Probably an obvious "don't do that", but
it's less obvious if something behind OPES (e.g. the MDA) decides to
forward or resend the message to a 3rd party.  DKIM is designed to
survive 1123 5.3.6(a) scenarios.

For some purposes OPES has to be as near to the border MX as possible,
ideally allowing to reject the mail before it's accepted.  For other
purposes it has to be as near to the MDA as possible, after it's clear
that the mail is not forwarded to a 3rd party.  That's a conflict.

>> system that blocked the message.

I interpreted that paragraph as "reject (or if that's too late bounce)"
with instructions to the originator how to bypasss OPES.  And that's
in essence the same as C/R.

> I have no comment on whether this is "net abuse"

A bounce to an unverified (no SPF PASS or similar) Return-Path most
probably hits innocent bystanders.  That's unsolicited bulk e-mail,
the "bulk" part being that it's from a bot, not from a human sender,
and some inluding me consider UBE as spam, i.e. net abuse.

> you could easily see the mailman spam quarantine system under this
> model.

Mailman is behind all spam protection systems, DNSBLs, SPF, SA, OPES,
SIEVE, and what else.  It has a decent chance that most crap including
bogus Return-Paths is already filtered before it sends any inquiries
to the envelope sender (as specified in RFC 3834).  But OPES isn't
behind the filters, it is (a part of) the filters.

> Can Frank clarify?

See above, I wasn't talking about "bypass" actions triggered by the
recipient (maybe talking to the sender how to do this), but about any
"bypass" proposal in NDRs to forged envelope senders.

I never got the OPES idea.  Of course folks can do their A/V and
SIEVE and SIQ (I-D.irtf-asrg-iar-howe-siq-03) businesss on a separate
box, they can even outsource it, but they do this already without OPES.
So what's the technical point of OPES wrt mail ?

Frank

---

From: Eliot Lear <[email-masked]>
Date: Wed, 10 Jan 2007 16:59:38 +0100

Hi Ted,

> OPES (developed in a bidirectional model) to SMTP, which has very different

The reason I'm concerned is that any form of OPES might invalidate a 
DKIM signature.  What can we say in a DKIM sense about OPES trace 
information?  In addition, an OPES server might choose to resign a 
message with DKIM.  However, we in the DKIM group wouldn't at this point 
know what to do with that.  But it might be a consideration for SSP as 
an authorized third party signature.  Anyway, my point is that there are 
considerations here that have not been thought out (at least not by me ;-).

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Wed, 10 Jan 2007 14:42:29 -0800

At 4:59 PM +0100 1/10/07, Eliot Lear wrote:
>
>The reason I'm concerned is that any form of OPES might invalidate a DKIM signature.  What can we say in a DKIM sense about OPES trace information? 

Do you mean, should a DKIM server sign OPES trace information?  The DKIM
base document says:

4.  Semantics of Multiple Signatures

   A signer that is adding a signature to a message merely creates a new
   DKIM-Signature header, using the usual semantics of the h= option.  A
   signer MAY sign previously existing DKIM-Signature header fields
   using the method described in section Section 5.4 to sign trace
   header fields.

and

   Signers should be careful of signing header fields that might have
   additional instances added later in the delivery process, since such
   header fields might be inserted after the signed instance or
   otherwise reordered.  Trace header fields (such as Received and DKIM-
   Signature) and Resent-* blocks are the only fields prohibited by
   [RFC2822] from being reordered.

if and when the protocol requirements in this document are embodied
in protocol specifics, the mechanics of carrying the trace information would need
to be fleshed out.  The consistent use of the term trace information
leads me to believe, though, that the protocol would put this information
in a trace header field (as DKIM does its signature).

>In addition, an OPES server might choose to resign a message with DKIM.  However, we in the DKIM group wouldn't at this point know what to do with that.  But it might be a consideration for SSP as an authorized third party signature.  Anyway, my point is that there are considerations here that have not been thought out (at least not by me ;-).

The document says this:

2.2  Non-standardized SMTP adaptations at SMTP gateways

   A large number of email filters are deployed at SMTP gateways today;
   in fact all usecases listed in "OPES SMTP Use Cases" [6] are already
   deployed, often in non standardized ways.  This opens a number of
   integrity, privacy and security concerns that are not addressed, and
   SMTP itself does not provide effective measures to detect and defend
   against compromised implementations.

In other words, if you will be worried about what OPES might do, you should
already be worried about what existing systems do do.

>Eliot
			regards,
				Ted

---

From: Dave Crocker <[email-masked]>
Date: Wed, 10 Jan 2007 17:09:36 -0800

Ted Hardie wrote:
>> The reason I'm concerned is that any form of OPES might invalidate a DKIM
>> signature.  What can we say in a DKIM sense about OPES trace information?
> 
> Do you mean, should a DKIM server sign OPES trace information?

Maybe one of you, or someone else, can help me out of some rather basic
confusion confusion.

The OPES SMTP draft uses language much like Ted's, here ("OPES trace
information".)

It is in the nature of a reference to details within a specification, with
normative protocol details, precise data definitions, etc.  Yet I can't find
such a specification.  The cited OPES documents either are generic about the
concept and its implications, or refer to HTTP details.

And so, for example, within the email architecture, I am not yet understanding
which components qualify as being "OPES systems" and which don't.  Equally I
seem to be entirely missing what insight or guidance is intended here.

As for trace information, are all Received headers "OPES" information?  If so,
why?  If not, why?

And so on...

Help?

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Barry Leiba <[email-masked]>
Date: Fri, 12 Jan 2007 00:42:03 -0500

Eliot Lear said...
> there too that should be discussed.

I'm with Ted here: this is a very high-level document, not one that's 
actually specifying the OPES SMTP "adaptation".  Perhaps (just perhaps; 
I'm not convinced of that either) the final adaptation specification 
should talk about DKIM.  But not this one.

In particular, I'll note that there are many places where a mail message 
can be modified today, in ways that break the DKIM signature -- in an 
SMTP server, in a Sendmail milter, in a Sieve script, in a mailing-list 
expander, and so on.  Think of OPES in SMTP as a standardized version of 
Sendmail milter (which would, I hope, fix some of the unfortunate 
limitations of the latter).  Sure, there are things it might do that 
could invalidate DKIM signatures.  And there are lots of things it might 
do that won't.

Apart from a note that says, "Changing the message might invalidate DKIM 
signatures, so go look at the DKIM spec and make sure you understand 
what you're doing," I don't see what some future OPES SMTP adaptation 
document should do about this.  And I certainly don't see what this 
document should do about it.

Barry

--
Barry Leiba, STSM, Internet Messaging Technology  ([email-masked])
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam

---

From: Douglas Otis <[email-masked]>
Date: Sat, 13 Jan 2007 03:43:08 -0800

> document should do about it.

DKIM has other problems.  DKIM mandates the From header be signed, but
also severely limits the range of identities that can be associated with
the signature.  As such, DKIM breaks badly when signing headers that
contain "<utf8@utf-8 [ascii@ascii]>" or <utf8@utf-8>.  The "downgrade"
process will remain with email, which then calls into question the
practicality of mandating the signing of UTF-8 based upon a premise of
visual recognition sans annotation.

Had the DKIM signature permitted the capturing of the identity on who's
behalf it was being applied without the restrictions, then not signing
headers would remain far less problematic.  Protection against spoofing
_must_ depend upon some form of annotation anyway and an ability to
associate one domain with another.  DKIM, as currently envisioned, is
not robust and mandates an impractical sharing of private keys or zone
delegations as the _only_ means to link headers with signatures.  Even
confirming DKIM identities may soon require conversion to ACE labels.

-Doug