Re: [ietf-dkim] 8bit downgrades

2011-05-22 Thread Hector Santos 
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] Certifying the DKIM public key?

2011-05-22 Thread Hector Santos 
John R. Levine wrote:
>> But this is exactly what DKIM is. You prove yourself fsvo "prove"
>> to the registrar who "certifies" you by virtue of placing your NS
>> records in the root servers instead of issuing a cert.
> 
> Registrars, as we all know, rarely check any credential beyond the 
> confirmation code from the credit card charge.  

h,  doesn't that depend on the cert being purchased?  There is a 
higher due diligence done for the more expensive "seal" which comes 
with a higher indemnity.  AFAIK, depending on your PCI level, you 
can't get the "el cheapo" cert like the Turbo SSL offered by GoDaddy 
because auditors will fail you.

> I'm still not seeing what a cert provides that couldn't be handled by VBR 
> or another DKIM signature by the certifier.

+1, I think VBR can address the "wildcard" signer which may not be 
desirable (by the receiver and by an 3rd party authority).   But I 
think you answered this in your RFC security session:

The receiver of a message with a VBR-Info header field MUST ignore
certifiers that it does not trust; otherwise, a bad actor could just
add an authority that it has set up so that it can vouch for itself.

No matter what, like everything else, there needs to be a "White List" 
of VBRs that is either defined locally or via a centralized source.

The problem, unlike the browser market, is that SMTP vendors do not 
have a common source to do this and even then, they may only want to 
do this for selected VBR records, Author Domains and signers.

-- 
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] Last Call: (DKIM And Mailing Lists) to BCP

2011-05-22 Thread ned+dkim 
> >   2. Should this be Informational or BCP?
> >  a: BCP, making it clear when we're insufficiently certain about 
> > something.
> > Last Call will sort out any objections.

> Well, I couldn't afford to go, so I can't say you're wrong, and I don't
> know why I didn't see that on the list.

> I guess on procedural grounds, you win, even though we all know that
> there's nothing B or C about this document.

I cannot comment on the process issues, but I'm afraid I have to agree with
John's technical assessment of this document.

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

Re: [ietf-dkim] New canonicalizations

2011-05-22 Thread Hector Santos 
Alessandro Vesely wrote:
> On 19/May/11 05:17, John Levine wrote:
>> And anyway, if your goal is for your message to survive, you should
>> armor it better, not come up with more arcane ways to declare that
>> it may be bleeding heavily but it's not dead yet.
> 
> Interesting, but not less intricate.  The semantics of authenticating
> only the armored part of a message is not obvious.  Resorting to
> base64 encoding is subject to varying interpretations, including
> spammers attempts to avoid naive content filtering.

+1.

What has made all this very difficult is trying to make a technology 
fundamentally based on authenticating integrity (DKIM) work with a 
natural breaking "Message Massager" (Mailing List) and as a result we 
have lowered its overall efficacy to an near absolute indeterminate 
state of conditions.  Even if the conversion is not required, you just 
don't know if BASE64 MIME is done by the signer and/or mailing list.

Case in point. Right now, I am looking at a gmail.com which I am 
pretty sure was not in Base64 MIME.  However, it was submitted to IETF 
DISCUSS group and its showing up as base64 MIME.  I don't know if the 
list did it one of the hops before the DKIM-Signature.

But the body hash failed.  So I took the message, made a copy and 
unbased64 the body, pulled the list footer and poof! - the body hash 
was ok again.

It would of been nice to have some DKIM-Signature flag that might 
indicate the Content-Transfer-Encoding, i.e.:

et="base64"   <--- copy of the top level Content-Transfer-Encoding

then at least the verify will know the encoding type of original body. 
If et= value does not match the current Content-Transfer-Encoding, 
then it has some smarts do a unbase64 before hash verification.

Of course, it still would of failed due to the list footer so, but if 
l= was used, there is some avenue for success.

The main realization is that Sender/Signers need to be more aware of 
the target/path if they desire a higher rate of return.

-- 
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] Certifying the DKIM public key?

2011-05-22 Thread J.D. Falk 
On May 22, 2011, at 12:27 PM, John R. Levine wrote:

> It occurs to me that since mail certification is likely to make assertions 
> about behavior as well as identity, the SSL model in which certs last for 
> a year won't work, since behavior can change rapidly.  Either the 
> certifier has to issue a stream of short-term certs to everyone it 
> certifies, or the verifiers have to check CRLs, which is tedious.  By the 
> time you do all that, a DNS check, even one with DNSSEC, looks pretty 
> attractive.

That's how it works at the IP level today.

--
J.D. Falk
the leading purveyor of industry counter-rhetoric solutions

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

Re: [ietf-dkim] 8bit downgrades

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

> Hector Santos followed up Crocker'ss passing of the buck:
>>
>> Please refrain from passing the buck to the WG. The document editors
>> are:
>>
>> D. Crocker (editor)
>> Tony Hansen (editor)
>> M. Kucherawy (editor)
>>
>> If the WG was technically incapable as you are implying, then the
>> *onus* was on the editors to make sure it was writing correctly.
> 
> Given that it's been pointed out the use of SHOULD in this case
> is entirely appropriate, I'm happy to accept blame on behalf of 
> the other authors for getting it right.

With all due respect, for the record, actually it was the original 
editors/authors:

  E. Allman
  J. Callas
  M. Delany
  M. Libbey
  J. Fenton
  M. Thomas

with the April 2006 draft-ietf-dkim-base-00 original text.  Updated in 
August 2006 base-05 draft update to clarify the 2nd paragraph in 
particular regarding Unix (LF) vs DOS (CRLF) translation requirements, 
and it (correctly) has remained that way since then.   This 
unfortunate issue is with new editors trying to change it and then 
labeling the WG for not understanding RFC2119 as a reason.

-- 
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] 8bit downgrades

2011-05-22 Thread Murray S. Kucherawy 
> -Original Message-
> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
> On Behalf Of Hector Santos
> Sent: Sunday, May 22, 2011 10:43 AM
> To: ietf-dkim@mipassoc.org
> Subject: Re: [ietf-dkim] 8bit downgrades
> 
> Please refrain from passing the buck to the WG. The document editors
> are:
> 
> D. Crocker (editor)
> Tony Hansen (editor)
> M. Kucherawy (editor)
> 
> If the WG was technically incapable as you are implying, then the
> *onus* was on the editors to make sure it was writing it correctly.

Given that it's been pointed out the use of SHOULD in this case is entirely 
appropriate, I'm happy to accept blame on behalf of the other authors for 
getting it right.


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

Re: [ietf-dkim] 8bit downgrades

2011-05-22 Thread Hector Santos 
Michael Deutschmann wrote:
> On Thu, 19 May 2011, Murray S. Kucherawy wrote:
>> The presented argument, which comes from an IETF outsider involved with
>> MTA development, is whether or not that SHOULD is worthy of a MUST because
>> failing to do it in the vast majority of cases will result in a downgrade
>> somewhere on the path that will invalidate the signature.  The question,
>> then, is why we didn't do MUST in the first place.  It's a perfectly
>> legitimate question.
> 
> One suggestion for compromise, from another "outsider" (myself):
> 
> Specify MUST, but clarify that this is just for now and may be revisited
> at a later time -- for example, if the SMTP protcol design community ever
> backs down and accepts DJB's approach to the 8-bit message problem
> (, essentially that it is OK to break
> any remaining 7-bit enforcing servers).  They probably won't ever, but
> just in case...

-1

The only reason for a MUST would be to enforce a change in software 
and to move it in into a positive direction.   In situations where 
this is known to create interoperability problems, you can only do 
this MUST if there is a technical fallback mechanism.

Case in point: For SMTP, HELO vs EHLO (extended HELO)

By RFC2119, EHLO should of been written as a SHOULD, but we wanted the 
market to move towards Extended SMTP operations and since SMTP was 
built with a

"500 COMMAND NOT UNDERSTOOD"

the SMTP state machine was still capable of falling back to a standard 
SMTP operation using the HELO command.  In other words:

  -  Client MUST always been with EHLO
  -  Client MUST always fallback to HELO if EHLO is not supported by 
server.

The issue with 8bit downloads is that DKIM does not have that fallback 
client/server state machine capability.

So if you make this a MUST, then you MUST have a fallback. If you make 
this (keep it as) a SHOULD, then you SHOULD have a fallback.

At the end of the day, you have to look at the realities there exist 
non-8BITMIME ready systems, so you won't get the conversions DKIM is 
looking for.  The better DKIM spec language would of been one related 
to "DKIM Input Validation Contracts."

http://www.google.com/search?q=Validation+Contracts

IOW, input requirements would be isolated to DKIM itself:

DKIM signing components SHOULD|MUST have 8bit downgrading. The idea
of whether MSA/MTA perform this conversion is OUT OF SCOPE.

SHOULD is my preference.  MUST is selected if that is what we want the 
DKIM MARKET to move to, but it MUST always have a fallback.

What will happen Michael if this is may a MUST is that systems will 
look for the fallback or skipping:

if mail is 8bit then SKIP signing mail

but it could be done with downlink target/path knowledge:

if mail is 8bit then
   if target path does destroy 8bit then convert
   sign mail

While that may be a functional description of a fallback, we don't 
have the automated technical capability to define it reliably.

-- 
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] Certifying the DKIM public key?

2011-05-22 Thread John R. Levine 
> But this is exactly what DKIM is. You prove yourself fsvo "prove"
> to the registrar who "certifies" you by virtue of placing your NS
> records in the root servers instead of issuing a cert.

Registrars, as we all know, rarely check any credential beyond the 
confirmation code from the credit card charge.  The thought here is to 
provide assertions more relevant to managing e-mail.

I'm still not seeing what a cert provides that couldn't be handled by VBR 
or another DKIM signature by the certifier.

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] Certifying the DKIM public key?

2011-05-22 Thread Michael Thomas 
On 05/22/2011 10:27 AM, John R. Levine wrote:
> It occurs to me that since mail certification is likely to make assertions
> about behavior as well as identity, the SSL model in which certs last for
> a year won't work, since behavior can change rapidly.  Either the
> certifier has to issue a stream of short-term certs to everyone it
> certifies, or the verifiers have to check CRLs, which is tedious.  By the
> time you do all that, a DNS check, even one with DNSSEC, looks pretty
> attractive.
>
>

But this is exactly what DKIM is. You prove yourself fsvo "prove"
to the registrar who "certifies" you by virtue of placing your NS
records in the root servers instead of issuing a cert. Nothing
different in *essence* to x.509 certs. The "advantage" that
x.509-style certs have is that you can verify them offline. Except
when you factor in CRL's which in any reasonable scheme you
must do. So yes, DKIM saves quite a bit of overhead by not
caring about the problematic offline verification problem.

There's really not a need of yet another certifier that I can see:
if your DNS is compromised, you have far, far larger problems than
DKIM.

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

Re: [ietf-dkim] Certifying the DKIM public key?

2011-05-22 Thread John R. Levine 
> VBR queries are about an actor, not a message.
>
> Certs can be coupled to a particular message -- this was an interesting 
> semantic distinction about Goodmail's certification scheme -- although I 
> believe that typically they, too, are only scoped to the actor, not the 
> specific content.

Now I'm really confused.  If the third party knows enough about each 
message to decide whether to provide the cert, why don't they just add 
their own DKIM signature?

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] 8bit downgrades

2011-05-22 Thread Hector Santos 
Dave CROCKER wrote:

>> On 5/19/2011 2:53 PM, Pete Resnick wrote:
>>> In RFC 2119 (the document that defines MUST, SHOULD, etc.), "MUST" does not 
>>> mean
>>> "vitally important" and "SHOULD" does not mean "really really important, but
>>> less important than MUST". "MUST" means "you have to do this or you're not 
>>> going
>>> to interoperate." "SHOULD" means, "there are ways to not do this which will
>>> still interoperate, but you had better know what those ways are and you 
>>> better
>>> be sure to do them, and if you don't, then you MUST NOT do this." That is,
>>> "SHOULD" is equivalent to "MUST unless you know exactly what you are doing."
> 
> Correct, of course, and nicely said.

Quite clear from what it actually says:

   3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
  may exist valid reasons in particular circumstances to ignore a
  particular item, but the full implications must be understood and
  carefully weighed before choosing a different course.

> This confusion about the meaning of normative language is one of the useful 
> touchstones to some of the problems that have plagued the DKIM working group.
>
> Among folks who haven't read the relevant bit of RFC 2119, the confusion 
> isn't 
> surprising.  However one would think that anyone with extended participation 
> in 
> a working group would do the homework of learning the basics of essential 
> specification vocabulary, such as the meaning of normative language or at 
> least 
> the difference between relaying and forwarding.
> 
> The fact that erroneous definitions persist among among some who actually 
> have 
> read RFC 2119 suggests possible issues with reading comprehension, since the 
> RFC 
> language about this is rather simple, direct and clear.

Please refrain from passing the buck to the WG. The document editors are:

D. Crocker (editor)
Tony Hansen (editor)
M. Kucherawy (editor)

If the WG was technically incapable as you are implying, then the 
*onus* was on the editors to make sure it was writing it correctly.

The problem in the WG was key cogs not following the charter, 
introducing deliberate out of scope concepts, mixing up the functional 
requirements with the technical specifications, doing global word 
replacements and not seeing if it was correct, removing/adding 
semantics and not seeing it fit the functional goals, confusing 
synergism with past or concurrent document productions, lost of WG 
interest participation with a resultant Consensus by Osmosis process, 
and frankly, all of which, all reflected a mark of poor leadership.

In this case (8BIT Downgrades), it is my view the SHOULD language is 
fine and was quite fitting the understood technical feasibility realities.


-- 
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] Certifying the DKIM public key?

2011-05-22 Thread Dave CROCKER 


On 5/22/2011 10:27 AM, John R. Levine wrote:
>>> through a separate, value-added mechanism. My own preference would be for 
>>> using
>>> a special header-field that contains the cert, with the specification of 
>>> using
>>> such certs as saying that they are enabled when included in the set of h=
>>> covered header fields.
>
> I don't see how this is functionally different from VBR. In both cases the
> signer assserts that the message is certified by foo.

Sorry, no.

VBR queries are about an actor, not a message.

Certs can be coupled to a particular message -- this was an interesting 
semantic 
distinction about Goodmail's certification scheme -- although I believe that 
typically they, too, are only scoped to the actor, not the specific content.

Mechanically, there are useful distinctions between in-band carriage of 
third-party information -- that is, carried with the message -- versus 
independent query, such as to the DNS.  The distinctions variously can entail 
benefits, costs or limitations.


> It occurs to me that since mail certification is likely to make assertions 
> about
> behavior as well as identity, the SSL model in which certs last for a year 
> won't

I believe most certification work is actually about behavior, except when the 
identity-related certification couples one identifier to another (or, my 
familiarly, one identifier to an identity.)


d/

ps.  none of this has anything to do with the current DKIM wg tasks, of 
course...
-- 

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

Re: [ietf-dkim] Certifying the DKIM public key?

2011-05-22 Thread John R. Levine 
>> through a separate, value-added mechanism.  My own preference would be for 
>> using
>> a special header-field that contains the cert, with the specification of 
>> using
>> such certs as saying that they are enabled when included in the set of h=
>> covered header fields.

I don't see how this is functionally different from VBR.  In both cases 
the signer assserts that the message is certified by foo.  If the 
recipient finds foo to be credible, it checks to see if foo really did 
certify the signer, by a DNS lookup for VBR, or I suppose by checking the 
offered cert to see if the signature is valid, and if the contents include 
the signer's domain and an expiration date in the future.

It occurs to me that since mail certification is likely to make assertions 
about behavior as well as identity, the SSL model in which certs last for 
a year won't work, since behavior can change rapidly.  Either the 
certifier has to issue a stream of short-term certs to everyone it 
certifies, or the verifiers have to check CRLs, which is tedious.  By the 
time you do all that, a DNS check, even one with DNSSEC, looks pretty 
attractive.

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] Certifying the DKIM public key?

2011-05-22 Thread Michael Thomas 
On 05/22/2011 08:02 AM, Dave CROCKER wrote:
>
> 3. As noted, certification was explicitly de-coupled from DKIM.  I'll claim 
> that
> it really is a separate, value-added service and any support of it should be
> through a separate, value-added mechanism.  My own preference would be for 
> using
> a special header-field that contains the cert, with the specification of using
> such certs as saying that they are enabled when included in the set of h=
> covered header fields.
>

Well, x.509 style certification certainly was. But using DNS is a
form of certification which is arguably not much worse than going
to godaddy and proving that you can receive email from the domain
or whatever weak tests they use to establish that you have control
of the domain. The weak part of DKIM/DNS chain isn't the certification
part (if you believe that godaddy et al aren't problematic), it's the
lack of data integrity in the transport of the dkim rr. Which can
be solved with DNSSEC.

Given how problematic x509 has been for people to get their heads
around, I think that DKIM has done a service in providing an
alternative mechanism/trust root for establishing identity
that is workable and especially with its solution to the revocation
problem.

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

Re: [ietf-dkim] Certifying the DKIM public key?

2011-05-22 Thread Dave CROCKER 


On 5/19/2011 3:17 PM, Murray S. Kucherawy wrote:
>> -Original Message- From: ietf-dkim-boun...@mipassoc.org
>> [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Rolf E. Sonneveld
...
>> recently someone asked me whether it would have any added value if the DKIM
>> public key, which is stored in DNS, would be 'certified' in some (yet to be
>> determined) way by a 3rd party like VeriSign, Thawte etc.?
...
> The use of plain RSA keys without requiring a third-party certification was a
> specific design criterion for DKIM.  You could change to using some kind of
> certificate that is signed by someone else, but you'd need a new key type and
> corresponding signing algorithm(s) that evaluate the more complex keys and
> then tie them to whatever your trusted certifiers list is, and would probably
> pretty much mandate TCP for DNS.
>
> It seems to me this is a bullseye for what VBR is capable of providing.


1. There are important differences between 'claims' -- certified or not -- and 
reputation.  Claims are provided by the claimant.  Reputation is provided by 
third-parties.  Certs are specific to the claims.  Reputation can be about 
anything.  And so on.  These really are not equivalent mechanisms, IMO.

2. It might be reasonable to enhance DKIM to support multiple claims.  As of 
now, DKIM has only one:  The signer claims to take /some/ responsibility for 
the 
message.  (DOSETA now supports multiple claims.)

3. As noted, certification was explicitly de-coupled from DKIM.  I'll claim 
that 
it really is a separate, value-added service and any support of it should be 
through a separate, value-added mechanism.  My own preference would be for 
using 
a special header-field that contains the cert, with the specification of using 
such certs as saying that they are enabled when included in the set of h= 
covered header fields.

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] EAI and 8bit downgrades

2011-05-22 Thread Douglas Otis 
On 5/22/11 10:38 PM, John R. Levine wrote:
>> Specify MUST, but clarify that this is just for now and may be revisited
>> at a later time -- for example, if the SMTP protcol design community ever
>> backs down and accepts DJB's approach to the 8-bit message problem
>> (, essentially that it is OK to break
>> any remaining 7-bit enforcing servers).  They probably won't ever, but
>> just in case...
> If you were following the EAI work, you'd know that they probably will do
> that within the next couple of months, albeit with an SMTP flag so servers
> and clients can tell whether a hop is 8-bit UTF or legacy.  They
> specifically do NOT provide any downgrade mechanism -- if a path isn't EAI
> from end to end, the message can't be delivered.  (Please read the many
> years of archives of the EAI list, in which they tried every imaginable
> approach via many experimental RFCs and a lot of running code, before
> commenting on the wisdom of this approach.)
>
> I beseech this group to refrain from hypothetiecal guesses about what some
> of us might think would be a good idea to address some anticipated
> problem, even though nobody has tried it. It was a mistake in the mailing
> list so-called BCP, and it would be a mistake here.
>
> There will be DKIM signatures on EAI messages.  It is pretty obvious how
> to do it, and in the few corners where it's not obvious, we won't know the
> right answer any better than anyone else until we've tried it and seen
> what happens.
Agreed.

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

Re: [ietf-dkim] New canonicalizations

2011-05-22 Thread John R. Levine 

Interesting, but not less intricate.  The semantics of authenticating
only the armored part of a message is not obvious.  Resorting to
base64 encoding is subject to varying interpretations, including
spammers attempts to avoid naive content filtering.


S/MIME and PGP MIME have been doing just that, authenticating just an
armored MIME body, for close to 20 years.  Your MUA probably has
support for S/MIME built in.  This is a wheel we do not need to
reinvent.

R's,
John

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-22 Thread Dave CROCKER 


On 5/19/2011 10:50 AM, Murray S. Kucherawy wrote:
> Can anyone remember why there’s a SHOULD for the downgrade to 7-bit in RFC4871
> Section 5.3, rather than a MUST?

To concur with one of the lines of explanation that has been offered:

  It is generally a good idea to refrain from mandating something that adds 
cost without benefit.  The recommendation is for a bit of additional processing 
-- the conversion -- that is not /always/ necessary, because downgrading does 
not always happen.

  If the signer has no knowledge of the path that the message will travel 
-- 
as, indeed, is /currently/ true for nearly all signers -- then they have to use 
the safest choice, namely performing the conversion, to increase the 
survivability of the signature, in case the path does happen to mess with the 
data in the way being discussed.

There are existing scenarios in which the signer well might know that the extra 
processing is /not/ required, such as for internal mail.  This might not be 
common, but it is legitimate.  The same applies for the emergence of 
8-bit-clean 
environments, as has been mentioned.

The concept that there will at least be islands of 8-bit clean is not all that 
silly and has been driving the latest round of EAI work.  That sort of concept 
certainly does tend to be viewed more optimistically by proponents than history 
would advise, but there are reasonable indicators to suggest that it's not an 
entirely silly idea with respect to MIME and email transit.  So, again, for 
such 
environments, the extra protection of the processing specified as SHOULD would 
be wasteful. This is why SHOULD is the correct choice and MUST is not.



> On 5/19/2011 2:53 PM, Pete Resnick wrote:
>> In RFC 2119 (the document that defines MUST, SHOULD, etc.), "MUST" does not 
>> mean
>> "vitally important" and "SHOULD" does not mean "really really important, but
>> less important than MUST". "MUST" means "you have to do this or you're not 
>> going
>> to interoperate." "SHOULD" means, "there are ways to not do this which will
>> still interoperate, but you had better know what those ways are and you 
>> better
>> be sure to do them, and if you don't, then you MUST NOT do this." That is,
>> "SHOULD" is equivalent to "MUST unless you know exactly what you are doing."

Correct, of course, and nicely said.

This confusion about the meaning of normative language is one of the useful 
touchstones to some of the problems that have plagued the DKIM working group.

Among folks who haven't read the relevant bit of RFC 2119, the confusion isn't 
surprising.  However one would think that anyone with extended participation in 
a working group would do the homework of learning the basics of essential 
specification vocabulary, such as the meaning of normative language or at least 
the difference between relaying and forwarding.

The fact that erroneous definitions persist among among some who actually have 
read RFC 2119 suggests possible issues with reading comprehension, since the 
RFC 
language about this is rather simple, direct and clear.



On 5/19/2011 7:20 PM, John Levine wrote:
 > I think Pete's analysis is correct, but my advice would be to take
 > it out altogether.  We don't have any great insight into the warts
 > of what paths are likely to downcode a message and what paths aren't,
 > so I would prefer not to purport to offer advice about it.

The SHOULD being discussed actually represents an important bit of responsible 
specification writing.  It MUST be retained.

First, it is necessary for the reason I described above:  It specifies 
something 
that adds cost, but there are legitimate scenarios that do not need it AND 
there 
is reason to believe the need will reduce over time.  If the signer knows it is 
not needed, then it is entirely wasteful to do the processing.

Second, a protocol specification SHOULD help the reader understand something of 
the usage dynamics of a protocol.  What are some of the interesting scenarios 
that can cause problems and what is the way to deal with them?  If a scenario 
has sufficiently severe effects and is plausibly going to happen, then the 
method of dealing with the situation is best specified normatively.

It is generally not a good idea to leave a protocol implementer guessing what 
situations to worry about and guessing about how to deal with them.



> On 5/22/2011 1:39 AM, Michael Deutschmann wrote:
>> One suggestion for compromise, from another "outsider" (myself):

While it's always good to see efforts at compromise, in this case, there is no 
need:  The current language fits the current situation nicely..


>> Specify MUST, but clarify that this is just for now and may be revisited
>> at a later time

This would miss the fact that there are existing scenarios that do not require 
the extra mechanism and there are already efforts ongoing that will make is 
/less/ useful.  To gain extremely widespread deployment, those efforts will 
need 
a very long time, o

Re: [ietf-dkim] EAI and 8bit downgrades

2011-05-22 Thread John R. Levine 
> Specify MUST, but clarify that this is just for now and may be revisited
> at a later time -- for example, if the SMTP protcol design community ever
> backs down and accepts DJB's approach to the 8-bit message problem
> (, essentially that it is OK to break
> any remaining 7-bit enforcing servers).  They probably won't ever, but
> just in case...

If you were following the EAI work, you'd know that they probably will do 
that within the next couple of months, albeit with an SMTP flag so servers 
and clients can tell whether a hop is 8-bit UTF or legacy.  They 
specifically do NOT provide any downgrade mechanism -- if a path isn't EAI 
from end to end, the message can't be delivered.  (Please read the many 
years of archives of the EAI list, in which they tried every imaginable 
approach via many experimental RFCs and a lot of running code, before 
commenting on the wisdom of this approach.)

I beseech this group to refrain from hypothetiecal guesses about what some 
of us might think would be a good idea to address some anticipated 
problem, even though nobody has tried it. It was a mistake in the mailing 
list so-called BCP, and it would be a mistake here.

There will be DKIM signatures on EAI messages.  It is pretty obvious how 
to do it, and in the few corners where it's not obvious, we won't know the 
right answer any better than anyone else until we've tried it and seen 
what happens.

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-22 Thread Alessandro Vesely 
On 19/May/11 05:17, John Levine wrote:
> The point I was making was that ever more complex ways to decide that
> two mutated versions of a message are "the same" aren't likely to help
> much, certainly not compared to the large cost of implementing code
> even more complex than what relaxed does now.

Just to mention two of those ways, MIME rewriting is a capability
mayor MTAs introduced when MIME took root, HTML styles mangling is an
ongoing MUA exercise.

> And anyway, if your goal is for your message to survive, you should
> armor it better, not come up with more arcane ways to declare that
> it may be bleeding heavily but it's not dead yet.

Interesting, but not less intricate.  The semantics of authenticating
only the armored part of a message is not obvious.  Resorting to
base64 encoding is subject to varying interpretations, including
spammers attempts to avoid naive content filtering.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] 8bit downgrades

2011-05-22 Thread Michael Deutschmann 
On Thu, 19 May 2011, Murray S. Kucherawy wrote:
> The presented argument, which comes from an IETF outsider involved with
> MTA development, is whether or not that SHOULD is worthy of a MUST because
> failing to do it in the vast majority of cases will result in a downgrade
> somewhere on the path that will invalidate the signature.  The question,
> then, is why we didn't do MUST in the first place.  It's a perfectly
> legitimate question.

One suggestion for compromise, from another "outsider" (myself):

Specify MUST, but clarify that this is just for now and may be revisited
at a later time -- for example, if the SMTP protcol design community ever
backs down and accepts DJB's approach to the 8-bit message problem
(, essentially that it is OK to break
any remaining 7-bit enforcing servers).  They probably won't ever, but
just in case...

So then there would be also a MUST that *incoming* 8-bit DKIM-signed
messages be processed in the obvious way.  This would never be used in
the present, but allow future protocol designers some leeway.

By the way, note that DKIM is not alone in this. S/MIME (RFC 1847) says,
on page [4]:
# In addition, if the multipart/signed object is EVER to be
# transferred over the standard Internet SMTP infrastructure, the
# resulting MIME body is constrained to 7 bits -- that is, the use
# of material requiring either 8bit or binary
# content-transfer-encoding is NOT allowed.  Such 8bit or binary
# material MUST be encoded using either the quoted-printable or
# base64 encodings.

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