Re: [yam] Russ Housley's Discuss on draft-ietf-yam-rfc4409bis-02: (with DISCUSS)

[John C Klensin <[e-mail]>]

Speaking personally, not as editor.

First, I can live, both personally and as editor, with Dave's
latest proposed text (although I'd prefer to see S/MIME added
back in).

But I think that, in the quest of apparent precision, we are
being a little unrealistic.  There are digital signature systems
around and in use that do not conform to the IETF-standardized
versions of DKIM, PGP, and S/MIME.  There are still environments
in which message content is secured by computing a message
integrity check values and then sending that value over a
separate channel, independent of the message itself.  In the
general case -- the three IETF-standard protocols excluded-- we
can't even have a general expectation that the Submission server
will be able to recognize the presence of a signature mechanism
because that mechanism may be supported through
undocumented/non-standard message header fields or
undocumented/non-standard envelope fields. In the case of
out-of-band transmission of a MIC, there may be no hint at all
in the envelope or message that a check is being done.

Depending on the method used, what it signs or verifies, and
what canonicalization is specified, many of the transformations
explicitly permitted by submission servers may mess things up,
usually be rendering a signature or separate MIC invalid.
Keeping in mind that we assume, at least formally, that
Submission servers are under the administrative control of the
sender, we can sensibly advise that the sender make sure the
Submission server is aware of any specialized constraints on its
actions (not only ones associated with signatures, although
those may be the most important case).   We can sensibly advise
(and probably should, given the concerns Russ identified about
invalid signatures versus no signatures) that part of that
Sender (or MUA) communication with the submission server include
agreements about whether the Submission server should remove
possibly-affected signatures, ignore the problem, re-sign the
message with its own keys and mechanisms (or incrementally if
that is feasible), or even return the message to the submitter
with an explanation of the problem. 

Other than advising such communication (which is better than a
dragon-warning, but maybe not much), there really isn't anything
we can say here because such statements would be very
method-dependent  and possibly dependent on the submission
environment (as well as too dependent on the  details of
less-mature protocols to be appropriate in a full standard). 

I think Dave's phrasing is better than the original, but I don't
think we should delude ourselves that it supplies real advice.
All it does is to make a statement about damage that can occur,
leaving it to the imagination of the reader or implementer what
should be done about it.  In that sense, it is just a
translation of the original "there be dragons" warning into
slightly more attractive standards-language.   Again, if that is
what the community wants, I'm ok with it.  But we are spending a
lot of time on this for a very small incremental gain over
either saying nothing or saying "Submission servers should be
really, really, careful that their well-intentioned changes to
messages don't screw things up".

     john