[ietf-dkim] CHANGE OF IETF DKIM LIST POSTING ADDRESS

[Dave Crocker]

Folks,

As of this message, the IETF DKIM discussion list address:

 ietf-dkim@mipassoc.org

is no longer valid.

The new address to use for posting to the IETF DKIM discussion list is:

 ietf-d...@ietf.org

The existing archive and the existing membership list has been 
transferred to the new address.  (You presumably already seen the 
announcement of your auto-subscription to the new address.)


d/

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

[ietf-dkim] change of venue for ietf-dkim mailing list

[Dave Crocker]

Folks,

I've been very long remiss in responding to a request that the ietf-dkim 
mailing list re-locate, to home on the ietf.org site.  That process is 
now (finally) underway.


It is being done in stages, to try to mitigate against any loss of 
membership entries and/or messages in the archive.


 1. The first step will be creation of the list at the ietf.  (I've 
suggested a list name, but we'll see what they choose.)


 2. Membership in the current list is now set to be moderated and 
I'll decline new members until the list is moved (and then it won't by 
mine to worry about...)


 3. The existing membership will be copied over to the ietf list. 
I've suggested a direct enrolling, without making anyone re-subscribe, 
but again we'll see what ietf ops decides.


 4. After the switch is complete and the list is operational, we'll 
move a copy of the list archive over there.



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

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

[Dave Crocker]

On 2/11/2018 5:54 PM, Michael Thomas wrote:

You clearly have no idea what you are talking about.

Mike

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




Mike,

Please review the participation rules applicable to this list.  They are 
the same as you had so much trouble with, previously.


Then please consider unsubscribing, since restraint within the bounds of 
professional behavior appears to (continue to) be absent from your 
repertoire.


d/

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

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

[Dave Crocker]

On 2/10/2018 10:47 AM, Michael Thomas wrote:

But I still think this entire conversation is silly in its theoreticality.



Extra design complexity and consuming development resources -- 
programming, bench testing, interoperability testing -- for something 
that is not essential, nevermind offers no actual value, is about as 
practical as any standards issue can get.


Protocol complexity matters, especially for features that have no 
immediate use.


d/

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

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

[Dave Crocker]

On 2/10/2018 9:59 AM, John R. Levine wrote:
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.


The problem is that you are conflating and/or missing some basic points, 
relative to my thesis, which is that a distinct 'version' flag is 
essentially never useful.


First, 8bitmime changes what is permitted for encoding, not basic 
'format' or semantics.  (For this discussion, that's a nit, but still...)


Second -- and really quite fundamental -- 8bitmime is a negotiated 
feature during an interactive session.  The SMTP server gives the SMTP 
client permission to use it.  DKIM is a unilateral mechanism: there's no 
interaction; there is no 'permission' to give.  There is only signaling 
the fact of usage.


Third, 8bitmime is not a version flag, distinct from the protocol 
feature changes being changed, which is the point of this thread.  It is 
the change itself.  The signalling function, that there is a new feature 
-- ie, a different 'version', to employ your apparent usage of the term 
-- is implicit and integrated, rather than distinct and explicit.




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.


That's not my point.  DKIM won't work without... DKIM.  SMTP /will/ work 
without the MIME extensions.


More generally, you have fallen into using the term 'version' for every 
specific enhancement.  While that has linguistic validity, it does not 
have real-world relevance, with respect to a protocol 'version' parameter.


A version parameter is distinct from other syntactic and semantic 
aspects of the changes that are being signaled.


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

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

[Dave Crocker]

On 2/10/2018 10:12 AM, Michael Thomas wrote:

DKIM-Signature-v2: vs DKIM-Signature: v=2;

Angels, meet the pinhead.


equal semantics does not mean equal implementation.  the processing for 
each of these takes place in very different parts of the system.  the 
latter requires new code, albeit internal to the DKIM module.  the 
former merely requires a new table entry.


d/

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

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

[Dave Crocker]

On 2/10/2018 9:47 AM, John R Levine wrote:

    v= word (, word)*

 where each word describes a semantic feature.  Feature tag "1" is all
 the stuff in RFC6376.  My feature is mandatory to understand tags,
 feature name "mandatory", so the signatures start


The listing of 'authorized' features ...


Sorry, stop there.  This isn't "authorized" features, this is "used" 


fine, but that doesn't change any of the rest of my commentary about 
unilateral vs. 'negotiated'.



features, as in if you don't support this feature, don't use this 
signature.


In a unilateral activity like DKIM, the mere presence of the usage 
"featurex=..." serves to flag that featurex is used.  There is no 
incremental benefit into moving the flag elsehwere.


Well, OK, other than DKIM-Improved-Signature how would you do 
conditional signatures, where the signature has to fail if the semantics 
of the re-sign tag aren't satisified?  Remember that the current rule is 
that verifiers ignore tags they don't understand.


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.


Different protocol?  Yes.  Current DKIM does not require support for 
unrecognized tags, beyond the initial set.  You want to require support 
for additional tags.  That's a fundamental change; so it isn't 'DKIM'. 
It's something different.


d/


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

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

[Dave Crocker]

On 2/10/2018 7:50 AM, John Levine wrote:

The idea with DKIM v=2 is that there are things that you cannot say in
a v=1 signature, no matter how many new tags you add, so you need some
way to tell verifiers what they need to understand.  How about this?

We rebrand the v= tag to be a feature list so the syntax is now roughly

   v= word (, word)*

where each word describes a semantic feature.  Feature tag "1" is all
the stuff in RFC6376.  My feature is mandatory to understand tags,
feature name "mandatory", so the signatures start


The listing of 'authorized' features makes sense when the usage may 
occur later in the session, as it does with ESMTP, for giving the other 
side permission to use those features.  It makes no sense at all for a 
unilateral exchange where one side uses whatever it feels like and the 
other side -- getting all this later -- either likes it or doesn't. 
That is there are no contingent behaviors in the exchange.


In a unilateral activity like DKIM, the mere presence of the usage 
"featurex=..." serves to flag that featurex is used.  There is no 
incremental benefit into moving the flag elsehwere.


d/

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

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

[Dave Crocker]

On 2/10/2018 7:50 AM, John Levine wrote:

PS: The reason you haven't noticed the versions in RFC822 is that we
put the version flags into SMTP.  An 8BITMIME or EAI mail message is
not backward compatible with RFC822.



Well, that's simply and completely false.

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


In fact, you've tripped into the core debate that originally triggered 
the parallel, /competing/ efforts that produced ESMTP and MIME.


d/

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

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

[Dave Crocker]

On 2/9/2018 2:31 PM, John R. Levine wrote:

In article <20180209202621.31355.qm...@f3-external.bushwire.net>,
Mark Delany <sx6un-fc...@qmda.emu.st> 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.



Sorry.  Where is the version number for SMTP?

Which is to day, thanks for demonstrating my point:  the 'version' flag 
is implicit with the features that are added.  If they are present, you 
have the 'newer' version.


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

d/


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

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

[Dave Crocker]

On 2/9/2018 12:26 PM, Mark Delany wrote:

On 08Feb18, Michael Thomas allegedly wrote:

I dunno, it's not like there isn't precedent for this. oh say, like ipv4
vs. ipv6?


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.


and SMTP...



I might add that RFC822 seems to have adapted a lot better than the v4 vs v6
crowd. Not sure you picked the best example of success there, Michael :-)


What's rather impressive is how aggressively the general Internet 
technically has worked to avoid learning any lessons from this disparity...



d/

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

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

[Dave Crocker]

On 2/8/2018 4:42 PM, Michael Thomas wrote:
Besides if you wanted to go from DKIM to EKIM, you'd be opening 
pandora's box imo.



The pandora's box is creating an incompatible new version.  All the rest 
is just engineering and operations tradeoffs.


d/

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

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

[Dave Crocker]

On 2/8/2018 11:24 AM, Barry Leiba wrote:

I believe the right solution to this, consistent with the intent of
how email header fields work, is to add a sentence (via errata) to RFC
5322 section 2.2 or section 3.6 -- or both -- somewhat like this:

OLD

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.

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.

END



wfm, although as a bit of belsts-and-suspenders, I'd also suggest in 
Section 3.6.8:


OLD:


   field-name  =   1*ftext

NEW:

   field-name  =   1*ftext
   ; case insensitive, per sections 2.2 and 3.6

or somesuch.

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

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

[Dave Crocker]

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.


Oh.  So v= doesn't dispatch to different code.



BTW, this topic tends to eventually produce a claim that the fact that 
the different versions share so much code justifies the versioning 
mechanism.


Except that code sharing happens in many circumstances that don't 
require conflating incompatible protocols and then using an internal 
demultiplexing switch.


The larger topic is the choice between high-level switching versus 
low-level, and the long-term costs of transition mechanisms.


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

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

[Dave Crocker]

On 2/8/2018 10:05 AM, Pete Resnick wrote:


RFC 7405 is also useful along these lines.


If those modifications are used, sure.  If not, not so much.


So, no error in 5322. As for the erratum below, not having ABNF for the 
header field does seem like a miss, though I'm not sure it should be 
marked as more than "Hold for document update".


Consider:

1. RFC 5322 specifies ABNF for field names that is in terms of 'allowed' 
characters, but has no text constraining the method of defining the 
specific characters for specific header-field names.


2. Section 1.2.2 notes that "..." is case insensitive, but that the %... 
is inflexible (ie, sensitive.)


3. Nothing in the definition of optional-field requires using the "..." 
construct to define the header field name.  It merely defines what range 
of characteris allowed in a field-name.


   fields  =   *(trace
  ...
   optional-field)

   optional-field  =   field-name ":" unstructured CRLF

   field-name  =   1*ftext

   ftext   =   %d33-57 /  ; Printable US-ASCII
   %d59-126   ;  characters not including
  ;  ":".

4. If a spec defines a field-name using the %... construct, it has 
effectively required case sensitivity in processing the field-name.


5. That was most certainly /not/ what was 'intended' for field-name 
parsing, going at least back to RFC 733. Violation of 'intent' is the 
criterion for an RFC erratum.


d/

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

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

[Dave Crocker]

On 2/8/2018 10:03 AM, John R. Levine wrote:
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.


Oh.  So v= doesn't dispatch to different code.



The point of a v=2 flag is to ensure that old v=1 code doesn't 
accidentally misinterpret new features. 


"Accidentally misinterpret new features" seems to be synonymous with not 
being upward compatible.  In other words, the new features make the new 
version incompatible with the old.  Hence, the new features define a new 
protocol.



 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.


Change to basic semantics of the protocol.  Hence, new protocol.


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

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

[Dave Crocker]

On 2/8/2018 9:45 AM, John R. Levine wrote:

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



Re-read what I wrote.

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


d/

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

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

[Dave Crocker]

On 2/8/2018 9:09 AM, John R. Levine wrote:
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.


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


d/


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

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

[Dave Crocker]

While possibly a nice addition to the specification, including this ABNF 
rule does not correct an error in RFC 6376.



As for header-field name case sensitivity, that is the purview of RFC 
5322, not RFC 6376.


(FWIW, it does appear that there is an error in RFC 5322, since it does 
not enforce case insensitity in the syntax, although it specifies -- and 
intends -- it in the prose.)


d/



The following errata report has been submitted for RFC6376,
"DomainKeys Identified Mail (DKIM) Signatures".

--
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5260

--
Type: Editorial
Reported by: Ale <ves...@tana.it>

Section: 3.5

Original Text
-


Corrected Text
--
DKIM-Signature = "DKIM-Signature:" tag-list

Notes
-
A formal definition is needed to make it explicit that this header field name 
is case insensitive, like all the other header field names.

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC6376 (draft-ietf-dkim-rfc4871bis-15)
--
Title   : DomainKeys Identified Mail (DKIM) Signatures
Publication Date: September 2011
Author(s)   : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
Category: DRAFT STANDARD
Source  : Domain Keys Identified Mail
Area: Security
Stream  : IETF
Verifying Party : IESG




--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
___
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?

[Dave Crocker]

On 2/8/2018 8:52 AM, John R. Levine wrote:

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.



What you realized goes to the heart of the reason we don't need version 
numbers.


The issue falls into the category of how to specify a processing fork. 
At each protocol layer, there is a mechanism for specifying which 
processing engine is appropriate for the next layer up.  Ethertype, 
Protocol ID, Port, etc.


Version numbers serve that purpose /within/ a protocol layer.

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


Except really they don't.

If modifications to a protocol are upward compatible, the the new 
features, themselves, self-identify and version numbers aren't needed. 
If no new features are present, you have the old 'version' of the 
protocol.  If new features are present, you have the new 'version'.


If modifications are /not/ upward compatible, you really have a new 
protocol.  Make a new entry in whatever forking mechanism was used to 
get to the previous version.  As you note, a new header-field would be 
appropriate here.


d/


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

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

[Dave Crocker]

On 2/8/2018 8:17 AM, Mark Delany wrote:

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


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.



There appears to be a genetically-encoded belief in the value of version 
numbers, independent of the logic against it.  The belief is pervasive 
and seems to cross all technical cultures, experiential sets, and 
protocol layers.


d/


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

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

[Dave Crocker]

On 2/8/2018 8:05 AM, John R. Levine wrote:
I'm not saying any sensible person would do that, but as far as I can 
tell, that's what the spec says.



From a quick review of RFC 5322, I think you are correct.  I also 
believe (know) that this is not what has been intended for header field 
name specification, dating back to RFC 733.


That is, the capability you note is contrary to what I believe was 
intended in the RFC 5322 specification.  And deviation from iontent is 
the requirement for qualifying as an errata on an RFC.


I suggest you submit it.  It will be interesting to see the followup.

d/

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

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

[Dave Crocker]

On 2/8/2018 5:22 AM, John R. Levine wrote:
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.


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.



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.


In RFC 6376, note Section 3.2 on tag lists.  The ABNF shows no 
sensitivity to ordering. (The linkage to DKIM-Signature is Section 3.5, 
first paragraph.)



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

Re: [ietf-dkim] Mailsploit

[Dave Crocker]

On 12/5/2017 1:44 PM, Steve Atkins wrote:

That's DMARC working exactly as designed but not as commonly understood, which 
makes it a DMARC issue (though a usability one of unmet expectations rather 
than anything technical).



probably not.

it's an anti-abuse issue, where there is quite a bit of sloppiness and 
confusion about all of the relevant technologies.


but the problem and the issue is the broad need for much better clarity 
and precision than to assign a particular misunderstanding to that 
particular technology.  (People generally believe DKIM certifies the 
source of a message and even its authorship.)


d/

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

Re: [ietf-dkim] Mailsploit

[Dave Crocker]

On 12/5/2017 1:33 PM, Steve Atkins wrote:

It's a DMARC issue rather than a DKIM one.



How is it a DMARC issue?

d/


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

Re: [ietf-dkim] Fwd: SendGrid, GetResponse and Hubspot being used over DKIM "patent"

[Dave Crocker]

On 12/5/2017 12:50 PM, Mark Delany wrote:

For moral equivalence, the Date: header is a pledge as to when the
email was composed/sent



I've done only two user studies in my life.  The first -- for the Rand 
system --produced the email command name 'reply'.  The second -- for the 
DRUMS production of RFC2822, I believe, clarifying RFC822 -- was for the 
semantics of the Date: field.  It's meaning was not lear in 822 and the 
result of the survey of users I did was to define it as the time of 
posting.  Hence the 'send' you cite, rather than the 'compose'.


Thank you for tolerating this distraction.  You are now returned to 
matters of substance...


d/

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

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

[Dave Crocker]

(re-setn, trying to use addresses for Tony and Murray that might work... /d)


On 10/3/2017 7:24 PM, RFC Errata System wrote:

Type: Technical
Reported by: Peter Smith<pesm...@microsoft.com>

Section: 3.6.1

Original Text
-
   key-k-tag= %x76 [FWS] "=" [FWS] key-k-tag-type


Corrected Text
--
   key-k-tag= %x6b [FWS] "=" [FWS] key-k-tag-type


Notes
-
The key-k-tag should (presumably) start with the letter "k" to match the other key-LETTER-tag definitions and 
to match the "k=" heading.  However, the ABNF specifies %76 which is the letter "v", not the letter 
"k".  The correct value is %x6b.



oops.

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

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

[Dave Crocker]

On 10/3/2017 7:24 PM, RFC Errata System wrote:

Type: Technical
Reported by: Peter Smith<pesm...@microsoft.com>

Section: 3.6.1

Original Text
-
   key-k-tag= %x76 [FWS] "=" [FWS] key-k-tag-type


Corrected Text
--
   key-k-tag= %x6b [FWS] "=" [FWS] key-k-tag-type


Notes
-
The key-k-tag should (presumably) start with the letter "k" to match the other key-LETTER-tag definitions and 
to match the "k=" heading.  However, the ABNF specifies %76 which is the letter "v", not the letter 
"k".  The correct value is %x6b.



oops.

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

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

[Dave Crocker]

(sigh.  re-re-sent to try for a valid tony address too...)
(resent, to get a working murray address. /d)


On 7/15/2017 9:10 AM, RFC Errata System wrote:

Original Text
-
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
  ; Prohibits WSP and FWS at beginning and end

Corrected Text
--
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] [tag-value [FWS]]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  tval *( 1*(WSP / FWS) tval )
  ; Prohibits WSP and FWS at beginning and end

Notes
-
The ABNF in the document permits two FWS rules to appear in the row. This 
results in permitting a line with only whitespace in the header which falls 
into obsolete syntax in RFC 5322 (Appendix B rule 12). The corrected text 
disallows this by eliding the second FWS when the tag-value is empty/omitted.



Hitting 'obsolete' RFC5322 syntax doesn't bother me all that much, given 
that there is now a long history of non-enforcement; the constructs were 
never seriously deprecated.


But the proposed change does seem cleaner to me.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Dave Crocker]

(resent, to get a working murray address. /d)


On 7/15/2017 9:10 AM, RFC Errata System wrote:

Original Text
-
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
  ; Prohibits WSP and FWS at beginning and end

Corrected Text
--
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] [tag-value [FWS]]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  tval *( 1*(WSP / FWS) tval )
  ; Prohibits WSP and FWS at beginning and end

Notes
-
The ABNF in the document permits two FWS rules to appear in the row. This 
results in permitting a line with only whitespace in the header which falls 
into obsolete syntax in RFC 5322 (Appendix B rule 12). The corrected text 
disallows this by eliding the second FWS when the tag-value is empty/omitted.



Hitting 'obsolete' RFC5322 syntax doesn't bother me all that much, given 
that there is now a long history of non-enforcement; the constructs were 
never seriously deprecated.


But the proposed change does seem cleaner to me.

d/


--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

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

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

[Dave Crocker]

On 7/15/2017 9:10 AM, RFC Errata System wrote:

Original Text
-
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] tag-value [FWS]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  [ tval *( 1*(WSP / FWS) tval ) ]
  ; Prohibits WSP and FWS at beginning and end

Corrected Text
--
tag-spec  =  [FWS] tag-name [FWS] "=" [FWS] [tag-value [FWS]]
tag-name  =  ALPHA *ALNUMPUNC
tag-value =  tval *( 1*(WSP / FWS) tval )
  ; Prohibits WSP and FWS at beginning and end

Notes
-
The ABNF in the document permits two FWS rules to appear in the row. This 
results in permitting a line with only whitespace in the header which falls 
into obsolete syntax in RFC 5322 (Appendix B rule 12). The corrected text 
disallows this by eliding the second FWS when the tag-value is empty/omitted.



Hitting 'obsolete' RFC5322 syntax doesn't bother me all that much, given 
that there is now a long history of non-enforcement; the constructs were 
never seriously deprecated.


But the proposed change does seem cleaner to me.

d/


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

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

[Dave Crocker]

On 2/13/2017 5:32 PM, Barry Leiba wrote:

Verified as Editorial is my preference.  Editorial because I don't

...

If you decide to leave it as Technical, then we should definitely go



Since I raised some fuss about this choice, let me be clear that I meant 
the fuss only in academic terms.  I don't think the difference matters, 
in this case, in terms of IETF process or actions.


d/
--

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

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

[Dave Crocker]

On 2/7/2017 5:52 PM, Roland Turner wrote:

As a passing engineer who doesn't spend that much time spelunking IETF
processes, a question that appears to be begged here is why the
distinction matters. This is not immediately clear from any of the
Status and Type of RFC Errata page
<https://www.rfc-editor.org/errata-definitions/>, the How to Report
Errata page <https://www.rfc-editor.org/how-to-report/>, or the FAQ
<https://www.rfc-editor.org/faq/>.




In recent years -- and by way of demonstrated some basic process 
problems, I'll note that I have no idea when the current constraints on 
the process were put in place -- the RFC errata process got moved into a 
very specialized place, to the exclusion of a number of useful 
functions.  It's not that what it does do isn't useful, it's that it has 
become idiosyncractic.  And, yeah, it does not appear to me that most 
folk know what it is and is not useful form.




d/

--

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

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

[Dave Crocker]

On 2/7/2017 10:52 AM, Barry Leiba wrote:

I suspect that "says something technically wrong" is meant to constrain
things to the specification content, but that's not what the RFC-Editor
definition says, nor is it clear to me that it should be that constrained.


I agree.  I think it mostly should, but that there should be judgment involved.


The current error has technical import, since we are talking about a broken
validation.

So, I'm not at all clear that this qualifies as only an 'Editorial' error.


I don't see it that way.
I think there's a difference between an example that includes


So, I think I understand that view, which is why I said "ambiguous".

And the only reason I'm pursuing it, here, is that I think the 
determination of an erratum should not be so subjective.  I think the 
RFC Editor language defining categories should have criteria that are 
considerably more crisp.



d/

--

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

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

[Dave Crocker]

On 2/7/2017 10:25 AM, Barry Leiba wrote:

Assuming they do, this errata report should be marked "Verified", but
the type should be changed to "Editorial", not "Technical".

Hmmn.  It's really both, a technical error caused by an editorial change.

No: a Technical erratum is one where the spec actually says something
technically wrong, such that if you implemented according to the spec,
your implementation would be wrong.  Missing space characters in
examples == Editorial.


Hmmm.  I'm not worried about this error doing damage to the community, 
but since the formality of 'errata' is at issue in this exchange, I find 
the online guidance just ambiguous enough to be significant...


I suspect that "says something technically wrong" is meant to constrain 
things to the specification content, but that's not what the RFC-Editor 
definition says, nor is it clear to me that it should be that constrained.



The guidance at:

 https://www.rfc-editor.org/errata-definitions/


Technical   error in the technical content (Note that changes in the usage 
of RFC 2119 keywords are considered technical.)

Editorial   a spelling, grammar, punctuation, or syntax error that does not 
affect the technical meaning



The current error has technical import, since we are talking about a 
broken validation.


So, I'm not at all clear that this qualifies as only an 'Editorial' error.

Mumble.

d/

--

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

[ietf-dkim] Fwd: [Technical Errata Reported] RFC6376 (4926)

[Dave Crocker]

G'day.

Looking for a community determination, here:  The DKIM spec's examples 
in A.2 and A.3 do not explicitly claim to be related to each other. 
However they do contain the same message, so that assuming a 
relationship seems pretty reasonable.


As such, calling the point raised in this Errata report an actual error 
is certainly not silly.  But I'm not sure it's correct, either.


Thoughts?

d/


 Forwarded Message 
Subject: [Technical Errata Reported] RFC6376 (4926)
Date: Tue,  7 Feb 2017 07:17:12 -0800 (PST)
From: RFC Errata System 
To: dcroc...@bbiw.net, tony+dki...@maillennium.att.com, 
m...@cloudmark.com, stephen.farr...@cs.tcd.ie, 
kathleen.moriarty.i...@gmail.com, barryle...@computer.org
CC: simon@emersion.fr, ietf-dkim@mipassoc.org, 
text/pl...@rfc-editor.org, charset=ut...@rfc-editor.org


The following errata report has been submitted for RFC6376,
"DomainKeys Identified Mail (DKIM) Signatures".

--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6376=4926

--
Type: Technical
Reported by: Simon Ser 

Section: A.2, A.3

Original Text
-
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
 c=simple/simple; q=dns/txt; i=j...@football.example.com;
 h=Received : From : To : Subject : Date : Message-ID;
 bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
 b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
 KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
 4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
 by submitserver.example.com with SUBMISSION;
 Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack 
To: Suzie Q 
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5...@football.example.com>


Corrected Text
--
DKIM-Signature: v=1; a=rsa-sha256; s=brisbane; d=example.com;
  c=simple/simple; q=dns/txt; i=j...@football.example.com;
  h=Received : From : To : Subject : Date : Message-ID;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB
  4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut
  KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV
  4bmp/YzhwvcubU4=;
Received: from client1.football.example.com  [192.0.2.1]
  by submitserver.example.com with SUBMISSION;
  Fri, 11 Jul 2003 21:01:54 -0700 (PDT)
From: Joe SixPack 
To: Suzie Q 
Subject: Is dinner ready?
Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
Message-ID: <20030712040037.46341.5...@football.example.com>

Notes
-
The "simple" header canonicalization doesn't change the header fields in 
any way.


Folded header fields are missing one space of indentation (they have 5 
spaces instead of 6), which makes the verification fail. Note that the 
plain text version of the RFC adds a prefix of three spaces before each 
line of text, which must be ignored.


In section A.3, the indentation is changed again (5 spaces instead of 6 
+ the "b=" tag has 2 additional spaces of indentation).


Test cases:
- opendkim: 
https://github.com/cyrusimap/opendkim/blob/ab2934e131cbe670b49f11db9daf8cd1223e3839/libopendkim/tests/t-testdata.h#L74

- go-dkim: https://github.com/emersion/go-dkim/blob/master/verify_test.go#L9

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  can log in to 
change the status and edit the report, if necessary.

--
RFC6376 (draft-ietf-dkim-rfc4871bis-15)
--
Title   : DomainKeys Identified Mail (DKIM) Signatures
Publication Date: September 2011
Author(s)   : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
Category: DRAFT STANDARD
Source  : Domain Keys Identified Mail
Area: Security
Stream  : IETF
Verifying Party : IESG

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

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

[Dave Crocker]

On 9/26/2016 12:15 PM, RFC Errata System wrote:

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

Notes
-
sig-q-tag-methods are ":"-separated in sig-q-tag, so ":" shouldn't be permitted
within x-sig-q-tag-args.  Note that qp-hdr-value (which I believe was originally
defined for sig-z-tag, which includes "|"-separated values) is defined as



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?


But basically, yeah, this looks to me like something needing to be fixed.

d/



--

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

Re: [ietf-dkim] Fwd: [Lurk] Another outside the "box" use case: DKIM

[Dave Crocker]

On 4/21/2016 11:50 AM, John Levine wrote:
> The reason DKIM doesn't have the LURK problem is that the key issuer
> directly controls the verification key with no intermediary doing
> certification.


The text I was commenting on cited an issue with handing out "my private 
key".  That DKIM might have other benefits is nice, and might be added 
benefits, they weren't the issue that was raised.


d/
-- 

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

Re: [ietf-dkim] Fwd: [Lurk] Another outside the "box" use case: DKIM

[Dave Crocker]

On 3/2/2016 1:35 AM, Stephen Farrell wrote:
> LURK is an IETF mailing list that's discussing developing a
> solution to the "offload TLS without giving the CDN my private
> key" problem.


The premise seems to be that there is a single private key.

DKIM permits an arbitrary of private keys to be associated with the 
domain name.  So assigning one solely for use by a third-party -- and 
deciding when to terminate it -- is convenient and carries no effect on 
other uses.

d/

-- 

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

Re: [ietf-dkim] DKIM Key Size Constraints

[Dave Crocker]

On 5/12/2015 10:25 PM, Roland Turner wrote:
 On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:
 
 https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with 
 what I'm saying above.  When talking about unacceptably small keys, 
 the unacceptable decision is not made by the protocol, but by the 
 receiver.
 
 +1


(I haven't been tracking this thread in detail, so please forgive my
missing some nuance.)


I think the issue separates between 'interoperability' vs. 'usage
policy'.  The former is the protocol.  The latter is either
Internet-wide BCP or local policy, depending upon strong community
consensus.

I did a quick search for (rfc ietf minimum key size cryptograph) and
found a series of RFCs that do indeed talk about minimum key size.  All
of them are Informational, rather than standards track or BCP.

As a non-crypto-geek, the solid constant I've observed is that crypto
algorithm and key size choices are highly malleable:  they change over
time.  So a protocol needs some agility with respect to these and MUST
NOT be locked in too tightly.

DKIM is algorithm-agile.  It needs to also be key-length-agile.

If there is strong community consensus on the choices of algorithm and
key-length, it needs to be asserted as an operational convention, not in
the base protocol

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

[ietf-dkim] Error in RFC 5321 concerning SPF and DKIM

[Dave Crocker]

(re-posted to DKIM list, but please reply to smtp mailing list. d/)


Hi folks.

I submitted an Errata on RFC 5321 that was rejected due to logic that is
proving a bit challenging to understand.

 http://www.rfc-editor.org/errata_search.php?eid=4055

So I thought I'd check with the SMTP, SPF and DKIM communities to get
some broader review for the substantive issue, before considering
alternative process paths.

Simply put:

 RFC 5321 has some text about SPF and DKIM that is
 simply wrong.

 Given the continuing community confusion about what
 SPF and DKIM do and do not do, I think that having
 the SMTP document perpetuate erroneous views is
 significantly problematic.

I've checked the archive of around the time the text was introduced.
Other that a brief exchange about the 'nature' of DKIM, I don't see any
messages on this topic.

I'd appreciate comments on the factual issues here.  I don't want to
discuss the Errata process.  Just the technical issues.

If folks think my characterization of the error is either correct or
incorrect, please say so and explain.  If you think it can be documented
better, please offer text!


(I've BCC'd the SPF and DKIM lists, to make sure that everyone there
sees this.  But please post any followups to the SMTP list.)


Thanks!

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

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

[Dave Crocker]

On 10/20/2013 3:50 PM, Tony Hansen wrote:
 Perhaps, if this document is ever cracked open again, it would be useful
 to tag things better to make it painfully obvious what is being
 discussed. For example,

  v= [Signature] Version (plain-text; REQUIRED) ...


Within the definition text, perhaps.

However we could develop a referential norm, independent of that, and 
then call for its use whenever docs are modified.  Something like the 
email header naming convention would make sense.

Hence:

   Signature.v =

   Key.h =

d/

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

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

[Dave Crocker]

On 10/20/2013 4:00 PM, Tony Hansen wrote:
 Use a - and I agree completely with this naming convention:

  Signature-v =

  Key-h =

 (Rulenames can use a hyphen, but not a period.)


was staying with the email header field notational form and hadn't 
thought to make it work in the bnf, but sure, why not.

d/


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

Re: [ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

[Dave Crocker]

On 9/12/2013 12:20 PM, Jim Fenton wrote:
 This might be the right thing to do, but it seems like the more
 appropriate time might be to do this when DMARC becomes standards-track.

1. There is not going to be any change the adoption of ADSP between now 
and then.

2. I don't see any obvious reason for linking them.  The mere fact that 
they are playing in roughly the same sandbox does not provide any 
obvious requirement for fate-sharing that I can see.

3. IF DMARC is never standardized, it still makes sense to deprecate ADSP.


 I will note that vanilla, uncustomized SpamAssassin does implement ADSP,
 so there might be more checking of ADSP records than some realize.  See,
 for example:

   http://wiki.apache.org/spamassassin/Rules/DKIM_ADSP_CUSTOM_MED

There seems to be a pattern that has developed, of demanding that 
failure mean literally no adoption.  It doesn't mean that.  It means 
that it has no community traction.  ADSP more than qualifies on the 
pragmatics of failure.

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

[ietf-dkim] Fwd: Request to move RFC 5617 (ADSP) to Historic

[Dave Crocker]

Folks,

Barry has agreed to sponsor the enclosed status change.

He would like to see discussion formal request.

(If you've already responded to my /in/formal query earlier today on the 
dmarc@ietf list, please now lodge any formal comments you wish to make 
on either of the two lists here.

d/


 Original Message 
Subject: Request to move RFC 5617 (ADSP) to Historic
Date: Wed, 11 Sep 2013 16:09:14 -0700
From: Dave Crocker dcroc...@bbiw.net
Organization: Brandenburg InternetWorking
To: Barry Leiba barryle...@computer.org,  Pete Resnick 
resn...@episteme-software.com

Folks,

This is a formal request, to have DomainKeys Identified Mail (DKIM)
Author Domain Signing Practices (ADSP) (RFC 5617) moved to Historic status.

It has garnered almost no deployment and use, in the 4 years since its
advancement to IETF Proposed Standard.

In addition, newer work, DMARC, covers the same general email functional
area and already has garnered quite a bit of deployment and use. Hence
it will clarify things for the marketplace to remove standards status
from the apparently-competing, but actually-useless ADSP specification.

Today I sent a query to the MAAWG Technical committee and the IETF DMARC
mailing lists, to assess support for the status change. Within only a
few hours, I've already seen quite a few +1s, and no -1s.

Thanks.


d/

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

Re: [ietf-dkim] [apps-discuss] Fwd: Request to move RFC 5617 (ADSP) to Historic

[Dave Crocker]

On 9/11/2013 6:41 PM, Michael Thomas wrote:
 It doesn't help that ADSP's author actively wanted to subvert it.

 As far as I can tell, DMARC is warmed over ADSP with a different set of 
 participants
 to claim credit for their original ideas.


I don't understand how these assertions are at all relevant to this 
thread, nor the first at all within IETF participation guidelines.

d/

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

Re: [ietf-dkim] STD 76, RFC 6376 on DomainKeys Identified Mail (DKIM) Signatures

[Dave Crocker]

On 7/11/2013 12:48 PM, rfc-edi...@rfc-editor.org wrote:
 RFC 6376 has been elevated to Internet Standard.

cool.  congrats to us all.

d/

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

Re: [ietf-dkim] Weird i= in client mail

[Dave Crocker]

On 6/20/2013 10:00 AM, Jon Callas wrote:
 It has many potential uses, but within DKIM itself, it's an expansion socket.


I tend to characterize it as an opaque cookie.

d/

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

[ietf-dkim] value-added DKIM-ish enhancements )was - Re: Weird i= in client mail)

[Dave Crocker]

On 6/18/2013 7:18 AM, Tony Hansen wrote:
 I always thought it would be a nice follow-on to DKIM to provide a way
 for a site to specify how that site was using i=; that is, to provide
 some clarity and comprehension for that value. For example, our
 implementation placed the authenticated userid into i=. I know of one
 site that appears to use a hash of the authenticated userid. John L says
 his site uses how the mail was injected (submit, webmail, whatever) and
 who the user was if it knows. When there is a deterministic mechanism
 used to create i=, and the mechanism is known, then it is possible for
 additional logic to be added to the receiving side as well.


I'm sure Tony already knows this, but just to make sure it's part of the 
thread:

  Anyone can define a value-added protocol layer on top of DKIM.  It 
can define all sorts of additional semantics.

  It needs a method of declaring its presence, such as an extra 
header field or a special external query, but after that, it's free to 
define anything it wants, including a public meaning for i=

One could, for example, imagine a layer that asserts that the domain in 
the rfc5322.From field MUST match the domain in the DKIM d= field, or at 
least have an organizational domain match (that is, match at the name 
portion that was delegated by a registry.

Oh, wait.  That's DMARC.

See?  It's possible.

d/


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

Re: [ietf-dkim] Weird i= in client mail

[Dave Crocker]

On 6/17/2013 2:36 PM, Laura Atkins wrote:
 I am in the process of reviewing the technical setup of a client
 installation. This client is using the VERP string (Return Path /
 Envelope From) in the i= of their DKIM signature.

 The signature looks like this:

 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; s=ci;
 d=inbox.example.com;
 i=verpprefix-laura=2dinterdirect=40wordtothewise.com-2979-83348823-24644-bou...@inbox.example.com;


h=content-type:mime-version:subject:list-unsubscribe:reply-to:to:from:date:message-id;
 bh=HbLebYQFYQmYej07DLVID9lCjc8=;

 Based on my understanding of DKIM, this isn't necessarily violating
 the DKIM spec, but it does seem to be not the right thing to use for
 the i= value

My understanding of i= semantics is that it has no formal meaning except 
to its creator.[1]  As long as the syntactic form is followed, it is 
acceptable for it to contain anything.[2]

At which point I'd expect the constraints to be privacy and utility, 
according to whatever criteria the creator wishes to invoke.


 I'm thinking my client should stop doing this, just because it really
 seems wrong but I have no justification for recommending that other
 than that can't be right.

 I haven't been able to find anything that discusses the intention
 behind the i=. I expect they chose this i= because that's the
 envelope from, but the i= is suppose to be a person, not a mechanical
 address, correct?

Different people had different intentions for i=, over the course of i= 
development.  Basically, the original spec promoted some confusion on 
its role and the role of d=.  We followed up with an effort to 
explicitly resolve this.  The above statement summarizes my 
understanding of the result, for i=.

d/


[1]  That is, pretty much the i= value is only useful for returning to 
the creator.  One can imagine utility when a receiver is interacting 
with the originator in problem handling, for example.

[2]  And, of course, there's the constraint: The domain part of the 
address MUST be the same as, or a subdomain of, the value of the d= 
tag.  But I'd consider that a minor point, for the kind of question 
being asked here.

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

Re: [ietf-dkim] Weird i= in client mail

[Dave Crocker]

On 6/17/2013 9:20 PM, Franck Martin wrote:
 On Jun 17, 2013, at 8:58 PM, John Levine jo...@taugh.com wrote:
 At one stage i= was thought to represent different mail streams with 
 different reputation,
 however this did not get any traction...
...
 The question was raised and dispelled on 
 http://blog.wordtothewise.com/2007/10/dkim-i-equal-vs-d-equal/, proving the 
 idea was in the air, and I read it in some deliverability documents in the 
 early days (tho wrong too)...


As I said, there were a variety of intentions, descriptions, desires and 
claims for i=.  Different people had different views.  None of the 
alternatives was in the spec and therefore none were standardized.

d/


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

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

[Dave Crocker]

On 7/23/2012 8:20 AM, Murray S. Kucherawy wrote:
 On Mon, Jul 23, 2012 at 7:28 AM, Dave Crocker d...@dcrocker.net
 mailto:d...@dcrocker.net wrote:

 Here are two small tweaks that might correct things:

y  This domain is testing DKIM.  Verifiers MUST NOT treat
 messages
   from Signers in testing mode differently from unsigned email.
   This covers both successful and failed verification.
   Verifiers MAY wish to track and report testing mode results to
   assist the Signer.


 This isn't quite right, I think.  For a signed message that verifies, a
 negative reputation should still be considered applicable.  A positive
 one should not.  That's not equivalent to unsigned.


Verification doesn't matter.

Again, the current normative text is straightforward and reads:

 Verifiers MUST NOT treat messages from Signers in testing mode 
differently from unsigned email,...

That's an absolute.  It's does not depend upon whether the signature 
validated or didn't validate.  It says that the processing of the 
signature is not to affect the handling behavior.

All I did with the modifications is to add some brute force assurance 
that the reader will not misinterpret or miss criteria or implications. 
  The changes do not change the existing semantics.

d/

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

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

[Dave Crocker]

On 7/21/2012 9:50 PM, Murray S. Kucherawy wrote:
 That customer brought up an interesting point.  t=y could also be
 useful for messages whose signatures do verify.  Specifically, it could
 be used by a signer to say It's possible this message shouldn't have
 been signed by us.  Please don't give it any preferential treatment
 based on our name's reputation if the signature verifies, which could
 then tarnish our reputation.


When Murray and I talked, I didn't review the existing text.  Having 
just done that:

t= Flags, represented as a colon-separated list of names (plain-
   text; OPTIONAL, default is no flags set).  Unrecognized flags MUST
   be ignored.  The defined flags are as follows:

   y  This domain is testing DKIM.  Verifiers MUST NOT treat messages
  from Signers in testing mode differently from unsigned email,
  even should the signature fail to verify.  Verifiers MAY wish
  to track testing mode results to assist the Signer.

I see that its semantics already cover the case that is being discussed, 
specifically with the core clause:  Verifiers MUST NOT treat messages 
from Signers in testing mode differently from unsigned email,...

That any reader does not readily see this suggests to me that some 
clarification language would be useful to apply, as well as an 
annotation about report.

The clarification attempted in the remainder of that sentence appears to 
cause readers to think that successful verification is excluded!

Here are two small tweaks that might correct things:

   y  This domain is testing DKIM.  Verifiers MUST NOT treat messages
  from Signers in testing mode differently from unsigned email.
  This covers both successful and failed verification.
  Verifiers MAY wish to track and report testing mode results to
  assist the Signer.


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

[ietf-dkim] Announce: Maturing DMARC implementations through an interoperability event

[Dave Crocker]

Maturing DMARC implementations through an interoperability event...


At the end of January, the DMARC (Domain-based Message Authentication, 
Reporting  Conformance) specification was publicly announced with 
extensive media coverage, blog posts and discussion. Since that time 
various folk have been working on writing code for DMARC validators and 
report parsers. The dmarc-discuss list has been active, as various 
questions and issues have been clarified.


Now it is time to see how well implementations play together in live 
testing.


The DMARC Interopability event has been announced:

http://dmarc.org/interop_event.html

When:   July 19-20, 2012
Where:  Menlo Park California

As with previous interoperability events for other specifications such 
as DKIM, the event for DMARC will help people who write running code to 
work with other implementers, to tease out any interoperability issues.

If you are writing and implementing DMARC code this is an event you 
shouldn’t miss.


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

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

[Dave Crocker]

+1


/d

--

Dave Crocker
bbiw.net



-Original Message-
From: Barry Leiba barryle...@computer.org
To: RFC Errata System rfc-edi...@rfc-editor.org
Cc: dcroc...@bbiw.net dcroc...@bbiw.net, tony+dki...@maillennium.att.com 
tony+dki...@maillennium.att.com, m...@cloudmark.com m...@cloudmark.com, 
stephen.farr...@cs.tcd.ie stephen.farr...@cs.tcd.ie, turn...@ieca.com 
turn...@ieca.com, barryle...@computer.org barryle...@computer.org, 
john.hawth...@gmail.com john.hawth...@gmail.com, ietf-dkim@mipassoc.org 
ietf-dkim@mipassoc.org
Sent: Sat, 14 Apr 2012 3:25 PM
Subject: Re: [Technical Errata Reported] RFC6376 (3192)

I've checked this, and it's correct.  We copied the examples from 4871, and
made the editorial error of adding a space without changing the hash.  I'll
mark it as Verified if i hear no objections soon.

Barry

On Saturday, April 14, 2012, RFC Errata System wrote:


 The following errata report has been submitted for RFC6376,
 DomainKeys Identified Mail (DKIM) Signatures.

 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6376eid=3192

 --
 Type: Technical
 Reported by: John Hawthorn john.hawth...@gmail.com javascript:;

 Section: Appendix A

 Original Text
 -
   From: Joe SixPack j...@football.example.com javascript:;
   To: Suzie Q su...@shopping.example.net javascript:;
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: 20030712040037.46341.5...@football.example.comjavascript:;
 

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

 Corrected Text
 --
   From: Joe SixPack j...@football.example.com javascript:;
   To: Suzie Q su...@shopping.example.net javascript:;
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: 20030712040037.46341.5...@football.example.comjavascript:;
 

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

 Notes
 -
 This text appears three times, in A.1., A.2., and A.3.
 Notice the double space after game., which renders the body hashes from
 A.2. and A.3. invalid.
 The corrected text is the same as that in RFC 4871.

 Instructions:
 -
 This errata is currently posted as Reported. If necessary, please
 use Reply All to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary.

 --
 RFC6376 (draft-ietf-dkim-rfc4871bis-15)
 --
 Title   : DomainKeys Identified Mail (DKIM) Signatures
 Publication Date: September 2011
 Author(s)   : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
 Category: DRAFT STANDARD
 Source  : Domain Keys Identified Mail
 Area: Security
 Stream  : IETF
 Verifying Party : IESG

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

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

[Dave Crocker]

raises a small question of needing notes to the editor advising hands off for 
such segments.


/d

--

Dave Crocker
bbiw.net



-Original Message-
From: Barry Leiba barryle...@computer.org
To: Barry Leiba barryle...@computer.org
Cc: RFC Errata System rfc-edi...@rfc-editor.org, dcroc...@bbiw.net 
dcroc...@bbiw.net, tony+dki...@maillennium.att.com 
tony+dki...@maillennium.att.com, m...@cloudmark.com m...@cloudmark.com, 
stephen.farr...@cs.tcd.ie stephen.farr...@cs.tcd.ie, turn...@ieca.com 
turn...@ieca.com, john.hawth...@gmail.com john.hawth...@gmail.com, 
ietf-dkim@mipassoc.org ietf-dkim@mipassoc.org
Sent: Sat, 14 Apr 2012 3:30 PM
Subject: Re: [Technical Errata Reported] RFC6376 (3192)

FWIW, the error was introduced by the RFC Editor, who surely used
double-space-between-sentences style, and didn't know that in that
particular case, the space matters.  And we didn't notice it in AUTH48
reviews.  Something we need to remember to check for, in the rare cases
where it does matter.

Barry

On Saturday, April 14, 2012, Barry Leiba wrote:

 I've checked this, and it's correct.  We copied the examples from 4871,
 and made the editorial error of adding a space without changing the hash.
  I'll mark it as Verified if i hear no objections soon.

 Barry

 On Saturday, April 14, 2012, RFC Errata System wrote:


 The following errata report has been submitted for RFC6376,
 DomainKeys Identified Mail (DKIM) Signatures.

 --
 You may review the report below and at:
 http://www.rfc-editor.org/errata_search.php?rfc=6376eid=3192

 --
 Type: Technical
 Reported by: John Hawthorn john.hawth...@gmail.com

 Section: Appendix A

 Original Text
 -
   From: Joe SixPack j...@football.example.com
   To: Suzie Q su...@shopping.example.net
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: 20030712040037.46341.5...@football.example.com

   Hi.

   We lost the game.  Are you hungry yet?

   Joe.

 Corrected Text
 --
   From: Joe SixPack j...@football.example.com
   To: Suzie Q su...@shopping.example.net
   Subject: Is dinner ready?
   Date: Fri, 11 Jul 2003 21:00:37 -0700 (PDT)
   Message-ID: 20030712040037.46341.5...@football.example.com

   Hi.

   We lost the game. Are you hungry yet?

   Joe.

 Notes
 -
 This text appears three times, in A.1., A.2., and A.3.
 Notice the double space after game., which renders the body hashes from
 A.2. and A.3. invalid.
 The corrected text is the same as that in RFC 4871.

 Instructions:
 -
 This errata is currently posted as Reported. If necessary, please
 use Reply All to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party (IESG)
 can log in to change the status and edit the report, if necessary.

 --
 RFC6376 (draft-ietf-dkim-rfc4871bis-15)
 --
 Title   : DomainKeys Identified Mail (DKIM) Signatures
 Publication Date: September 2011
 Author(s)   : D. Crocker, Ed., T. Hansen, Ed., M. Kucherawy, Ed.
 Category: DRAFT STANDARD
 Source  : Domain Keys Identified Mail
 Area: Security
 Stream  : IETF
 Verifying Party : IESG


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

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

[Dave Crocker]

On 4/16/2012 8:10 AM, RFC Editor wrote:
 Just a heads up that we will be reviewing this one internally with the
 team to raise our awareness of the issue.  Additionally, we agree with
 Dave, and encourage the inclusion of notes to help avoid such errors
 in the future.   


My guess is that the existing notation for communicating inline to the RFC
editor is sufficient.  That is, I'd expect the real issue being one of getting
us all to tell you what not to format, rather than one of creating a new 
notation.

d/
-- 

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

Re: [ietf-dkim] Doublefrom language should be in ADSP, not core

[Dave CROCKER]

On 7/10/2011 7:51 PM, Murray S. Kucherawy wrote:
 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Scott Kitterman
 Sent: Sunday, July 10, 2011 6:46 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Doublefrom language should be in ADSP, not core

 I think we should make it clear that singleton header fields like From (and
 Subject and Date) can be added without breaking signatures unless one is
 careful as a signer and/or a verifier.  This is related to a core DKIM design
 principle and doesn't need ADSP (or other non-standard measures) for it to be
 something we should care about.

 I think the language we've proposed in response to the DISCUSS covers this 
 appropriately.


+1

d/
-- 

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Dave CROCKER]

On 7/8/2011 6:48 AM, Murray S. Kucherawy wrote:
 If DKIM is not intended to give added credance to messages, then what on
 earth is its purpose at all.

 That question is answered numerous times in the draft, namely the Abstract 
 and Sections 1, 1.2, 1.5, 2.5, 2.7, 3.9, 3.11, 6.3, and 8.15 (and other parts 
 of 8).


Perhaps I'm missing something basic that makes clear the value of this thread?

Hashing and re-hashing first principles of DKIM hardly seems useful, at this 
stage.  If someone has trouble understanding the specification, this forum is 
not intended for tutorials, particularly not tutorials that constantly repeat 
first principles.

d/
-- 

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Dave CROCKER]

On 7/8/2011 6:54 AM, Murray S. Kucherawy wrote:
 That's not part of what DKIM tells an assessor, nor is the list of signed 
 header fields, so I don't see why that would be a useful thing to highlight.  
 For example, if a message contains two Subject: fields, the assessor doesn't 
 know which was signed; could be neither.  It still gets an SDID out of the 
 verification and nothing more (possibly not even that if the signature 
 failed).


It simply is not productive to pursue terse, abstract claims of threats, absent 
detailed technical description, detailed explanation of how it is relevant to 
DKIM, and some indication of concern for that threat among a range of people

The main effect of responding to isolated, terse concerns is to create a record 
that can be read as giving credence to those threats.

d/
-- 

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Dave CROCKER]

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.

d/
-- 

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Dave CROCKER]

On 7/7/2011 6:57 AM, Murray S. Kucherawy wrote:
 I'd s/to be liberal/to be exceedingly liberal/ (we don't want to revise
 Postel's statement, do we?)

 You're either liberal in your application of the RFCs, or you're not.  I
 don't see how adding that word improves things here.

well, it keeps the thread going...


 DKIM signs and validates the data it is told to and works correctly. So
 in this case, DKIM has done its job of delivering a validated domain (the
 d= value) and, given the semantics of a DKIM signature, essentially the
 signer has taken some responsibility for a problematic message.  It is up
 to the identity assessor or some other subsequent agent to act on such
 messages as needed, such as degrading the trust of the message (or,
 indeed, of the signer), or by warning the recipient, or even refusing
 delivery.

 I'd omit any allegation on what an assessor's needed actions might be.

 Such as makes it clear these are only possible actions (and the obvious
 ones).  It's not an exhaustive list.

Huh?  You mean that listing examples is not the same thing as specifying 
directives or even similar to implying obligation?

You mean, an example is merely and example of what is possible?  As in... 
example.

gosh.


 (Actually, we'd need yet another policy or authentication method in order
 to allow the outcome of an identity assessor to be formally expressed.
 Without it, the quick-n-dirty approach of degrading the trust of a message
 by tampering with its DKIM verification's results may seem the easiest
 remedy --much like what Doug et al. proposed.)

 If the role of the identity assessor is reputation, and we decide later that
 we want reputation to be relayed to downstream agents, we can extend RFC5451
 by such a registration then.  It doesn't make sense to do it here though.

It might make a great deal of sense to do it here, if we were specifying a 
tightly integrated, inflexible, and self-contained end-to-end reputation 
service.

But since we aren't, modularity of specification scope is the norm for a reason.


 An agent consuming DKIM results needs to be aware that the validity of
 any header field, signed or otherwise, is not guaranteed by DKIM.

 Please, s/validity/reliability/: someone might believe a field is valid if
 it retains the value that was given to it originally.

  Isn't that conclusion precisely what this sentence is countering?

The word reliability has no meaning in this context.  On the other had, 
misunderstandings about implied or actual data validity is /exactly/ the issue 
this text is /intended/ to cover.

d/
-- 

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Dave CROCKER]

On 7/7/2011 7:18 AM, John R. Levine wrote:
 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.


no you wouldn't.

d/
-- 

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Dave CROCKER]

On 7/7/2011 12:41 PM, John R. Levine wrote:
 Oh yes there is! Because identity assessors will undoubtedly give more
 credence to messages where the signature domain is the same as the author
 (i.e.From:) domain, ...

 My spam filters don't do that.


as well they shouldn't.

Somehow, validating a From: field of bad-ac...@bad-host.example.com does 
provide 
any obvious basis for giving more 'credence' to the trustworthiness of the 
author or the message content.

but this does raise the question of how many times this point needs to be made?

d/
-- 

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

Re: [ietf-dkim] Final update to 4871bis for working group review

[Dave CROCKER]

On 7/6/2011 11:34 AM, Murray S. Kucherawy wrote:
 As Pete has pointed out -- and has he's adamant about -- the signer can't
 attack... that is, DKIM can't do anything about attacks by the signer.
 And that's as Charles's text itself points out.  So I'd be

The signer can attack the receiver, of course.

The signer cannot attack the DKIM mechanism.  Attacking the mechanism has to do 
with working around the mechanism.  Semantically, that is only meaningful as 
done by independent third-parties.  Not a principal in the use of the mechanism.


 Interesting side note: Given the reference to Postel's Law being
 not-such-a-good-idea-after-all,

Postel's law is generally misapplied from what he intended.

It is mis-used as an excuse for sloppy and overly permissive specification and 
for inaccurate implementation, neither of which were what Jon intended.

He was attempting to cover only those cases in which reasonable specifications 
are subject to some variance in interpretation, resulting in a degree of 
difference in implementation.

As such, it's a dandy rule.


 Anyway, with a few nitty edits from me as well, here's the current 8.15 for
 -15 for everyone's consideration.  I concur with Barry with respect to the
 DISCUSS complaint about who's attacking what.

+1


 Also, the second paragraph
 already alludes to the fact that multiple From: fields is a problem
 regardless of whether or not one of them is signed.  I think it covers the
 bases and flows nicely.

+1

d/
-- 

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

Re: [ietf-dkim] Pete's review of 4871bis

[Dave CROCKER]

On 6/29/2011 9:40 AM, John R. Levine wrote:
 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.


Well, perhaps you are right.

After all, the group's ability to make decisions about changes, it's enthusiasm 
for such an effort and the community's demonstrated problems with the 
problematic text are all clear enough to easily justify our continuing to 
expend 
significant effort and to further delay publication of this document.

Not.

d/

-- 

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

Re: [ietf-dkim] Pete's review of 4871bis

[Dave CROCKER]

On 6/29/2011 11:49 AM, Pete Resnick wrote:
 Now*that's*  the attack. But it's NOT AN ATTACK ON DKIM! It's an attack


So?

The original directive to produce a threats analaysis was for threats to 
recipients that DKIM might help remedy.

Clearly, techniques later designed to circumvent or exploit DKIM weaknessare 
also relevant, but they aren't the only attacks that are relevant here.  Also, 
I'm just guessing that that's what you mean by attack on DKIM.

If I missed it, I apologize, but have you define what you mean by attack on 
DKIM?  And why is it important to distinguish which category an attack falls 
into?

d/

-- 

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

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

[Dave CROCKER]

On 6/27/2011 10:51 AM, Murray S. Kucherawy wrote:
 We should have the DKIM signing specification normatively require
 checking for every known technique, since we cannot be sure that any
 other part of the system will perform the necessary checks.

 +100

 But sadly the consensus of this WG was otherwise :-(

 Mmm, I think Dave was being sarcastic.


Dave thinks so, too.

Dave even thought that was pretty obvious, but Dave should have known better.

The term for the class of exercise I described is boiling the ocean... 
Alternatively is requires already knowing what is not known.

d/

-- 

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

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

[Dave CROCKER]

On 6/24/2011 5:55 AM, John R. Levine wrote:
 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,
...


Let's simplify this discussion:

Spammers do a variety of techniques to trick filters and users.

We should have the DKIM signing specification normatively require checking 
for every known technique, since we cannot be sure that any other part of the 
system will perform the necessary checks.

d/
-- 

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

Re: [ietf-dkim] I-D Action: draft-ietf-dkim-rfc4871bis-11.txt

[Dave CROCKER]

On 6/15/2011 10:19 AM, internet-dra...@ietf.org wrote:
 A New Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Domain Keys Identified Mail 
 Working Group of the IETF.

   Title   : DomainKeys Identified Mail (DKIM) Signatures
   Author(s)   : D. Crocker
Tony Hansen
M. Kucherawy
   Filename: draft-ietf-dkim-rfc4871bis-11.txt
   Pages   : 78
   Date: 2011-06-15


Folks,

Small reminder...

The datatracker:

https://datatracker.ietf.org/doc/draft-ietf-dkim-rfc4871bis/

now automatically provides a copy of a diff between the new version and the 
previous version:

http://tools.ietf.org/rfcdiff?url2=draft-ietf-dkim-rfc4871bis-11

d/
-- 

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

Re: [ietf-dkim] New canonicalizations

[Dave Crocker]

Steve Atkins st...@wordtothewise.com wrote:


On May 30, 2011, at 3:23 PM, Murray S. Kucherawy wrote:
 or at least the chain-of-trust capability, but no proof that the
increased risk is worth the increased gain.

Chain of trust is a somewhat different thing, and could likely be
implemented with little, if any, increased risk in the case where the
MLM is trusted (for some meaning of the word that probably boils down
to manual whitelist or positive reputation of the MLM operator) by the
recipient.

The MLM signing the re-sent message, including an A-R header or some
slight variant, is the obvious way. I don't think there's much gain to
be had there, but it can be done with little effort and little risk.

Chain of trust is always an appealing model.  Unfortunately, it hasn't been 
used successfully over the open Internet.  The closest we are coming to having 
an example of its working is DNSSec, which actually has a very, very 
constrained model and relatively short chain.  It's utility as a demonstration 
of success is also very new.  It's not a 'complete' example.

There is a tendency to believe that operational changes are preferred over 
protocol changes.  That's essentially the difference between formulatng a model 
of trusting the sequence of message handlers, versus devising an authentication 
technique that survives the sequence of handlers.

Unfortunately, operational changes for security tend to make a more fragile 
model.



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

Re: [ietf-dkim] MLMs and signatures again

[Dave CROCKER]

On 5/26/2011 1:29 PM, John R. Levine wrote:
 In my experience, the reputation of the list is unrelated to the reputation of
 its participants.


Given how little DKIM-related reputation work has been done, deployed and 
heavily used so far, perhaps we should all be a bit cautious about taking 
existing practices and treating them as definitive of future needs and uses.

d/
-- 

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

Re: [ietf-dkim] New canonicalizations

[Dave CROCKER]

On 5/25/2011 9:59 AM, John Levine wrote:
 The idea is to anticipate any unknown signature breaker.

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

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

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

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

d/

-- 

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

Re: [ietf-dkim] 8bit downgrades

[Dave CROCKER]

On 5/24/2011 3:34 PM, John R. Levine wrote:
 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.


Maybe yes, maybe no.

That actally means definitely yes, for some scenarios.  The maybe no means that 
it might not occur for some others.

One possibility is that the two paths are distinguished by near-term vs. 
long-term, assuming one believes that 'near-term' is a useful construct when 
projecting Internet-scale transitions of infrastructure service...

d/

-- 

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

Re: [ietf-dkim] New canonicalizations

[Dave CROCKER]

On 5/23/2011 10:26 AM, Murray S. Kucherawy wrote:
 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.

 So assuming it's a useful endeavour, it seems to me there's a lot of work to
 be done here.

Let's make it be the right work.

To make a canonicalization algorithm that is more robust -- such as having it 
based on canonical forms of data, independent of encoding -- makes some sense. 
Trying to create the ability to reverse changes strikes me as far to complex 
and fragile to be reasonable.

d/
-- 

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

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

[Dave CROCKER]

On 5/22/2011 10:43 AM, John R. Levine wrote:
 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?

(Note that you are the one who introduced the construct of certifying a 
message.)

In any event, there always needs to have an independent means of authenticating 
that a statement by a third party really is by them, whether it is through 
querying a portion of the DNS they own or by using their domain name to verify 
something in a message.  So they probably /will/ add their own DKIM signature.

But that's quite different from adding a signature with the domain of the 
organization producing the message, since this latter is the subject of the 
reputation/certification.  (One could design this to remove the need for the 
latter signature, even while still including their domain name, I suppose.)

The bottom line to this sort of exchange is that it seems pretty clear that as 
a 
community we are not clear about concepts or details for this topic.  That one 
or another person thinks one or another issue has an obvious answer is turning 
out to be a poor indicator of actual community understanding or agreement.


As an impressive example of even deeper misunderstanding:

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



 But this is exactly what DKIM is. You prove yourself fsvo prove
 to the registrar who certifies you by virtue of placing your NS
 records in the root servers instead of issuing a cert. Nothing
 different in *essence* to x.509 certs.

DKIM has almost literally nothing to do with proofs made to a DNS registrar. 
For example, it says nothing about the relationship between a domain name and a 
brand or company name.

DKIM merely says that who ever owns use of a domain name is asserting some 
responsibility for the signed message.

In extremely abstract terms, a DKIM signature relates to a reasonably constant 
construct that one might call an identity but it does not label the identity, 
except with the domain name.

More importantly, there are none of the claims, assertions or endorsements that 
go along with Certs, except for the mild one noted above.

One would have expected a former author of the spec who so-often proclaims 
their 
expertise to understand the semantics of DKIM better.  On the other hand, it 
does nicely show that implementing code doesn't mean understanding what it is 
for...

d/

-- 

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

Re: [ietf-dkim] 8bit downgrades

[Dave CROCKER]

/
-- 

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

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

[Dave CROCKER]

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

 It seems to me this is a bullseye for what VBR is capable of providing.


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

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

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

d/
-- 

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

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

[Dave CROCKER]

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

 I don't see how this is functionally different from VBR. In both cases the
 signer assserts that the message is certified by foo.

Sorry, no.

VBR queries are about an actor, not a message.

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

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


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

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


d/

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

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

Re: [ietf-dkim] 8bit downgrades

[Dave CROCKER]

On 5/19/2011 7:34 PM, Michael Thomas wrote:
  Since dev
 managers literally looks at MUST's and SHOULD and ignore
 MAY's to determine what gets implemented, this is not
 quite as academic.


That's a rather significant assessment.  It means that all of the Internet 
specifications done for the last 20 or 30 years, that have had the 'MAY' 
qualifier were wasting their effort.

It's odd that working groups continue to use the construct, since you claim it 
is not at all useful for the software that implements the specifications.

Such a basic claim warrants understanding its basis.  Please share it.

d/

-- 

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

Re: [ietf-dkim] Section 3.7 s/content-hash/body-hash/?

[Dave CROCKER]

On 5/17/2011 1:54 PM, Murray S. Kucherawy wrote:
 Shouldn't it say

 More formally, pseudo-code for the signature algorithm is: body-hash =
 hash-alg (canon-body limited by l-param) data-hash=  hash-alg
 (h-headers, D-SIG with body-hash) signature=  sig-alg (d-domain,
 selector, data-hash)

 where:

 body-hash:   is the output from hashing the body, using hash-alg. It is set
 as the value of the bh= tag in D-SIG for computing the data-hash.

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

Right.  This was my error.  the 'content' string was a carry-over from my 
attempt to define DKIM
in terms of Doseta.  I tried to do string replacements but missed this one.


 The remaining changes are inconsistent with the rest of the section or don't
 clarify anything.  For example, the hash-alg function on the body-hash line
 takes the canonicalized body and the l-param as inputs, and produce the
 body-hash.  Thus, that expression is correct as-is.

Not merely inconsistent.  The existing text specifies parameters to routines
that do internal processes.  This is a standard form for specifying interfaces.

The proposed change tries to move some of the processing into the parameter, and
hence is not an interface specification (unless, for example, the goal is to
tell the caller to truncate the body, rather than have the subroutine do the
truncating.

d/

-- 

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

Re: [ietf-dkim] New canonicalizations

[Dave CROCKER]

On 5/16/2011 9:00 AM, John R. Levine wrote:
 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.


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.

The problem is that the working group was not able to develop a... workable... 
canonicalization algorithm to achieve this complete robustness.  In the 
extreme, 
this is a research topic.  Certainly it is a delicate engineering tasks, since 
too much robustness against change can easily introduce security holes.

But, then, that's why the working group debate the issue so extensively and the 
result did gain working group consensus.

Since the list of algorithms is defined to be extensible, anyone feeling that 
an 
additional algorithm is warranted is free to define it and seek community 
consensus for it.

d/

-- 

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

Re: [ietf-dkim] discardable, was Last Call: draft-ietf-dkim-mailinglists-10.txt (DKIM And Mailing Lists) to BCP

[Dave CROCKER]

On 5/16/2011 8:22 AM, John R. Levine wrote:
 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
...
 The definition in the RFC was hammered out after a great deal of debate,
 and I see no evidence that the definition is defective.


+1 to the -1.

d/

-- 

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

Re: [ietf-dkim] New canonicalizations

[Dave CROCKER]

On 5/16/2011 9:36 AM, John R. Levine wrote:
 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.


absent a standards-track specification for it being adopted, it's not 
interoperable.

d/

-- 

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

Re: [ietf-dkim] New canonicalizations

[Dave CROCKER]

On 5/16/2011 10:40 AM, Mark Delany wrote:
 On 16May11, Alessandro Vesely allegedly wrote:
 On 16/May/11 15:41, John R. Levine wrote:
 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.

 OTOH, comparing the count fields of those two lines, 86% relaxed vs
 14% simple, says that such kind of benefit is really really wanted.

 But that's a perceived benefit, not an actual one.

I agree that the above does not give us insight into actual benefit.  Rather, 
it 
tells us something about beliefs and goals of signers; they chose one or the 
other because they /believed/ it would be helpful. As to whether it really was, 
we can't see here.


 Folk think they need relaxed to significantly increase survivability
 but that's not the case given the stats above. So yo may be right that
 folk really really want it, but they don't really really need it.

Sorry, but I believe the above also does /not/ help us to understand actual 
survivability differences.

To assess that difference, the experiment needs to send the same set of message 
twice, one with each type of canonicalization, and then see what the survival 
differences are.

The problem with the above is the biasing factor of signers' choosing to use 
one 
or the other, based on criteria we can't know about.  Their criteria might have 
greatly affected actual survival rates.  Or might not have...


d/

-- 

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

Re: [ietf-dkim] MLM and C14N

[Dave Crocker]

+1.  No.

John R. Levine jo...@iecc.com wrote:


 No.

+1 to the No.

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

Re: [ietf-dkim] DKIM and mailing lists

[Dave CROCKER]

On 5/11/2011 1:35 PM, John Levine wrote:
 It's unnecessary and unwelcome to call what other people write stupid.

 FYI, that section is taken verbatim from the MLM draft that Barry sent
 off yesterday.  I guess now we know who read it and who didn't.


He was just following instructions:


On 5/11/2011 10:36 AM, John R. Levine wrote:
  ... but you should blame me for
  the whole thing, borrowed or otherwise.


d/
-- 

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

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

[Dave CROCKER]

Barry,

On 5/10/2011 6:45 PM, Barry Leiba wrote:
 The DKIM Working Group requests the publication of
 draft-ietf-dkim-mailinglists-10 as a BCP. Alternatively, this document
 might be suitable for Pete's Applicability Statement experiment, at
 the Proposed Standard level.


Why are you suggesting that we offer to participate in an experiment?

1. The offer primarily serves to suggest that the document has questionable 
purpose or clarity.

2. The 'experiment' is a glimmer in Pete's idea, not a well-formulated plan 
with 
support that is gaining momentum.  All that might get better, by what is the 
benefit of introducing a possible linkage?

3.  As negotiating model's go, it is counter-productive to open with a 
fall-back 
offer.

d/

-- 

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

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

[Dave CROCKER]

On 5/11/2011 8:22 AM, Barry Leiba wrote:
 3.  As negotiating model's go, it is counter-productive to open with a
 fall-back offer.

Offering to participate in an unformulated experiment that has no schedule is a 
fallback, yes.


 There is no sense in which this is a fall-back.  I see it as a
 *better* mechanism for this document than BCP, if the IESG decides
 that it agrees.  The experiment is seeing if the IESG agrees, and
 the fall-back is BCP.

Perhaps I missed the working group discussion that agreed to this approach?

d/

-- 

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

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

[Dave CROCKER]

On 5/11/2011 10:17 AM, Murray S. Kucherawy wrote:
 I suspect you would find signficant objection to making it a PS.

 Probably not if it's made into an Applicability Statement:

 http://tools.ietf.org/html/rfc2026#section-3.2


That's simultaneously a reasonable and a terrible idea.

The construct is currently unused and is also currently under discussion.

IMO, we should stay away from nascent experiments about fuzzy topics with a 
poor 
track-record.

d/
-- 

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

Re: [ietf-dkim] DKIM and mailing lists

[Dave CROCKER]

On 5/11/2011 2:41 PM, Murray S. Kucherawy wrote:
 After all, that was the original purpose of this MLM I-D effort when
 many people had express concerns with the MLM/DKIM conflicts and lack
 of respect for ADSP and me showing real examples for the
 interoperability problem - it was only then that gave life to this
 document.

 That is not in fact the purpose of the MLM I-D effort.


Since this has all been discussed multiple times before, I suggest it /not/ be 
discussed further, yet again.  The outcome won't be any better this time than 
it 
has been in the past and there's no new material.

d/
-- 

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

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

[Dave CROCKER]

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


 +1


Hmmm, it occurs to me that the folks doing this form of +1 might mean ship it 
or they might mean preference for replacing with one-page doc or, failing 
that, 
ship it.

d/


-- 

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

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

[Dave CROCKER]

On 5/9/2011 7:40 AM, MH Michael Hammer (5304) wrote:
 I'd like to request that we specifically test for consensus on
 deprecating l= through the usual +1/-1 approach. No miring, just a
 vote.


This isn't my vote, but a comment:

Oddly, I'm finding myself coming to believe that its use within a coordinated 
template for mediators might actually being helpful.  This assumes, of course, 
that the template can be specified and gain consensus, and that signers, 
verifiers and mediators all are willing to implement it.  Hence, this path 
involves significant effort.

One could argue that it's cleaner to drop it now and explore re-introducing it 
in the effort to develop that template.

d/

-- 

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

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

[Dave CROCKER]

On 5/9/2011 1:14 PM, Steve Atkins wrote:
 On May 9, 2011, at 7:56 AM, Dave CROCKER wrote:
 Oddly, I'm finding myself coming to believe that its use within a coordinated
 template for mediators might actually being helpful.  This assumes, of 
 course,
 that the template can be specified and gain consensus, and that signers,
 verifiers and mediators all are willing to implement it.  Hence, this path
 involves significant effort.

 One could argue that it's cleaner to drop it now and explore re-introducing 
 it
 in the effort to develop that template.

 It sounds like what you're suggesting would be quite different from (and
 more complex than) l=, and would have very different semantics compared
 with the current numeric definition of l=.


In its entirety, yes.

My guess is that there is some benefit in a piece like (or the same as) l=, but 
the important difference is that it would be fit into an integrated mechanism, 
rather than just sit there piecemeal.

d/

-- 

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

Re: [ietf-dkim] Issue: Consider deprecating l=

[Dave CROCKER]

 - the PS-DS promotion rules say we should cut stuff that's not actually in
 use, but this is;

 - we therefore don't have any data to conclude that there isn't anyone out
 there that finds it exceptionally useful despite the dangers


oops.  he's right.  it /is/ in use and we have no basis for claiming that those 
using it find no benefit in it.

Hence (and with regret):

   -1

d/
-- 

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

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

[Dave CROCKER]

On 5/6/2011 11:24 AM, Murray S. Kucherawy wrote:
 I suspect it's use of l= by a signer without regard to whether or not the 
 mail is heading to an MLM.  For example, OpenDKIM's antecedent had that as an 
 option; only the evolution to OpenDKIM allowed you to be more specific.


You are certain to be correct.

In practical terms for the current world, what is the likelihood that a signer 
has any information about the 'type' of an email address?  How can a signer 
possibly know that an addressee is a mailing list???

d/

-- 

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

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

[Dave CROCKER]

On 5/8/2011 7:03 AM, Barry Leiba wrote:
 Participant input:

 I proposes the following:

 3.x  Originating Domain Identity (ODID)

  The ODID is the domain part of the From: address.  This identity
  MAY be considered as an output communicated to an advanced
  Identity Assessor module.

 I don't like making up a new name for what we already have.  I'd
 rather just call it the domain part of the 'From' address.

We might want to consider the benefits of consistency with existing 
documentation.

Email Arch (RFC 5598):

Section 2.1.1:  Author - responsible for creating the message

Section 2.2.1:  Originator - ensures that a message is valid for posting and
then submits it to a Relay

Section 4.1.4:  From:Author
Sender:  Originator

So what, exactly, are the semantics intended by this new term.



 I find this Mostly Harmless[1], but unnecessary.

Going to Draft is supposed to restrict changes to what is necessary, rather 
than 
what is whimiscally appealing to some folk.

There is already a problem with people's believing that DKIM protects or 
validates the From: field contents and that a DKIM signature implies 
assurances about that field, more than the actual data integrity from signing 
to 
verifying.

Adding a new term to refer to a portion of the From: field implies that there 
is 
an important need for the DKIM Signing specification to make that reference.

This feeds the confusion about the role of a DKIM signature.  That's not 
benignly unnecessary.  That's actively counter-productive.

d/
-- 

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

Re: [ietf-dkim] Ticket #17

[Dave CROCKER]

On 4/27/2011 2:21 AM, SM wrote:
 I thought that the advancement of the specifications from Proposed to
 Draft would not be too much of an effort as there are existing
 implementations of RFC 4871.  But then, this is the DKIM WG.


The effort is primarily created by folks choosing to respond about issues that 
have no constituency, are not real problems, and/or have already been settled.

Folks can choose not to respond, when someone else raises a concern that is not 
an actual problem with the specification.

Responding makes it look as if the issue is real and significant. The fact that 
someone chooses to keep raising settled or non- issues does not obligate others 
to respond.

That would make things go considerably quicker.

d/
-- 

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

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

[Dave CROCKER]

On 5/8/2011 10:40 AM, John R. Levine wrote:
 In practical terms for the current world, what is the likelihood that a 
 signer
 has any information about the 'type' of an email address? How can a signer
 possibly know that an addressee is a mailing list???

 Our expert interface designers add yet another knob to the user friendly 
 control
 panel, of course.

 http://graphics2.snopes.com/inboxer/graphics/rand.jpg

How the heck did they get a photo of my living room???


But seriously...

 I have to say that way too much of the MLM document strikes me as
 overcomplicated workarounds to unlikely scenarios, all of which could be dealt
 with by encouraging lists to sign their outgoing mail.

A document like this has a challenge to find the right balance between 
well-known vs. possible vs. likely issues.  The challenge is exacerbated, for 
scenarios that entail some complexity or, as with MLMs, mediation.

I think there are two reasonable ways to find the balance:

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.

d/
-- 

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

Re: [ietf-dkim] issue: Section 2.6/ 3.5 AUID/i= should have pubkey t=s info

[Dave CROCKER]

On 5/5/2011 1:37 PM, Barry Leiba wrote:
 Possible small change in 3.5 i= definition, 2nd paragraph change:

The syntax is a standard email address where the Local-part MAY be
omitted.  The domain part of the address MUST be the same as, or a
subdomain of, the value of the d= tag.  If the public key
contains t=s, then the domain part of the address MUST match
the value of d= tag.

Repeating or rephrasing specification text invites divergent interpretations.

If folks believe that it is important to create a linkage between the two 
segments of text, then make the reference be linkage, not repetition.

So, for example:

Note the constraint on the value of i= that is imposed by the t=s tag 
of 
the stored key record. (See Section 3.6.1).



 Possible small change in 2.6:

 2.6.  Agent or User Identifier (AUID)

 A single identifier that refers to the agent or user on behalf of
 whom the Signing Domain Identifier (SDID) has taken responsibility.
 The AUID comprises a domain name and an optionalLocal-part.  The
 domain name is the same as that used for the SDID or is a sub-domain
 of it. If the public key contains t=s, then the domain name MUST
 be the same as SDID. For DKIM processing, 

See above.

d/

-- 

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