Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades

2011-05-25 Thread Hector Santos
John R. Levine wrote:
>>> It tells me signing and encryption certificates are valid and even their
>>> root certificates are valid...
>>
>> Well, something's wrong with it.  I checked the signature in Alpine,
>> Thunderbird, and Evolution, and they all agree it's fine.
> 
> I went back and looked in more detail.  The problem appears to be that 
> this mailing list wraps the signed body in a MIME multipart/mixed 
> section including both the signed message and the unsigned footer.  Some 
> MUAs look inside the mixed and see the signature, some don't.  For the 
> ones that do, I haven't checked to see how if at all they distinguish 
> the signed part from the unsigned when they show you the message (shades 
> of all the l= arguments.)
> 
> So this tells me that existing mail software doesn't try very hard to 
> recover signatures from modified messages, even for simple changes that 
> don't need any guessing or heuristics to undo.  Why would anyone think 
> that the situation with DKIM would be any different?

I think you were telling people for a while now to use it for some reason.

Anyway, I don't think the problem is as you state.

 From what I see, I think the issue here is no MIME Application Type 
association for the application and extension your message was made. 
Your email provides this MIME info:

Content-Type: APPLICATION/pkcs7-signature; name=smime.p7s
Content-Transfer-Encoding: BASE64
Content-Description: S/MIME Cryptographic Signature
Content-Disposition: attachment; filename=smime.p7s

Software that offer auto launching (generally with user permission 
necessary) using MIME Application association, can either have its own 
table or depends on the OS to provide it.

For example, under Windows, you can use a console window using the 
ASSOC command to get the file type for the extension:

ASSOC .p7s

and it returns

.p7s=P7SFile

then you use the FTYPE command to see what application is responsible 
to handle this file type.

FTYPE P7SFile

and it returns:

p7sfile=rundll32.exe cryptext.dll,CryptExtOpenPKCS7 %1

So if the email has an attachment file name/extension smime.p7s,  then 
it should allow the user (with permission) to load it by running the 
above rundll32.exe process passing the rest of the line as parameters 
and substituting %1 with the local temp storage FQFN for smime.p7s

Now, under TBIRD, it apparently is independent of the built-in Windows 
MIME association table in the registry.  So one would think that 
Outlook would not have a problem and indeed it doesn't; it displays a 
"seal icon" save button for the SMIME.P7S attachment file when viewing 
the message under OE.

Under TBIRD, you can click

 TOOLS | OPTIONS

and under the Attachments properties tab, you will see the View & Edit 
Associations button.   For me, it is empty list - no MIME associations 
so shown as a file name "PART 1.2"

Now why didn't it atleast show SMIME.P7S as a file attachment?   You 
did have:

Content-Disposition: attachment; filename=smime.p7s

You should check bugzilla or asks the TBIRD folks why it doesn't at 
least show the actual file name as the attachment because even if 
TBIRD doesn't have its own table, when the user tries to save it, 
Windows will most likely make the shell association.

BTW, under OE, while it does show the SMIME.P7S icon attachment, the 
message display is blank.  That may be related to what you are talking 
about.  In any case, its all fubar.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades

2011-05-25 Thread John R. Levine

It tells me signing and encryption certificates are valid and even their
root certificates are valid...


Well, something's wrong with it.  I checked the signature in Alpine,
Thunderbird, and Evolution, and they all agree it's fine.


I went back and looked in more detail.  The problem appears to be that 
this mailing list wraps the signed body in a MIME multipart/mixed section 
including both the signed message and the unsigned footer.  Some MUAs look 
inside the mixed and see the signature, some don't.  For the ones that do, 
I haven't checked to see how if at all they distinguish the signed part 
from the unsigned when they show you the message (shades of all the l= 
arguments.)


So this tells me that existing mail software doesn't try very hard to 
recover signatures from modified messages, even for simple changes that 
don't need any guessing or heuristics to undo.  Why would anyone think 
that the situation with DKIM would be any different?


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

smime.p7s
Description: S/MIME Cryptographic Signature
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] 8bit downgrades

2011-05-25 Thread Hector Santos
Scott Kitterman wrote:
> On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote:
> ...
>> When I remove the domains I know, the rest is pretty much spam.
> ...
> 
> Isn't that pretty generally true, DKIM or no DKIM.  

Sure, in general I would agree with that and most of it are single 
shot deals.

There seem to be a pattern among the different spammer domains and 
that shouldn't be a surprise when using templates.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread Dave CROCKER


On 5/25/2011 9:59 AM, John Levine wrote:
>> The idea is to anticipate any unknown signature breaker.
>
> I'm pretty sure that's specifically out of scope.
>
> And I promise that whatever you do, short of wrapping the whole
> message in opaque armor, I can come up with something that will
> break it.

One might have a goal of attempting to be robust against all forms of potential 
breakage.

That's not likely to be the goal of this sort of exercise.  Rather, it will be 
to choose a set of particular types of breakage, ignoring others.  For an 
effort 
like that, it is not meaningful to come up with additional types of breakage, 
since there is no attempt to cover such additional examples.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] 8bit downgrades

2011-05-25 Thread Scott Kitterman
On Wednesday, May 25, 2011 02:04:45 PM Hector Santos wrote:
...
> When I remove the domains I know, the rest is pretty much spam.
...

Isn't that pretty generally true, DKIM or no DKIM.  

Scott K
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] 8bit downgrades

2011-05-25 Thread Hector Santos
Alessandro, with the undotting leading dot fix, I went back and adding 
code to adjust for this by undotting it in the C14N code and what a 
major difference compared to the failed rate listed before:

  Failure rates for level encoding type (OLD)
++
| enctype   total   bodyfail pct |
||
| 8bit  31  25   80.6|
|   54611236 22.6|
| binary5   120.0|
| quoted-printable  1188179  15.0|
| base6432  3 9.3|
| 7bit  1465106   7.2|
++

   Failure rates for encoding type (NEW)
+--+
| enctype total   bodyfail   pct   |
|--|
| 8bit31  22 71.0  |
| binary  5   1  20.0  |
| base64  32  3  9.4   |
| quoted-printable12061078.9   |
| 7bit165485 5.1   |
| 55121883.4   |
+--+

+--+
|   OLD  NEW   |
| hash  bodyfail bodyfail  |
|--|
| relaxed/relaxed   1085 238   |
| relaxed/simple276  56|
| simple/simple 215  112   |
+--+

Overall

   OLD: 18.7% failure
   NEW:  4.8% failure

and the major contributor to this is that I have no more 
facebookmail.com failures!

When I remove the domains I know, the rest is pretty much spam. :)

Hector Santos wrote:
> Alessandro Vesely wrote:
> 
>> For example, MTAs that autoconvert from quoted-printable to 8bit, a
>> rather common circumstance.
> 
> I did the following Content-Transfer-Encoding failure analysis:
> 
>  Failure rates for message top level encoding type
> ++
> | enctype   total   bodyfail pct |
> ||
> | 8bit  31  25   80.6|
> |   54611236 22.6|
> | binary5   120.0|
> | quoted-printable  1188179  15.0|
> | base6432  3 9.3|
> | 7bit  1465106   7.2|
> ++
> 
> Based on my PCN, 8bit does have a high rate of failure, but they are a 
> very small amount of the grand total.  The encoding types; QP, base64 
> and 7bit offers the better lower failure rate.  Except for the 3 
> base64 fails, but I can't tell if they originated that way or not. I 
> will take a SWAG that these represent direct messages and were not 
> going thru a list.
> 
> It would be interesting to see what Murray can show for his volume 
> collection.
> 

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread MH Michael Hammer (5304)


> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-
> boun...@mipassoc.org] On Behalf Of John Levine
> Sent: Wednesday, May 25, 2011 12:59 PM
> To: ietf-dkim@mipassoc.org
> Cc: ves...@tana.it
> Subject: Re: [ietf-dkim] New canonicalizations
> 
> >The idea is to anticipate any unknown signature breaker.
> 
> I'm pretty sure that's specifically out of scope.
> 
> And I promise that whatever you do, short of wrapping the whole
> message in opaque armor, I can come up with something that will
> break it.
> 

+1


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread John Levine
>The idea is to anticipate any unknown signature breaker.

I'm pretty sure that's specifically out of scope.

And I promise that whatever you do, short of wrapping the whole
message in opaque armor, I can come up with something that will
break it.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread Hector Santos
Alessandro Vesely wrote:
>>> 3) For text parts, completely remove /any/ whitespace.  Additionally,
>>> remove most punctuation, especially from begin and end of lines.
>>
>> Do we really need this?  Do you know of cases related to this?
> 
> The idea is to anticipate any unknown signature breaker.  My three
> points above are rather generic.  They are meant to be expanded so as
> to include your five points below, and more.
> 
> I think it is quite obvious that MIME rewriting generates new
> boundaries, and may alter an entity's header.
> 
> Non-text binary content that arrives corrupted deserves breaking a
> signature.  However, a rewriter may decode a base64 entity for local
> storage, and then re-encode it with a different line length.
> 
> Text undergoes any kind of massage, trailing "=" may be leftover,
> CRLFs may be doubled, "From " turned into ">From ", besides the
> leading dots you mention in point five.

Why not just DKIM Signer ALWAYS  base64 a MIME message/rfc822, sign it 
and thats it? :)

>>   4 - Lines over 998 (1000 with CRLF), this is an invalid RFC5322, but
>>   its possible some verifiers are designed to do a buffered C14N
>>   and don't check for RFC5322 line lengths between two memory points
>>   in the buffer as oppose as a line by line feed into the C14N
>>   function.  Why buffer vs line?  speed.
> 
> I imagined the C14N function reads characters one by one.  On finding
> CRLF it can go back a few bytes to remove end-of-line punctuation.
> However you code c14n(), it will be sparklingly faster than sha256().

The code can be written to do the C14N first, then do a time hash 
call, or you can do it on the fly C14N/HASH.  I use memory file maps 
to deal any potential large mail and the line parsing doesn't hurt speed.

>> and I just found a yet another problem which I was currently 
>> investigating to see where it this "mite" is occurring:
>>
>>   5 - Incorrect handling of lines beginning with dots, for example
>>   I sent a message containing a line beginning with:
> 
> Yes, dot is one of the punctuation characters that should be removed.

This turned out to be a bug in our beta code, revamped to support I/O 
completion ports and the code for undotting of the leading dot (per 
RFC5321 4.5.2) fell thru the crack.  So we can nix this one. :)

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] No signatures, bad signatures, cousin domains

2011-05-25 Thread Murray S. Kucherawy
> -Original Message-
> From: Michael Thomas [mailto:m...@mtcc.com]
> Sent: Wednesday, May 25, 2011 7:03 AM
> To: Murray S. Kucherawy
> Cc: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] No signatures, bad signatures, cousin domains
> 
> Heuristic based systems like SA are subject to the phases of the moon
> with respect to what they find valuable and for how long. If they find
> it useful to educe something from DKIM or lack thereof, more power to
> them. Heck, if they just used the signature header pattern to determine
> spam from ham for different senders, that would be cool too. This is not
> in conflict from the statement that _cryptographically_ a broken signature
> is no different than a missing signature. SA and its ilk just don't operate
> on the plane of mathematical provables is all; nothing wrong with that.

My use of Spamassassin for correlation of DKIM verification versus message 
classification is really only a proof-of-concept thing.  Certainly connecting 
this stuff to a much more robust spam feedback system like the one Cloudmark 
has would produce far better results.  It's somewhere on my to-do list.


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread Alessandro Vesely
On 25/May/11 14:27, Hector Santos wrote:
> Alessandro Vesely wrote:
>> On 25/May/11 10:03, Hector Santos wrote:
>>> How would 7/8 bit be considered?
>>>
>>> Personally, the STRIP C14N idea would work just fine by removing all 
>>> trailing WSP (CR, LF, SP) and for QP text, decode it first.  I'm 
>>> considering updating my 2006 I-D to include the QP decoding logic.
>> 
>> I propose a much more radical approach, something that will likely
>> land on the too-loose side.  Such kind of approach is justified by the
>> "most breakage is innocent" theory, and by already having two
>> canonicalizations on the too-tight side.
>> 
>> For example, consider these criteria for feeding the body hash:
>> 
>> 1) For multipart MIME messages, completely remove the preamble, the
>> epilogue, and all boundaries and entity headers.
>> 
>> 2) For MIME encoded parts, get back to the binary content.
>> 
>> 3) For text parts, completely remove /any/ whitespace.  Additionally,
>> remove most punctuation, especially from begin and end of lines.
> 
> Do we really need this?  Do you know of cases related to this?

The idea is to anticipate any unknown signature breaker.  My three
points above are rather generic.  They are meant to be expanded so as
to include your five points below, and more.

I think it is quite obvious that MIME rewriting generates new
boundaries, and may alter an entity's header.

Non-text binary content that arrives corrupted deserves breaking a
signature.  However, a rewriter may decode a base64 entity for local
storage, and then re-encode it with a different line length.

Text undergoes any kind of massage, trailing "=" may be leftover,
CRLFs may be doubled, "From " turned into ">From ", besides the
leading dots you mention in point five.

> We should identify and list the sort of transformation issues we are 
> seeing.

Erring on the too-lose side implies some generalization.

> I have identified four so far:
> 
>   1 - We forgot a possible top CRLF. We dealt with the bottom 
>   but not the top,
> 
>   2 - Top level QP decoding,
> 
>   3 - Top Level reformatting to C-T-E: base64 (not MIME multi-part)
> 
>   4 - Lines over 998 (1000 with CRLF), this is an invalid RFC5322, but
>   its possible some verifiers are designed to do a buffered C14N
>   and don't check for RFC5322 line lengths between two memory points
>   in the buffer as oppose as a line by line feed into the C14N
>   function.  Why buffer vs line?  speed.

I imagined the C14N function reads characters one by one.  On finding
CRLF it can go back a few bytes to remove end-of-line punctuation.
However you code c14n(), it will be sparklingly faster than sha256().

However, distinguishing begin middle of line versus begin/end is
possibly inconsistent, since line breaks may be altered because of
invalidly long lines or RFC3676 rewrapping.

>   I found 98 such buffer hash errors from various domains due to
>   having at least 1 super long line.

Some MUAs consistently keeps paragraphs on a single line.

> and I just found a yet another problem which I was currently 
> investigating to see where it this "mite" is occurring:
> 
>   5 - Incorrect handling of lines beginning with dots, for example
>   I sent a message containing a line beginning with:
> 
>   ... blah blah blah.  blah.
> 
>   and it was received by my SMTP server as:
> 
>    blah blah blah.  blah.
> 
>   and its sent to this list, it comes back as:
> 
>   . blah blah blah.  blah.
> 
> I checked my SMTP server and its correct. I just now pretty much 
> confirmed ThunderBird is causing this initial dot escaping error by 
> sending mail to my gmail host and hotmail host accounts. The "" 
> showed up in my new mail bin. But it also appears there could be an 
> intermediary with a bug as well adding yet another dot.
> 
> While we like to shift blame to the buggy software, IMV, since 
> transport DOT escaping is a SMTP requirement and there could be these 
> small issues, I'm thinking maybe we should consider a similar 
> "relaxed" logic now done for reducing multiple  to reduce 
> multiple  as well but only when its begins on a new line (or for 
> block transfers, preceded by ).  So a line like
> 
>   blahblahblah
> 
> it becomes:
> 
>   blahblahblah

Yes, dot is one of the punctuation characters that should be removed.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] No signatures, bad signatures, cousin domains

2011-05-25 Thread Michael Thomas
On 05/25/2011 01:05 AM, Murray S. Kucherawy wrote:
> Interesting.  I ran some queries on our data for ebay.com, paypal.com, 
> chase.com and bankofamerica.com.  In all cases, messages with failed 
> signatures were never tagged by Spamassassin, and at most 7% (usually less) 
> of unsigned mail where the From: field contained those domains was tagged.  
> This seems to concur with the "most breakage is innocent" theory and also 
> supports the notion that treating a broken signature as equal to no signature 
> is almost always the right way to go.
>

Heuristic based systems like SA are subject to the phases of the moon
with respect to what they find valuable and for how long. If they find
it useful to educe something from DKIM or lack thereof, more power to
them. Heck, if they just used the signature header pattern to determine
spam from ham for different senders, that would be cool too. This is not
in conflict from the statement that _cryptographically_ a broken signature
is no different than a missing signature. SA and its ilk just don't operate
on the plane of mathematical provables is all; nothing wrong with that.

Mike

___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread Hector Santos

Alessandro Vesely wrote:
> On 25/May/11 10:03, Hector Santos wrote:
>> How would 7/8 bit be considered?
>>
>> Personally, the STRIP C14N idea would work just fine by removing all 
>> trailing WSP (CR, LF, SP) and for QP text, decode it first.  I'm 
>> considering updating my 2006 I-D to include the QP decoding logic.
> 
> I propose a much more radical approach, something that will likely
> land on the too-loose side.  Such kind of approach is justified by the
> "most breakage is innocent" theory, and by already having two
> canonicalizations on the too-tight side.
> 
> For example, consider these criteria for feeding the body hash:
> 
> 1) For multipart MIME messages, completely remove the preamble, the
> epilogue, and all boundaries and entity headers.
> 
> 2) For MIME encoded parts, get back to the binary content.
> 
> 3) For text parts, completely remove /any/ whitespace.  Additionally,
> remove most punctuation, especially from begin and end of lines.

Do we really need this?  Do you know of cases related to this?

We should identify and list the sort of transformation issues we are 
seeing. I have identified four so far:

  1 - We forgot a possible top CRLF. We dealt with the bottom 
  but not the top,

  2 - Top level QP decoding,

  3 - Top Level reformatting to C-T-E: base64 (not MIME multi-part)

  4 - Lines over 998 (1000 with CRLF), this is an invalid RFC5322, but
  its possible some verifiers are designed to do a buffered C14N
  and don't check for RFC5322 line lengths between two memory points
  in the buffer as oppose as a line by line feed into the C14N
  function.  Why buffer vs line?  speed.

  I found 98 such buffer hash errors from various domains due to
  having at least 1 super long line.

   Domains with Illegal RFC5322 text
+-+
| count(*)   sdid |
|-|
| 78 coldwatercreek.com   |
| 4  jcprewards.com   |
| 4  news.redlobster.com  |
| 2  livingsocial.com |
| 2  resultsmail.com  |
| 2  trl3.net |
| 2  xanthianoutswagger.net   |
| 1  numbersoft.info  |
+-+

and I just found a yet another problem which I was currently 
investigating to see where it this "mite" is occurring:

  5 - Incorrect handling of lines beginning with dots, for example
  I sent a message containing a line beginning with:

  ... blah blah blah.  blah.

  and it was received by my SMTP server as:

   blah blah blah.  blah.

  and its sent to this list, it comes back as:

  . blah blah blah.  blah.

I checked my SMTP server and its correct. I just now pretty much 
confirmed ThunderBird is causing this initial dot escaping error by 
sending mail to my gmail host and hotmail host accounts. The "" 
showed up in my new mail bin. But it also appears there could be an 
intermediary with a bug as well adding yet another dot.

While we like to shift blame to the buggy software, IMV, since 
transport DOT escaping is a SMTP requirement and there could be these 
small issues, I'm thinking maybe we should consider a similar 
"relaxed" logic now done for reducing multiple  to reduce 
multiple  as well but only when its begins on a new line (or for 
block transfers, preceded by ).  So a line like

  blahblahblah

it becomes:

  blahblahblah

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread Alessandro Vesely
On 25/May/11 10:03, Hector Santos wrote:
> How would 7/8 bit be considered?
> 
> Personally, the STRIP C14N idea would work just fine by removing all 
> trailing WSP (CR, LF, SP) and for QP text, decode it first.  I'm 
> considering updating my 2006 I-D to include the QP decoding logic.

I propose a much more radical approach, something that will likely
land on the too-loose side.  Such kind of approach is justified by the
"most breakage is innocent" theory, and by already having two
canonicalizations on the too-tight side.

For example, consider these criteria for feeding the body hash:

1) For multipart MIME messages, completely remove the preamble, the
epilogue, and all boundaries and entity headers.

2) For MIME encoded parts, get back to the binary content.

3) For text parts, completely remove /any/ whitespace.  Additionally,
remove most punctuation, especially from begin and end of lines.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] DKIM Scouts, was 8bit downgrades

2011-05-25 Thread Ian Eiloart

On 25 May 2011, at 02:13, John R. Levine wrote:

>> Interestingly enough, outlook tells me this message has been tampered
>> with, but not sure why...
> 
> Probably doesn't have the Comodo validation certificate.

Maybe, but my Mac does, and it complains. As does a Thunderbird client and an 
Outlook client. That's three different setups that are complaining about your 
signature now.

Whether they're right or wrong is largely irrelevant. The fact is that S/MIME 
doesn't seem to be bullet proof.


> I took the copy of my message that came back from the mailing list, ran it 
> through some rather violent transformations (mail to usenet and back) and the 
> S/MIME signature still is OK.
> 
> R's,
> John
> 
>> 
>> On 5/24/11 15:35 , "John R. Levine"  wrote:
>> 
 Are there the same issues with PGP or S/Mime email?
>>> 
>>> Generally no.  They're a group of MIME parts that shouldn't need to be
>>> recoded, or even if they are, will decode to the same value.
> ___
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html

-- 
Ian Eiloart
Postmaster, University of Sussex
+44 (0) 1273 87-3148


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


[ietf-dkim] No signatures, bad signatures, cousin domains

2011-05-25 Thread Murray S. Kucherawy
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Scott Kitterman
> Sent: Monday, May 23, 2011 10:12 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] 8bit downgrades
> 
> > Do you have numbers to show that broken signatures indicate that messages
> > are malicious, or spam, or otherwise worse than otherwise?
> 
> None that I can share unfortunately.  IME no signature is more suspicious than
> a broken one (as you suggest, I think most breakage is innocent), but putting
> broken and no signature into the same bucket is the most sensible and RFC
> compliant way to approach it.

Interesting.  I ran some queries on our data for ebay.com, paypal.com, 
chase.com and bankofamerica.com.  In all cases, messages with failed signatures 
were never tagged by Spamassassin, and at most 7% (usually less) of unsigned 
mail where the From: field contained those domains was tagged.  This seems to 
concur with the "most breakage is innocent" theory and also supports the notion 
that treating a broken signature as equal to no signature is almost always the 
right way to go.


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] New canonicalizations

2011-05-25 Thread Hector Santos
Murray S. Kucherawy wrote:

> You could use an extension tag to capture the original 
> Content-Transfer-Encoding 
> as a hint to the canonical form that was signed, but that means the verifier 
> has to undo the conversion before computing the hashes, and it has to do that 
> bytewise precisely as well as reconstructing the original MIME header fields. 
>  
> Getting that even a byte off (modulo "relaxed") means you're toast.

The idea was to only do it for certain situations, i.e. when converted 
to base64.  Since a unbase64 function is already in your DKIM 
repertoire, no extra library is require and it would be one additional 
conditional statement.

> At that point I suspect you may as well bite the bullet and start down the 
> road of defining a new canonicalization that accommodates possible 
> downgrades in transit, picking either 7-bit or 8-bit as the canonical form, 
> and feeding that form to the hash to be used in signature generation.  But 
> once you consider that a multipart can have some 7-bit and some 8-bit, this 
> can get real messy real fast.

+1 (on the last sentence)

How would 7/8 bit be considered?

Personally, the STRIP C14N idea would work just fine by removing all 
trailing WSP (CR, LF, SP) and for QP text, decode it first.  I'm 
considering updating my 2006 I-D to include the QP decoding logic.

This, along with the et= idea, it would address at least three 
additional cases I have encountered.

- MLM that add an extra line at the top (possibly because of any 
empty
  header file of size 2, crlf)
- Intermediaries that expand QP to 8 bit
- Intermediaries that reformat to BASE64

I personally have not seen anything else.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com


___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html