ietf
[Top] [All Lists]

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

2007-01-10 15:45:25
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

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf