--On Wednesday, August 24, 2011 14:26 -0700 Ned Freed
<[email protected]> wrote:
>> Speaking personally, not as editor.
>...
>> 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
>...
> This is the same primary point, more or less, that I made in
> my original reply.
Yes, I know. But the point seems to have gotten lost in the
noise. My apologies for not explicitly crediting you.
> It's why it's simply wrong to be using
> compliance language here, irrespective of the process issues
> with adding it to a full standard: Since you cannot in general
> tell if a signature/hash/mic/whatever is even being used,
> short of never touching message content at all, including
> stuff like MIME downgrading, you cannot possibly honor a
> "SHOULD respect any signature scheme that is present".
Right.
>> 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.
> Yep, although I note that your chances are a lot greater if
> you restrict your signature to inner message content and use
> the generic multipart/signed container to indicate its
> presence.
Again, yes. And that is why the IETF versions of the PGP and
S/MIME approaches do just that, rather than trying to sign outer
headers and, fwiw, why we didn't feel a need to mention this
issue (any more than other things a Submission server could mess
up) in earlier versions of the Submission server RFCs. In order
to accomplish a different objective, DKIM signs headers. For
that reason, I think it would be entirely reasonable to require
that the DKIM specs say something like "If an MUA is going to
use a Submission server that modifies, fixes, or otherwise
diddles with headers that need to be signed, the DKIM signature
better be applied by that Submission server and not the MUA or
originating machine". But that is a DKIM problem and not a
4409bis one. And, yes, I think you've said that before too.
>> 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
>...
>> 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".
>
> I think it's important to at least point it out so that
> there's some chance people will at least be aware of the
> issue. I agree that anything more is too much.
Then, IMO, Dave's latest version is too much between it can be
read as implying that, if the signature isn't associated with
DKIM or PGP (or maybe S/MIME), then transformations are safe.
It can also be read as implying that the Submission server can
tell whether or not the message is signed and we know that isn't
true. So, if something should be said (and I agree that is
useful), it should be closer to:
Implementers of MSAs and those who submit messages to
them should be aware that MUAs (or other submission
system components) may apply digital signatures or other
types of message integrity checks (MICs) to messages and
that, in the most general case, the MSA may not be able
to detect the fact that MIC arrangements have been used
by inspection of the message. Some of the
transformations permitted by this specification will
invalidate such MICs. Although the risk is less
if MICs protect only internal body parts (i.e., that the
main header fields are not signed) that restriction does
not completely eliminate the risk. Consequently,
operators of message originating systems that apply such
signatures should ensure that the relevant MSAs are
aware that signatures may be present (or external MICs
used) and that they are properly configured to avoid
making changes, remove signatures, or accept that
signatures may become invalid as appropriate.
Still no normative language, but I think that addresses the
concerns we have been trying to raise while, at the same time,
actually saying something (and not implying that three
IETF-defined protocols are the only options). It can probably
be improved by editing -- it is really just an example of a
slightly different approach -- or by eliminating statements that
go into more detail than is needed.
best,
john
_______________________________________________
yam mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/yam
