[ietf-dkim] feature tags

[John R. Levine]

Just for fun I sent in a new I-D of the dkim-conditional draft that takes 
out version numbers and adds feature tags in a backward compatible way.


https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] features and versions and running code

[John R. Levine]

 The current point of departure into DKIM is by the header field name. So I'm
 not sure why 'other than' is being queried, since it's the natural, existing
 point for going to a different protocol.


Hmmn.  Yesterday someone seemed to agree that keeping the same header name 
would make life easier for all the code that looks for a DKIM-Signature header 
to decide whether to call the DKIM library, since in any sensible scenario the 
old and new DKIM headers are handled by one library with a single verification 
interface.  Has he changed his mind?


R's,
John

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

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

[John R. Levine]

MIME was in significant use quite a bit before ESMTP was operational. In fact 
it's a non-trivial feature that MIME only requires adoption by author and 
recipient and not by /any/ of the infrastructure.  IE, not by SMTP.


Yes, I know, but I wish you'd read what I've said about 8BITMIME.  It's 
an overlay that makes an INCOMPATIBLE CHANGE TO THE MESSAGE FORMAT, which 
is a version change in any world I know.


Ditto EAI.

The SMTP extensions to support MIME characteristics are value-added, beyond 
the basic MIME capability.  In other words, they aren't necessary.


Well, sure, neither is DKIM, you could authenticate your mail some other 
way.  I don't understand what point you're making here.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

Sorry.  Where is the version number for SMTP?


MAIL FROM:<Борис@пример.ru> SMTPUTF8<--


These are not 'version' flags.  They are feature indicators.


They're both.  If you use the feature, you're using the new version of the 
message.


R's,
John___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

[John R Levine]

Well, that's simply and completely false.

The message format specification(s) have no dependency on the email transport 
mechanism.


Huh.  When I look at RFC 822, section 3.1 says:

 The  body  is simply a sequence of lines containing ASCII charac-
 ters.  It is separated from the headers by a null line  (i.e.,  a
 line with nothing preceding the CRLF).

If a message uses 8BITMIME, there are characters in the body that are
not ASCII.  It does not conform to RFC 822, it's a different format.
If you feed an 8BITMIME message to an RFC 822 mail system, random bad
things can happen, particularly back on PDP-10s where we stored five
7-bit characters in 36 bit words.

By the time we get to RFC 5322, there is a paragraph of waffle in
section 2.1 that says that non-ASCII stuff is described somewhere else
and "Discussion of those mechanisms is not within the scope of this
specification."  I suppose we can have a metaphysical argument about
what you call something that exists but we pretend for now that it
doesn't.

EAI adds another level of version, by redefining the address syntax so
domains can be U-labels, local parts can be any UTF-8, and most places
in mail headers that can contain text can be UTF-8.  Again, if you
feed one of these to a 5322 mail parser, even an 8BITMIME parser, it
won't work.  It's a new version of the message format.

In both cases the new versions are backward compatible with the old
versions, but so what?  They're not forward compatible, you need some
sort of version flag to avoid feeding new messages to old parsers.

Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

In article <20180209202621.31355.qm...@f3-external.bushwire.net>,
Mark Delany  wrote:

Oh I dunno. The precedent of RFC822 - the very standard we rely on - has
survived numerous upgraded and enhancements over a 36 year period and managed
to do just fine without a version.


RFC 822 may not have versions but 821/2821/5321 sure do.

As soon as 2821 added EHLO, SMTP got service extensions and pretty
much by their nature, those extensions are not backward compatible.

Well-known examples are 8BITMIME and SMTPUTF8.  If you have a message that needs
one of those and the server you're trying to send it to doesn't support the
extension, you lose, the message bounces.  (A sending host might try to rewrite
MIME bodies to avoid 8BITMIME but it's a long time since I've seen anyone try
that, and it'd break DKIM signatures, so it probably wouldn't help.)

Nonetheless, we seem to have survived.

The DKIM v=2 hack I proposed is a lot like SMTP extensions in that if
your signature doesn't need the new semantics, don't ask for them, so
you should sign with v=1, so the old and new will coexist forever.
Since they can easily be handled by the same signing and verifying
libraries, that's not a problem.
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly


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

Re: [ietf-dkim] DKIM and EAI

[John R. Levine]

If I may once again change the topic for a moment ...



https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/


I pushed out a new version that says something about SPF macros, 
attempting to say that if you try to expand a UTF-8 local part, it doesn't 
match anything.  I figure this is consistent with what would happen if 
your local part was something like foo..bar which won't match anything 
either.


I would appreciate if people would take a look and see if anything seems 
obviously wrong.  I'm doing some EAI whitepapery things for ICANN and it 
would be nice if, for a change, the advice they offer matches reality.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [Editorial Errata Reported] RFC6376 (5260)

[John R. Levine]

 NEW

   Header fields are lines beginning with a field name, followed by a
   colon (":"), followed by a field body, and terminated by CRLF.  A
   field name MUST be composed of printable US-ASCII characters (i.e.,
   characters that have values between 33 and 126, inclusive), except
   colon.  In all cases, field names are interpreted as case-insensitive
   strings, so that, for example, "Subject", "SUBJECT", and "SuBjEcT"
   are considered to be the same field name.


Seems reasonable.  While we're picking nits, RFC 3864 says you can't register a 
field with a dot in it, might be worth a mention.


Also, according to the spec, #)*%;' is a valid field name, although I observe 
that every name in the field name registries is LDH.  Would it be worth a note 
saying that LDH names are likely to interoperate better?


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

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

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

The code that knows to dispatch to v=2 can, just as easily, parse for the 
strings associated with the new features.


True, but not very interesting.  In my spamassassin example, the outside 
code knows nothing about DKIM versions, it just sees a dkim-signature 
header and sends it to the DKIM library.


The point of a v=2 flag is to ensure that old v=1 code doesn't 
accidentally misinterpret new features.  In my example, I made a semantic 
change: in v=1 DKIM, verifiers ignore tags they don't understand.  In v=2, 
there's a new tag type that fails if a verifier can't handle it.  The new 
tags have new syntax that, in an ideal world, would make v=1 verifiers 
fail with a syntax error, but we all know that parse errors are often not 
well debugged.  I did look at a bunch of DKIM libraries and they all check 
for v=1 and fail if they don't find it.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

 the DKIM library.  If it passes a v=2 signature to a library that only
 knows about v=1, the library will say it's invalid, which isn't ideal but
 isn't wrong.


the code that tests for the v= parameter could, just as easily, check for the 
presence of the new features.


Huh?  v=1 code doesn't know what the new features would be.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

They seek to distinguish important differences in processing for what is 
claimed to be the /same/ protocol.


Except really they don't.


Except when they do.  I'm thinking, f'rinstance, that there is a bunch of 
code in things like Spamassassin that looks at headers and switches out to 
routines to do stuff with them.  There is nothing in Spamassassin that 
needs to care whether a DKIM signature is v=1 or v=2, that's all inside 
the DKIM library.  If it passes a v=2 signature to a library that only 
knows about v=1, the library will say it's invalid, which isn't ideal but 
isn't wrong.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

On Thu, 8 Feb 2018, Mark Delany wrote:

Heh. I'm still waiting to hear a good reason as to why "v=" exists at all - 
apart
from exposing brittle parsers which mistakenly expect it to show up as the first
tag.


I had a draft that invented v=2, for headers with a tag syntax that is not 
quite backward compatible with the current spec.  I realize that we could 
change the header to DKIM-Improved-Signature but the change was small and 
it smelled to me like the same header.


See https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[John R. Levine]

Header field name rules are in RFC 5322.  That deals with case sensitivity 
for field name strings.  Section 1.2.2 provides the basis for knowing whether 
a defined string is to be parsed in a case sensitive or insensitive manner.


That's right, and all of the fields defined in 5322 have case insensitive 
names, but as far as I can tell, I could define a header like this:


 pickle-header = %d80.111.99.107.108.101 ":" CFWS ( "dill" / "garlic" / 
"kimchee" )

So this is a pickle-header

 Pickle: dill

but this is not:

 pickle: garlic

I'm not saying any sensible person would do that, but as far as I can 
tell, that's what the spec says.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[John R. Levine]

"v=1" doesn't have to come first.  It just usually does.  I think there was
a version of RFC4871 that did that, but then when challenged we couldn't
come up with a good reason to keep it that way.


I wonder how many DKIM libraries will accept a signature where it doesn't.

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Where is the formal definition of DKIM-Signature?

[John R. Levine]

someone asked me about case sensitiveness of the header field name.  I looked
for an ABNF in RFC6376, but only found examples and informative notes.


I was going to say that can't possibly be true, but it's true, there's no 
ABNF for the header.  So, for example, I don't know whether the v= field 
has to come first.  Send an erratum, we'll probably accept it as hold for 
update.


By the way, all field names are case insensitive.  RFC 5322 doesn't say 
that explicitly, but the ABNF for the field names makes it pretty clear, 
On the other hand, RFC 5322 also says that field names can be any printing 
ASCII character so this is be a valid header.


$"%\)': plugh

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] DKIM and EAI

[John R. Levine]

If I may change the topic for a moment ...

I'm working on some stuff for ICANN to help people get EAI mail working. 
One of the underspecified bits of EAI is how authentication works with 
SPF, DKIM, DMARC and now, I suppose ARC.  There's a bunch of places where 
one needs to make arbitrary decisions about what's in ASCII (a-labels) or 
what's in UTF-8 (u-labels.)  I did a draft about it last year:


https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/

It would be nice if this could be finished and published, so I have 
something better than an expired draft to point at when people ask me how 
to do DKIM and SPF with their EAI mail.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailsploit

[John R. Levine]

From:
=?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?==?utf-8?Q?=00?==?utf-8?b?cG90dXNAd2hpdGVob3VzZS5nb3Y=?=@
mailsploit.com


I'm with Steve, this is overclever in a world where most MUAs just show 
you the From: comment.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[John R. Levine]

I'm with Murray -- why is this a problem?  Single recipient has been
the de-facto standard for years, and unless you are extremely
bandwidth constrained, it's faster.


No, it's not faster, see my answer to Murray. It's wasting a lot of 
ressources.


People who've measured say the elapsed time is faster, and the extra bytes 
on the wire don't matter.  This is an old argument, and not one you're 
going to win.


John, did you read my email? The whole text is about how the leakage of the 
BCCs can be prevented and the feature of a multi-recipient email be 
preserved. If you see an error in the algorithm, please explain.


See previous messages, particularly the ones from Ned Freed.  Any sort of 
multi-recipient signing is subject to guessing attacks.


This isn't saying that signing the recipient is a good idea, but signing 
them individually is no worse than signing them together and avoids the 
leakage.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[John R. Levine]

Also realize that this isn't "Gmail shouldn't sign spam", it's everyone who
normally has a good reputation needs to not sign spam, this is a way to
steal reputation from any service allowing you to choose your own message,
and can be used against any mail receiver.


Just wondering, roughly when would you use the no-forward flag?  I hope 
you wouldn't use it on everything, since that would make DMARC have far 
worse effects on legit mail than the current mailing list issues.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[John R. Levine]

The negative side of the proposal is the requirement to split all 
multi-recipient-emails to single-recipient-emails, which is a show stopper 
for me.


I'm with Murray -- why is this a problem?  Single recipient has been the 
de-facto standard for years, and unless you are extremely bandwidth 
constrained, it's faster.


 But I don't think this requirement is needed. I would allow a list of 

recipients and have a paragraph which states ...


See previous discussion.  We rejected multi-recipient signatures because 
of the bcc recipipient leakage.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [dmarc-ietf] a slightly less kludge alternative to draft-kucherawy-dmarc-rcpts

[John R. Levine]

Version 01 is purely incremental, meaning you can just ignore the new tags
if you're more worried about breakage of forwarding than the attack it's
trying to address.


Ah, I'd missed that you took out the magic hash goop.  If it's optional, 
it's still a bad idea, but it breaks a lot less stuff.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM Key Sizes

[John R. Levine]

It's also probably worth ensuring that the major open source DKIM
implementations support both signing and verifying with 4096-bit keys.
Aside from OpenDKIM and dkimpy, are there any others that should be checked?


Perl Mail::DKIM is still widely used.  It calls Crypt::OpenSSL::RSA which 
is a wrapper around openssl so I'd be surprised if it had trouble with 
large keys.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM and EAI

[John R. Levine]

In order to make EAI environment more friendly,  I suggest that this WG
considers to move this document/work forward.


Which working group?  DKIM hasn't existed in years.  We'd have to spin up
another one.


It's one fairly short and I hope uncontroversial draft, so I'd suggest 
running it through DISPATCH.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] DKIM and EAI

[John R. Levine]

On a bit of a side note, I wonder how much appetite there
is for a document update?  Besides this, we have no way to
include non-ASCII UTF-8 local parts in i=.


I wrote a draft about it, but I can't say it's gotten a lot of attention 
other than from Alexey:


https://datatracker.ietf.org/doc/draft-levine-appsarea-eaiauth/

Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4810)

[John R. Levine]

tl;dr: I agree with the change suggested


Yeah, if we were opening this up, the ABNF could be considerably 
clarified.  But since we're just patching, one line will have to do.


R's,
John


*) I agree with John that "/" and "=" do not need to be encoded because there’s 
no ambiguity if those were to be present.
*) I also agree with John that WS is already covered by the production.
*) But ":" DOES need to be encoded for sig-q-tag-method.
*) For sig-q-tag-method, "|" does NOT need to be encoded, but it doesn’t hurt 
if it is.

An alternate solution would have been to change the definition of qp-hdr-value to add 
":" to the list of encoded characters:

  qp-hdr-value = dkim-quoted-printable ; with "|" and ":" encoded

For that matter, dkim-quoted-printable is used in so few places, that it might 
be even better to just change the list of dkim-safe-char to not include any of 
these characters. So that is another alternate solution:

dkim-safe-char=  %x21-39 / %x3C / %x3E-7B / %x7D-7E
; '!' - '9', '<', '>' - '}', '}', '~'

But the least damage to the document and protocol seems to be to follow the 
suggestion as given.

Tony

On 9/27/16, 2:24 AM, "ietf-dkim on behalf of Stephen Farrell" 
<ietf-dkim-boun...@mipassoc.org on behalf of stephen.farr...@cs.tcd.ie> wrote:


   Thanks folks. I plan to accept this as-is later today
   unless someone proposes better text that gets a better
   reaction.

   S

   On 27/09/16 03:30, John R Levine wrote:
   > tl;dr the proposed correction does the right thing
   >
   >
   >>> Section: 3.5
   >>>
   >>> Original Text
   >>> -
   >>> x-sig-q-tag-args = qp-hdr-value
   >>>
   >>> Corrected Text
   >>> --
   >>> x-sig-q-tag-args = dkim-quoted-printable  ; with ":" encoded
   >
   >> ... Section 2.10 shows:
   >>
   >> qp-hdr-value=  dkim-quoted-printable; with "|" encoded
   >>
   >> so the suggested change doesn't seem to accomplish the stated goal,
   >> since the two rules are equivalent.
   >>
   >> Nor does dkim-safe-char get us there.
   >>
   >> I think the rule should exclude WSP, ":", "/" and "=", and I'm not
   >> seeing an existing one that gets us there.  Am I missing it?
   >
   > I also don't see any ABNF term that does the trick.  The
   > DKIM-signature is a tag-list which is a list of tag=value separated by
   > semicolons.  The q= tag in a signature is a list of query methods
   > separated by colons.  Each query method can either be a token or token
   > / args where the args is x-sig-q-tag-args.  In those args, you have to
   > quote a semicolon to avoid starting a new tag, you have to quote a
   > colon to avoid starting a new method, and quote whitespace which is
   > otherwise ignored.  A slash or equal sign isn't a problem since you
   > can't have multiple args per method or multiple values for a tag.
   >
   > The closest we have is dkim-quoted-printable which already requires
   > that you quote white space and semicolons, so I think the simplest
   > non-wrong change would be what Juan proposed, dkim-quoted-printable
   > with colons also encoded.
   >
   > R's,
   > John
   >
   > PS: For people who don't know him, Juan is the author of the widely
   > used Port25 MTA, so I expect he ran into this while writing its DKIM
   > parser.



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



Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] [Technical Errata Reported] RFC6376 (4810)

[John R Levine]

tl;dr the proposed correction does the right thing



Section: 3.5

Original Text
-
x-sig-q-tag-args = qp-hdr-value

Corrected Text
--
x-sig-q-tag-args = dkim-quoted-printable  ; with ":" encoded



... Section 2.10 shows:

qp-hdr-value=  dkim-quoted-printable; with "|" encoded

so the suggested change doesn't seem to accomplish the stated goal,
since the two rules are equivalent.

Nor does dkim-safe-char get us there.

I think the rule should exclude WSP, ":", "/" and "=", and I'm not
seeing an existing one that gets us there.  Am I missing it?


I also don't see any ABNF term that does the trick.  The
DKIM-signature is a tag-list which is a list of tag=value separated by
semicolons.  The q= tag in a signature is a list of query methods
separated by colons.  Each query method can either be a token or token
/ args where the args is x-sig-q-tag-args.  In those args, you have to
quote a semicolon to avoid starting a new tag, you have to quote a
colon to avoid starting a new method, and quote whitespace which is
otherwise ignored.  A slash or equal sign isn't a problem since you
can't have multiple args per method or multiple values for a tag.

The closest we have is dkim-quoted-printable which already requires
that you quote white space and semicolons, so I think the simplest
non-wrong change would be what Juan proposed, dkim-quoted-printable
with colons also encoded.

R's,
John

PS: For people who don't know him, Juan is the author of the widely
used Port25 MTA, so I expect he ran into this while writing its DKIM
parser.
___
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM Key Size Constraints

[John R. Levine]

 Apart from that I think we should start a (separate) effort to determine 
 where we go from here. For the most part 2048 length keys seem not to be 
 a problem in the wild at this time. On the other hand, given the speed 
 (or lack thereof) involved in working groups generating useful output, 
 if we start now (for some definition of now) we should (hopefully) have 
 a solution before 2048 keys are at risk.

The only problem I'm aware of is the 512 byte UDP DNS packet size.  Is 
anyone aware of actual stats on how often larger packets fail?

The IETF is not useful here.  The IETF DNS crowd swears that it's not a 
problem at all and anyone who believes otherwise is stupid.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] need for clarification on key size

[John R. Levine]

 Signer using a key larger then 2048 (like I do for years now) aren't 
 inside the specification because there is no MUST on the validation 
 side.

 From operational perspective I experience no drawback using 4k RSA
 keys for DKIM.

I'm not surprised that 4K keys work.  Most crypto software can handle 
abitrary key sizes.  The most likely issue would be that the TXT records 
don't fit in a 512 byte response packet which is a problem for some cruddy 
middleboxes.

Could you explain what problem you believe needs 4K rather than 2K keys? 
DKIM is not PGP or S/MIME and is not intended for long term protection of 
confidential data.  It's just a short term assurance that a particular 
message in transit was signed by a particular signer.

I rotate my keys every month, which appears to be the shortest DKIM 
rotation time in the world.  Most people do it every six months or a year.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] need for clarification on key size

[John R. Levine]

 The most likely issue would be that the TXT records don't fit in a 512 byte 
 response packet which is a problem for some cruddy middleboxes.

 that was exactly the reason I started using 4k keys. I wanted to make sure
 at least my infrastructure could handle DNS over TCP everywhere.

That's nice, but I don't see what that has to do with interoperating with 
the rest of the world whose DNS does what it does.

 Do you think, the DKIM specification should be more detailed on this pros and 
 cons?

No, the advice to use 2K keys will be reasonable for the forseeable 
future even for very infrequent rotation.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

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

[John R. Levine]

On Wed, 9 Jul 2014, Jiankang Yao wrote:
 Is there any RFC which deals with EAI DKIM ?
 how to deal with EAI message in the DKIM?
 Do we have a decision about it?

We had a small amount of discussion but I don't recall any conclusions.

Signing an EAI message should work the same as signing a non-EAI message. 
I suppose we might have conventions for things like whether the d= domain 
is a A-labels or U-labels, but those are pretty minor.

As Wietse noted, EAI no longer does any downgrading in transit, so that't 
not an issue.  Even if it did, DKIM decided long ago not to deal with it, 
and if people recoded, say, quoted-printable into base64, that would break 
the 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] Timeouts retrieving keys from ietf.org

[John R. Levine]

Sep  7 12:58:19 v2 opendkim[1019]: r87JwCmq008446: key retrieval failed
(s=ietf1, d=ietf.org): timeout DNS query for `ietf1._domainkey.ietf.org'


I did a little poking around and the problem appears to me that the IPv6 
address for ns0.ietf.org, 2001:1890:126c::1:2, doesn't work.  I tried it 
from a couple of places on different networks, no luck anywhere.


There appear to be v6 routing problems for some of the secondaries, too.

ns1.ams1.afilias-nst.info. is has IPv6 address 2a01:8840:7::1, and 
although I can query it via a v6 tunnel at HE, I can't see if from the 
native IPv6 on my T-W cable modem.  The T-W v6 is OK, since it queries

ns1.yyz1.afilias-nst.info 2a01:8840:9::1 without problems.

On the other hand, you might also file a bug report with whoever runs your 
local DNS server.  If a v6 query fails and a host has a v4 address, it 
really should try the v4 address next.


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] Timeouts retrieving keys from ietf.org

[John R. Levine]

Traceroutes confirm that it's dead, I sent a note to ietf-action.

On Sun, 15 Sep 2013, Jim Fenton wrote:

 Slightly off-topic for this list, but the dkim-ops mailing list seems to
 be dormant...

 I'm getting a fair number of DKIM key lookup failures from ietf.org.  I
 have run into this on two different mail servers with independent
 resolver configurations, so I'm inclined to think the problem is not on
 my end:

 Sep  7 12:58:19 v2 opendkim[1019]: r87JwCmq008446: key retrieval failed
 (s=ietf1, d=ietf.org): timeout DNS query for `ietf1._domainkey.ietf.org'

 If anyone else is seeing this, let me know and I'll report it.  My
 theory is that their DNS servers are struggling to respond to many key
 requests after sending out signed messages to large mailing lists. The
 TTL is 30 minutes, which may be too short.

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


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] IPR Disclosure: ENTERKHAN CO., LTD's Statement about IPR related to RFC 6376, draft-allman-dkim-base-01, and Creative Commons

[John R. Levine]

 That looks weird. Do we know its not spam?

Well, he managed to put in plausible looking contact info.

I'd say it's a crank or at best someone who is deeply confused about what 
IPR is.

R's,
John

 On 08/15/2013 04:44 PM, IETF Secretariat wrote:

 Dear Murray Kucherawy, Dave Crocker, Tony Hansen:

  An IPR disclosure that pertains to your RFC entitled DomainKeys Identified
 Mail (DKIM) Signatures (RFC6376) was submitted to the IETF Secretariat on
 2013-08-08 and has been posted on the IETF Page of Intellectual Property 
 Rights
 Disclosures (https://datatracker.ietf.org/ipr/2169/). The title of the IPR
 disclosure is ENTERKHAN CO., LTD's Statement about IPR related to RFC 6376,
 draft-allman-dkim-base-01, and Creative Commons.);

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

Re: [ietf-dkim] That weird i= is most probably EDSP

[John R. Levine]

 EDSP would be tier 1 both senderside and receiverside.  That's its
 selling point. ...

 TPA ADSP enhancements are tier 1 receiverside and just-barely-above tier
 3 senderside. ...

Did I miss some I-Ds describing these?

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] The problem with the DKIM design community

[John R. Levine]

What I'm asking for is nothing like SES.  I want the signature to be
based on the envelope MAIL FROM:, but it is still the body that gets
signed.  No VERPing is called for. ...


Where can we read the draft?

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] The problem with the DKIM design community

[John R. Levine]

 In reality, the recipient end DKIM deployment will be driven by
 sysadmins representing end-users who want less bad mail to reach them.
 Unlike the participating senders, they are not afraid of a phish or
 virus mail succeeding --- they merely do not want to be disturbed unless
 the mail is actually relevant.

My, aren't we cynical.  You must know very different system managers than 
the ones I talk to at MAAWG and other places.  I wouldn't say they're 
afraid of viruses and phishes, but they certainly want to keep them out of 
recipient mailboxes.

I also second Murray's suggestion that if you think you can design 
something better, please do so and write it up.  But first you might want 
to look at some of the signed bounce address proposals like this one, and 
consider why nobody adopted them.

http://web.archive.org/web/20060909034948/ses.codeshare.ca/files/Working_SES_Format_Definition_16.html

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] Weird i= in client mail

[John R. Levine]

 Now on the other hand, if an administrative domain wanted to go to the 
 trouble to authenticate down to the user level, we didn't want to prevent 
 that, either. The primary audience for DKIM includes regulated industries, 
 after all.

Seems to me that works fine as is.  If a stock broker wants to set up its 
mail system to put an i= into DKIM that reliably identifies the person who 
sent the mail, they can do that.

But unless I have external knowledge that they do that, and trust them to 
do it right, I can't depend on it, so it's mostly an opaque token of use 
to the sender when someone sends back a message and says what the heck is 
going on here?

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] The good ol' t= tag in key records

[John R. Levine]

 I've opened a ticket to arrange that t=y suppresses any positive impact
 domain reputation has in the next version of OpenDKIM, as an experiment.

I'm inclined to leave well enough alone.  That wouldn't have been an 
unreasonable interpretation six years ago when DKIM was new, but this is 
the first time someone's suggested that t=y mean something operational 
rather than just encouraging better logging and diagnostics.  (I discount 
the don't penalize us for bad signatures theory since as you note people 
aren't supposed to do that even without t=y.)

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Thoughts on ADSP discardable messages BCC'ing the postmaster? (akin to a FBL)

[John R. Levine]

 I'm reading the archives on ADSP and haven't seen anyone pitch the idea
 that on verification failure, we could have the message in question would
 be BCC'd to the domain owner's administrator for review.

I am a teenager with a lot of spare time, so I'm going to send thousands 
of random messages forging your domain, so you get copies of all of them.
Perhaps inventing yet another channel for indirect mailbombing is not a 
good idea.

This is not a hypothetical issue -- my abuse.net domain is forged enough 
that I've gotten 400,000 useless bounces in one day to random addresses in 
the domain.  It would not have been useful to get 400,000 more helpful 
notifications to my postmaster address.

By the way, I'm one of the authors of ADSP, and in my opinion, ADSP 
discardable is completely useless.  There are indeed domains whose mail is 
such a phieh target that it's worth losing a few real messages to get rid 
of all the phishes, but ADSP is not an effective way to find out who they 
are.

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] Enough already, Final update to 4871bis for working group review

[John R. Levine]

I'm not seeing much agreement on any changes to Murray's final draft, so 
may I suggest that it's good enough and we should ship it?  The potential 
benefit of the proposed changes doesn't impress me as worth the amount of 
argument they're provoking.

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] Final update to 4871bis for working group review

[John R. Levine]

 On 7/6/2011 10:59 PM, Michael Deutschmann wrote:
 Under the double-From: exploit Otis is so concerned about, one signer can
 (given favorable winds) trick an end-user into thinking his message was
 signed properly *by someone else*.  So indeed, a signer can attack.

 A signer can attack a recipient.  A signer cannot attack DKIM's mechanisms.

I would also be interested in seeing an example of a case where adding an 
extra From: line changles the d= in a 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] Final update to 4871bis for working group review

[John R. Levine]

 When DKIM signatures serve as a basis for acceptance, ...

Since they don't, can we skip the rest of the screed?

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] Pete's review of 4871bis

[John R. Levine]

 The first thing is that it's out of scope to address changes to things
 that were in RFC 4871, which was approved by the working group, the
 community, and the IESG in 2007, if it's simply a question of one or
 two people not liking those things so much -- even if one or two of
 those people now sit on the IESG.  The working group has really made
 an effort to avoid casual changes, and I support that, as chair and
 document shepherd.

RFC 4871 is full of gratuitous and often wrong advice on everything from 
APIs to MUA design to key management.  4871bis got rid of some of it, but 
there's still a lot left.  If Pete can force us to strip out more of the 
gratuitous stuff and stick to telling people how to do reliably 
interoperable signing and verification, the actual standards part of the 
standard, he'll be doing everyone a favor in the long run.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] spam filtering 101, was DKIM expert group meeting for Dutch 'comply or explain' list

[John R. Levine]

 For me, as an MTA operator, I'm happy that I have justification for 
 rejecting messages with the wrong number of From: headers.

I have pointed out at least six times, that in the extremely unlikely 
event that bad guys were to send mail with double From headers you can 
just dump it, since no real mail has more than one.  You don't need DKIM 
for that.  Spam filters have detected spam by looking for technical 
message flaws for over a decade, and this is just another one.

I don't know how to say that any more clearly.  Perhaps you can explain it 
to Doug.

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] DKIM expert group meeting for Dutch 'comply or explain' list

[John R. Levine]

 Acceptance policies and results for DKIM MUST align with
 what is being displayed in the message.

I'm pretty sure that we have uniformly agreed not to attempt to do MUA 
design, so, no, it doesn't.  We have no idea what is displayed in the 
message.  We have no idea if the message will ever be displayed at all.

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] DKIM expert group meeting for Dutch 'comply or explain' list

[John R. Levine]

 I'm pretty sure that we have uniformly agreed not to attempt to do MUA 
 design, so, no, it doesn't.  We have no idea what is displayed in the 
 message.  We have no idea if the message will ever be displayed at all.
 Ian,

 John is right.  Most headers are displayed selecting top-down

If you'll review the message you were quoting, I said We have no idea 
what is displayed in the message. I have done some experiements, and MUAs 
are utterly inconsistent.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] DKIM expert group meeting for Dutch 'comply or explain' list

[John R. Levine]

 Assuming this is some other protocol layers problem; to ensure consistency 
 between any possible display and DKIM validation, ...

  ... is, for about the hundredth time, not DKIM's job.

Please chant we have no idea how MUAs will display mail over and over 
until you believe it. This includes valid 5322 mail.

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] the non-problem of contributor signatures, was DKIM Scouts

[John R. Levine]

I didn't posit this as a problem. Others did. I jumped in at the point that you 
said s/mime was already a solution, with a message that proved otherwise.


It would be better to say that if there were a problem, and people wanted 
to solve it, the pieces are all there with S/MIME.  MUAs all know how to 
add S/MIME sigs to outgoing mail.  Mailman, which must be the most popular
MLM around, wraps the message body so that it preserves the signature. 
And some MUAs even look inside the wrapper to recognize and verify the 
wrapped signatures.


But a lot of MUAs don't, the ones that do make little effort to separate 
the signed from the unsigned text, and as far as I can tell, until I 
started poking at it last month, nobody knew or cared.


So, again, can someone tell me why this is so urgent a problem that we 
need to add special code to every DKIM signer and verifier in the world to 
solve 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

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] New canonicalizations

[John R. Levine]

 Chain of trust is always an appealing model.  Unfortunately, it hasn't 
 been used successfully over the open Internet.

I agree with your doubts about the utility of chain of trust, but I would 
have to say that SSL signed web sites are used successfully over the open 
Internet.

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

[John R. Levine]

 So as far as I can tell, we're at a point where lots of people think they 
 want MLM survivability of signatures, or at least the chain-of-trust 
 capability, but no proof that the increased risk is worth the increased gain.

I would quibble with the word lots.  Perhaps a few highly vocal.

Put me in the camp that says there's no problem that's come up in 40 years 
of MLMs that this would solve, and in the unlikely event that it actually 
were a problem, signing an A-R header would work lot better, since it 
includes a signature from the MLM, which is what we really want.

To the claim that there are MLMs that won't do that, if I count the number 
of MLMs in the world vs. the number of sending and receiving mail hosts, 
upgrading all the MLMs is a whole lot more likely than upgrading all of 
the mail hosts.

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] MLMs and signatures again

[John R. Levine]

 2) do we need a mechanism to alert the receiving MTA that you have
 subscribed to a mailing list, and all messages should pass through?

 Yes, desperately.

 Certainly a possible feature, but it seems like it won't scale very well.

 Why not?

If I were a spammer, I would tell the victim's MTA that the victim 
subscribed, then send the spam.

These days most subscriptions are entered on a web page, and if you're 
lucky the mailer will send a confirmation message with a URL that sends 
the subscriber back to the web page.  Where's the MTA going to get the 
subscriber info? The challenges in designing a protocol that neither makes 
unreasonable demands on users and MUAs nor is easily spoofed by hostile 
mailers seem insurmountable to me.  If you're planning to keep a 
reputation database of mailers who send credible subscription 
announcements, why not just whitelist their mail?

Since as far as I know nobody does this, it's a resarch topic, so I've 
directed replies to the ASRG.  See you there.

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

[John R. Levine]

 By introducing a loose canonicalization we may learn whether signature
 survivability affects DKIM adoption.

Feel free to do some experiments.  One of the reasons that DKIM has had 
relatively few implementation surprises is that we already knew how DK 
worked.

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] DKIM Scouts, was 8bit downgrades

[John R. Levine]

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.


My client found the signature, otherwise it would not have commented on its 
validity. It just wasn't able to verify it.


Hmmn.  How does it like the copy of this message sent to you directly? 
The signature was definitely good on the way out.


I think the long term solution would be for mailing list software to 
stop mucking around with the message body, and for MUAs to work better 
at exposing meta data added by lists (like the list-unsubscribe header).


Actually, I think the long term solution is for people to stop pretending 
there is a problem.  Can you describe the operational problems you're 
experiencing here?  Broken signatures is a fact, not a problem. 
Mailing lists have worked quite well for 40 years with no signatures at 
all, making all sorts of random changes to the mail, so it has to be 
something more than that.


Also, if you're suggesting changes to list software, please explain why 
they would have greater benefits than the obvious and simple one to have 
lists add their own signature on the way out.


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] signature breakage, DKIM Scouts, was 8bit downgrades

[John R. Levine]

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


FYI, I checked copies coming through the list in Apple Mail 4.5, and it 
sees the signature, too.  I was mistaken about T'bird, 3.1.9 on the Mac 
and 3.1.10 on FreeBSD don't.


Just out of nosiness, if your MUA doesn't think this message is signed 
could you drop me a private note saying what it is?  Tnx.


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


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] DKIM Scouts, was 8bit downgrades

[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] dot-forward, was 8bit downgrades

[John R. Levine]

 Although it is a minor number of messages, I don't think that
 ignore-by-design could play a winning role here, because --unlike
 mailing lists-- there is no way to eventually fix this at the
 forwarding MTA.

If the EAI work is any guide, in the long run everything will be 8 bit, 
and downgrades will eventually go away.

In the shorter term, if the forwarding MTA is inclined to be helpful, it 
can re-sign on the way out.

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

[John R. Levine]

 Barely. That's 0.1 on a default threshold of 5.0, I think.

 Granted, it's a small penalty, yet it's a penalty.

I'll ask the spamassassin developers where the number came from.  SM's 
suggestion that it has to be non-zero to exercise the code may be 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] 8bit downgrades

[John R. Levine]

 Exchange advertises 8bit and then bounces the mail if it tries to forward it 
 to a server that doesn't advertise 8bit.

 This (entirely RFC valid yet completely broken) behaviour has bitten me a 
 couple of times.

Better get used to it, since that's what EAI is going to do, too.

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] DKIM Scouts, was 8bit downgrades

[John R. Levine]

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.


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] DKIM Scouts, was 8bit downgrades

[John R. Levine]

Interestingly enough, outlook tells me this message has been tampered
with, but not sure why...


Probably doesn't have the Comodo validation certificate.

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 jo...@iecc.com 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.

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] DKIM Scouts, was 8bit downgrades

[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.


 On 5/24/11 18:13 , John R. Levine jo...@iecc.com wrote:

 Interestingly enough, outlook tells me this message has been tampered
 with, but not sure why...

 Probably doesn't have the Comodo validation certificate.

 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



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

[John R. Levine]

 In the real world signature reliability matters. If a domain signs mail 
 as a rule then an absent or broken signature will be treated as 
 suspicious.

I hope you're wrong, since that violates an explicit SHOULD in RFC 4871, 
and in my experience, most broken signatures are due to innocent 
modification in transit, not malice.

Do you have numbers to show that broken signatures indicate that messages 
are malicious, or spam, or otherwise worse than otherwise?

For that matter, since we're not talking about ADSP, what do you mean by 
an absent signature?  Do you track which domains sign what mail? How do 
you tell what signature you're expecting?  From line domain? Sender? 
Message ID? Something in the Received lines?

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

[John R. Levine]

 If one were to encode somehow an extension indication that this content was 
 subjected to 8-to-7 downgrade as a hint that a verifier should do the 
 reverse before verifying, the verifier would have to manage to undo the 
 downgrade in precisely, i.e. byte-for-byte, the same manner that the 
 downgrade was done for it to work.  That's a pretty high requirement for 
 interoperability (i.e., it's pretty error-prone), so it requires a 
 specification and it would need to be consistent with the MIME RFCs.

Seems to me that if someone were that desperate to get a signed message 
through a downgraded path, they should wrap the whole thing in a 
base64 encoded message/rfc822 mime part and send it that way.

This all strikes me as mostly hypothetical, and unlikely to affect more 
than a tiny sliver of mail.

The EAI group, which has way more experience with character set issues and 
downgrades than we do, tried all sorts of downgrade experiments and 
decided that none of them were workable. The current nearly final draft 
says that if you want to send an EAI message, you better find a path to 
the recipient that can deliver it as is.  Perhaps we should take the hint.

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

[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
 (http://cr.yp.to/smtp/8bitmime.html, 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

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

[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?

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

[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] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

[John R. Levine]

 As chair, I can say that consensus was to make this normative, not 
 experimental.

With the best will in the world, I was there, and I saw no such consensus.

The closest thing I can find in a quick search of the archive is this 
note, which says that the group agreed on one thing (that lists should 
sign their mail) but not on anything else:

http://mipassoc.org/pipermail/ietf-dkim/2010q4/014630.html

This document does not describe existing signing practice.  It makes a 
variety of highly speculative recommendations unsupported by experience. 
It is an experiment.

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] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

[John R. Levine]

   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.

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] Section 3.7 s/content-hash/body-hash/?

[John R. Levine]

 I think this should be limited only to change content-hash to body-hash 
 in the data-hash line, which is correct.

+1

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] discardable, was Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

[John R. Levine]

 I'd propose to put this item ('writeup a definition of 'discardable') on
 the to-do list of a successor of RFC5617, if there ever will be one. Or
 on another future 'policy' document.

-1

RFC 5617 has a perfectly good definition of discardable:

All mail from the domain is signed with an
Author Domain Signature.  Furthermore, if a
message arrives without a valid Author Domain
Signature due to modification in transit,
submission via a path without access to a
signing key, or any other reason, the domain
encourages the recipient(s) to discard it.

I realize there are people who wish it meant something else, typically 
simultaneously saying this mail is very important and throw this mail 
away, which is absurd, or perhaps if there's no signature, handle it 
based on some complicated set of instructions of no benefit to the 
receiver, even though the apparent sender probably isn't the actual 
sender, because the message is so very important.

The definition in the RFC was hammered out after a great deal of debate, 
and I see no evidence that the definition is defective.  ADSP has plenty 
of problems, but the definition of discardable isn't one of them.

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

[John R. Levine]

 Thus the following two forms

  Content-type: text/plain; charset=us-ascii (Plain text)
  Content-type: text/plain; charset=us-ascii

 are completely equivalent

 but they are not DKIM-wise equivalent.

I'm sorry, but this is just so wrong.

Helpful software can modify mail in a million ways that don't affect the 
way that a message renders.  If the contents of a message are in fact 
ASCII, these are also equivalent to the headers above:

  Content-type: text/plain; charset=UTF-8 (a superset of ASCII)
  Content-type: text/plain; charset=ISO-8859-2 (another superset of ASCII)
  Content-type: text/enriched; charset=windows-1252 (if there are no enriched 
codes)

The point of relaxed canonicalization was to deal with the kind of small 
changes that dusty copies of sendmail make, not to handle every possible 
message mutation that more or less renders the same.  In retrospect, it 
probably would have been better only to provide simple and tell people 
more firmly to do the signing after and the checking before any local 
modification.  The idea that an MUA can sign if an MTA doesn't is clever, 
but if anyone's doing that, it's news to me.

Perhaps Murray has data that says whether relaxed verifies much more 
often than simple does.

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

[John R. Levine]

 The underlying concern here actually is pretty reasonable: Variations that do
 not affect the appearance or semantics of a message could reasonably still
 permit a signature to verify.

Oh, sure, but we also traded off the cost of handling changes and how 
common they are.  For example, old copies of sendmail often add an extra 
blank line at the bottom of a message.  That's common (or at least, was 
common), and easy to deal with, and is the kind of thing that relaxed 
handles.  The variety of MIME rewrites is so vast that I don't see any 
hope of handling a usefully large set of them, so I'm not inclined to try.

If you really really really want your signature to verify, after signing 
the message, turn it info a base64 encoded message/rfc822 mime part, wrap 
another message around it, and unwrap it before verifying.  That works 
with S/MIME, too.

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

[John R. Levine]

 In retrospect, it probably would have been better only to provide
 simple and tell people more firmly to do the signing after and the
 checking before any local modification.

 That implies hop to hop rather than end to end.  What would the
 advantage over SPF be then?

The fact that most hops don't break even simple signatures.  We went 
through all this in 2006 (RFC 4686) and I don't see any reason to revisit 
it now.

 Perhaps Murray has data that says whether relaxed verifies much more
 often than simple does.

 Yes, http://www.opendkim.org/stats/report.html#hdr_canon says

 Header canonicalization use:
 canonicalization  count   domains passed
 simple  6536886786591938
 relaxed 3940377   56621   3640854

 Although they only differ by 2% (90% simple vs 92% relaxed), such
 percentages would be superb for tools like Spamassassin.  I'd expect
 at least 99% from a cryptographic tool.

This tells me that the benefit from relaxed is at most pretty small.

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] MLM and C14N

[John R. Levine]

 Hi Hector,
 At 15:20 14-05-2011, Hector Santos wrote:
 Shouldn't the MLM I-D say something regarding C14N and CR/LF related
 mutations?

 No.

+1 to the No.

I have my reservations about the draft, but this is not one of them.

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] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

[John R. Levine]

 I think it's best to have an example.  cron seems to be an ideal one, 
 though I'd be happy to add a second, Windows-specific, example if there is 
 one.  If not, changing 'such as cron' to 'such as the cron UNIX utility' 
 seems a better change to me.

Anyone who's ever managed a Unix or linux system knows what cron is. 
It's a fine example.

Indeed, on my own servers, there are cron scripts that push out daily 
digests which are DKIM signed on the way out.

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] Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

[John R. Levine]

I'd be very surprised to find that mention of cron in an RFC is
unprecedented.  Maybe I'll download the RFC set, have Google do a
word index on it, and see.


RFCs 2123, 2839, 4833, and 5427 refer to cron and cron jobs.  There may be 
others, but I found those with a simple grep.  (If anyone was planning to 
ask what grep is, don't.)



I don't see that automated mail robot with an MTA is right at all.
But I see what you're getting at, and I'd support a change such as
this:

      The author can be a human using an MUA (Mail User Agent) or
      an automated process that may send mail (for example, the cron
  Unix system utility).


There's no need to change the current language.  RFCs have been referring 
to cron jobs since 1997.


R's,
John___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] PROTO writeup for draft-ietf-dkim-mailinglists-10

[John R. Levine]

 This is a valid point.  Sean, please consider that the working group
 did not discuss the possibility of changing the status from BCP to
 Proposed Standard.  You might remove that from the writeup.

I suspect you would find signficant objection to making it a PS.

Considering how little of the advice is based on actual practice, even BCP 
is a stretch.

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

[ietf-dkim] DKIM and mailing lists

[John R. Levine]

I realize it's a little late, but here's what I think the MLM document 
should have said:

http://www.taugh.com/draft-levine-mlm-minus-00.html

I shamelessly stole Murray's intro sections, but you should blame me for 
the whole thing, borrowed or otherwise.

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] DKIM and mailing lists

[John R. Levine]

 I think You miss to state the important point that MLMs usually preserve
 the RFC5322.From when sending the email to the subscribers except in
 digest mode where it replaces it by the list-owner(?) email.

 This is why ADSP fails, otherwise if the RFC5322.From was replaced we
 would have no issues with ADSP.

As I tried to say tactfully in the draft, mailing lists have worked just 
fine for 40 years, so if DKIM or ADSP don't work with mailing lists, it's 
not because the lists are broken.

ADSP seems to be carrying on the SPF tradition of claiming that it's 
everyone else's fault that it doesn't work.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] I-D ACTION:draft-ietf-dkim-mailinglists-08.txt

[John R. Levine]

 4.3 it would be nice to talk about message encoding change like QP-8bits,
 may be in minor or major body changes. It is a minor change for the human
 but major for the machines as many characters got changed.

 Which MLMs do this?  I've never heard of that.

mj2 does all sorts of MIME smashage, although as far as I can tell nobody 
but Mozilla and I use it any more.  It's fairly common to flatten 
formatted text down to plain text either in the MLM or with a prepass like 
demime.  But we already know there are more ways that lists can break 
signatures than we can list, so I don't see any point in listing more of 
them.

 such as a signing and author subdomain {DKIM 12} - such as a signing
 and author subdomain {DKIM 12} or a totally different domain

 I'm on the fence on this one.  Does anyone else have an opinion?

It's an example, no need to change it.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

[John R. Levine]

 1.  State principals that are specific to the content of the draft and that 
 give guidance about the scope and boundaries of what should be covered.

 2.  Make specific suggestions for specific bits of text in the draft.

Despite the valiant work that Murray has put into the MLM document, my 
preference, which I doubt has any hope of gaining consensus, would be to 
throw it away and replace it by one page that says

a) many lists break signatures, which isn't going to stop

b) so it would be nice if they signed their mail on the way out.

Everything else is either too marginal to be worth worrying about, or not 
a problem if a list's mail has a credible signature.*

Failing that, I don't see small changes making it any better, so just ship 
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

* - Yes, that includes whether you can believe the From: line. I'm 
agnostic about whether it's useful to include an A-R header describing the 
incoming state of the message.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] l= statistics was 23 again (sorry John) was Output

[John R. Levine]

 Might not be list traffic.  But I have data for that too.  Count of 
 signatures with l= that did or didn't appear to pass through an MLM:

 +--+--+
 | count(*) | mailing_list |
 +--+--+
 |77246 |0 |
 |78853 |1 |
 +--+--+

That's just strange.  Most of the l= signatures don't cover the whole 
body, and half of those didn't go through a mailing list?

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] Output summary - Keep your Eye on the Prize!

[John R. Levine]

 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
 from others within the next few days, about whether you think we
 should make the change Hector requests or not.

Dave and Murray are right, Hector is not.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity

[John R. Levine]

 Alternatively we can allow it, warn, and expect implementers to code
 heuristics that can discern attacks from regular footers.

Speaking as an implementer, I ignore l=, because the hassle of working 
around it and trying to guess how hostile any added content might be is 
vastly greater than any utility it has.  As I've often noted, there are 
about a hundred ways that a mailing list can break a signature, and l= 
deals (badly) with only one of them.

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] 23 again (sorry John) was Output summary - proposing ODID Originating Domain Identity

[John R. Levine]

 I agree, as a participant.  Nevertheless, we have consensus to leave
 it in because of the stats Murray gave us on the usage (on the signing
 side).

I agree we need to leave it in, but as I said, I would rather not offer 
advice about how to code around its limitations, not least because 
whatever advice we offer will be insufficient.

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] Output summary - proposing ODID Originating Domain Identity

[John R. Levine]

 For a scenario where a caller is calling a DKIM milter which in turn calls an 
 API, this is all true. But DKIM will be/is deployed in many more scenarios.

Indeed, but you're misunderstanding the point of a standard.  The DKIM 
spec tells signers how to create a signature that recipients can verify, 
and it tells verifiers how to check whether a signature is valid.  The 
spec is not an implementation guide for every possible implementation 
scenario.

We're allowed to assume that the spec will be implemented by reasonably 
competent programmers.  I think reasonably competent includes figuring how 
to maintain or communicate the external state needed to do what you want 
to do.

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] Output summary - proposing ODID Originating Domain Identity

[John R. Levine]

 Has anyone other than me bothered to generate and review the complete diff?

I have.  The changes to the parts that actually describe how to create a 
signature are tiny, and well contained, e.g. updating the punycode 
definition, making sha-1 more deprecated, clarifying that unknown options 
and flags are ignored, explicitly deleting whitespace around b= when 
computing signatures, notes that all bets are off if you start with an 
invalid message.

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] Ticket 23 -- l= and Content-type

[John R. Levine]

 I don't think we yet have consensus to take out l= but it is quite clear
 that the problems it causes are far greater than whatever problems it
 might solve.

 As Hector notes, it is required by non-DKIM aware MLMs.

To aim one more kick at the greasy spot on the floor where the horse used 
to be, MLMs break signatures in a hundred ways, l= lets you work around 
one of those hundred ways at the cost of making your signature worthless.

 Perhaps reasoning should go like this:  Let's assume we can sign according to
 the target, then what would we do with a non-aware MLM?  If the answer is to
 avoid signing in such cases, then omitting l= and letting the signature break
 is just equivalent --except for aesthetic considerations...

Since a proper DKIM implementation ignores broken signatures, you sign 
everything.

Can we stop arguing about this now?  These points were all hashed to the 
point of exhaustion a year ago.

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] Ticket 23 -- l= and Content-type

[John R. Levine]

 I don't think we actually understand all the ways that l= allows you to
 shoot yourself in the foot, so I would prefer not to give the impression
 that if people avoid a few cases we describe, they're safe.

 -1, I agree we don't know all the ways DKIM can be fooled.  Neither we
 actually saw real attacks in the wild.  We don't even state how to
 react to multiple Froms.  Presumably, the wider the DKIM deployment,
 the more we'll learn on handling attacks.  However, hiding the few
 things we know doesn't seem to be a good start toward such watchful
 cooperative deployment.

The message should be don't use l= if you care about your signature.

I don't think we yet have consensus to take out l= but it is quite clear 
that the problems it causes are far greater than whatever problems it 
might solve.

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] Ticket 23 -- l= and Content-type

[John R. Levine]

 What's your counter-proposal to Alessandro's proposal to modify 9.1.1?

Oh, that.  Replace all of sec 9.1 with:

  As noted in Section 4.4.5, use of the l= tag enables a variety of
  attacks in which added content can partially or completely changes the
  recipient's view of the message.

I don't think we actually understand all the ways that l= allows you to 
shoot yourself in the foot, so I would prefer not to give the impression 
that if people avoid a few cases we describe, they're safe.

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] Ticket 23 -- l= and Content-type

[John R. Levine]

1. This is just a variant of the basic hole created by use of l=

2. The premise that having the l= go to a multipart boundary somehow
 increases security is simply wrong.  More generally, the idea that one or
 another tidbit might tighten things a bit, l= opens such a huge door, the 
 small
 tidbits don't matter.

On further consideration, I'm with Dave.  Suggest removing the current 
language about l= and MIME boundaries, and replace with a note that if you 
use l=, added content can change the appearance of a message in hard to 
anticipate ways.

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] Ticket 23 -- l= and Content-type

[John R. Levine]

On Fri, 29 Apr 2011, Murray S. Kucherawy wrote:

 On further consideration, I'm with Dave.  Suggest removing the current
 language about l= and MIME boundaries, and replace with a note that if you
 use l=, added content can change the appearance of a message in hard to
 anticipate ways.

 Replace the whole section with just that, or only the first paragraph?

Sheesh, you actually want me to read the thing?  Oh, all right.

In 4.4.5, delete   Signers
of MIME messages that include a body length count SHOULD be sure that
the length extends to the closing MIME boundary string.

Also delete the subsequent INFORMATIVE IMPLEMENTATION NOTE.

The note earlier in the section says the bad guy can replace the displayed 
contents, so I don't think we need to say it again.


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] Output summary

[John R. Levine]

 I wouldn't be opposed to doing so, except that 4871 says in two separate
 places not to do that.  Section 7 is, now that I look at it, really badly
 written, since it implies that a verifier is an SMTP server.

 I can take a run at fixing Section 7.  What's the other place that says 
 not to do that?

Last paragraph of sec 5.2:  Verifiers SHOULD ignore failed signatures as 
though they were not present in the message.

 My preference would be to return a list of signatures that either passed 
 or TEMPFAILed, which could be the empty set if all of them PERMFAILed or 
 the message was unsigned, or none of them were acceptable in the first 
 place for whatever policy reasons.  The caller can decide whether it 
 wants to try the whole shebang again later, or continue with what it 
 got.  It's simple and complete.

That seems reasonable, but I wonder if that's a large enough change to 
provoke a recycle.  I suppose we can argue that the prior language was 
inconsistent.  What does opendkim do?  My verifier, which sometimes runs 
in the SMTP session and sometimes runs other places, treats tempfail 
and permfail the same.


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] Output summary

[John R. Levine]

 Last paragraph of sec 5.2:  Verifiers SHOULD ignore failed signatures as
 though they were not present in the message.

 Is that inconsistent with the idea of only reporting signatures that 
 verified or those that TEMPFAILed?  In that model, failed ones aren't 
 reported which is logically equivalent to them being ignored.  Seems 
 like a fit to me.

I read that as inconsistent with reporting tempfails.

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] ADSP stats

[John R. Levine]

 We check ADSP every time we run DKIM and see the following policy
 distribution:

 97.98% unknown (including domains not explicitly publishing policy)
 2% discardable
 0.02% all

That's not surprising.  Keep in mind that the design of ADSP means that 
you're supposed to check mail that's not signed (or at least, without a 
signature that matches the From: line.)  In my much smaller sample, I see 
discardable on mail from Paypal, and I could believe that Paypal is 2% of 
the signed mail they check.

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] Two issues derived from Ticket #20: signature practices

[John R. Levine]

 +1, and also for Murray's advice of signing A-R fields.

I still don't understand why, if you trust a signer enough to believe the 
mailing list A-R headers he signs, you don't trust him enough to deliver 
the mail, and, of course, why we now need to remotely verify contributor 
addresses when we've gotten along without it for 40 years, but whatever.

Keeping in mind that this is all non-normative, it seems harmless.

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] Output summary

[John R. Levine]

 Do we need to say anything about the possibility that there are multiple
 signatures?

 How about For each signature not ignored by the verifier or such.

Section 5.3 says:

Verifiers SHOULD ignore failed signatures as though they were not
present in the message.

and Section 7 says:

In the following description, text reading return status
(explanation) (where status is one of PERMFAIL or TEMPFAIL)
means that the verifier MUST immediately cease processing that
signature.  The verifier SHOULD proceed to the next signature, if any
is present, and completely ignore the bad signature.  If the status
is PERMFAIL, the signature failed and should not be reconsidered.
If the status is TEMPFAIL, the signature could not be verified at
this time but may be tried again later.  A verifier MAY either defer
the message for later processing, perhaps by queueing it locally or
issuing a 451/4.7.5 SMTP reply, or try another signature; if no good
signature is found and any of the signatures resulted in a TEMPFAIL
status, the verifier MAY save the message for later processing.  The
(explanation) is not normative text; it is provided solely for
clarification.

If you believe that, the output should only include signatures that 
verified, right?  So you aren't suppsed to report TEMPFAIL or PERMFAIL. 
Except that if it TEMPFAILed, the output can optionally include a queued 
copy of the message and part of a of SMTP transaction.

I fear the worms are escaping.  Maybe it should say that the output 
includes the signatures that validated.  If nothing validated, it might 
include a hint that the caller might get a better answer later.  And we 
should fix Section 7, since you can't even assume that the validator is 
running anywhere near an SMTP session.

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] Output summary

[John R. Levine]

 As for TEMPFAIL, you'd have to know which signature(s) were temp-failed in 
 order to decide about a later retry, which then leans us back toward giving 
 the whole list of signatures that were present and a status for each.

I wouldn't be opposed to doing so, except that 4871 says in two separate 
places not to do that.  Section 7 is, now that I look at it, really badly 
written, since it implies that a verifier is an SMTP server.

We probably have reasonably good agreement about what a verifier should 
do:

a) If at least one signature verifies, report success with the d= value(s)
of the valid signature(s) and optionally other stuff.

b) If nothing verified and nothing tempfailed, report no signatures.

c) If nothing verified and something tempfailed, return a hint to try 
again later.

d) If at least one signature verified and at least one tempfailed, uh, 
flip a coin and either report success or a try again hint.

Unfortunately, that's not really what the existing language says.

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