Date: Fri, 26 Sep 2003 13:08:11 -0400
From: Bennett Todd <bet@...ul.net>
To: Earl Hood <earl@...lhood.com>
Cc: bugtraq@...urityfocus.com, MightyE <trash@...htye.org>,
	Lawrence MacIntyre <lpz@...l.gov>
Subject: Re: base64

2003-09-25T19:46:36 Earl Hood:
> On September 25, 2003 at 11:30, Bennett Todd wrote:
> > There's a third method, which I think is rather better than either
> > of those. [canonicalize]
> 
> You cannot do this for signed messages, therefore, you still
> need to either decode in all possible ways or drop the message
> (or the offending entity).

Or break the signature in the canonicalization.

Good catch. Lots of work will be needed to really completely solve
this, and different solutions will fit different security stances.

I think in terms of the security stances for corporations, with
particular focus on financial services firms. A very, very different
answer would be in order for e.g. an ISP.

For the kind of companies I work in, the very best solution would
(in my opinion!) be a canonicalizer that was smart enough to hold
off actually committing any rewrites until it finds something that's
ambiguous or dangerous, and that leaves notes describing what it did
and why.

Then when people get their mail whose sigs don't check, they get an
explanation of what needs fixing. Depending on the user they may
need to call a helpdesk to interpret the note and help them, or
their correspondent, to reconfig to fix the problem, but that's as
may be.

Also, in this sort of setting at least, you need very different
handling of inbound -vs- outbound messages. Inbound messages get
repaired --- or broken, in the case of digital sigs --- and then
sent on to their intended internal recipient. Outbound traffic gets
canonicalized if necessary, with commentary, gets malware replaced
with "evil badness used to be here, I yanked it", then gets bounced
back to the internal sender.

-Bennett

Content of type "application/pgp-signature" skipped

Powered by blists - more mailing lists