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

From: "John R. Levine" <[email-masked]>
Date: 9 Feb 2018 17:31:41 -0500

In article <[email-masked]>,
Mark Delany <[email-masked]> wrote:
> Oh I dunno. The precedent of RFC822 - the very standard we rely on - has
> survived numerous upgraded and enhancements over a 36 year period and managed
> to do just fine without a version.

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

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

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

Nonetheless, we seem to have survived.

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

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

---

From: "Mark Delany" <[email-masked]>
Date: 10 Feb 2018 09:21:27 +0000

On 09Feb18, John R. Levine allegedly wrote:

> extension, you lose, the message bounces.

I'm not sure whether this an argument for or against versioning. Or an argument
that sometimes bad engineering choices are made regardless of the upgrade
mechanism.

In any event, 822 is an existence-proof that decades-long upgrades are entirely
possible without the scorched-earth approach of versioning. I hope it would take
a very strong argument to suggest that we shouldn't (or can't) follow the 822
strategy.

Mark.

---

From: Alessandro Vesely <[email-masked]>
Date: Sat, 10 Feb 2018 10:38:28 +0100

> libraries, that's not a problem.

Assuming that that hack would have been way more befitting than any other idea
discussed on dmarc-ietf ever since, one may wonder how much of its fading away
was due to its version bumping instead of, say, introducing a new header field.

Ale

---

From: "John Levine" <[email-masked]>
Date: 10 Feb 2018 10:50:10 -0500

In article <[email-masked]> you write:
>possible without the scorched-earth approach of versioning. ...

Nope, see the PS.  But anyway.

I don't understand this scorched earth stuff.  This is not IPv6, which
is often incompatible for the sake of being incompatible, and is
intended to make IPv4 go away sometime in the fourth millenium.

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

  DKIM-Signature: v=1,mandatory ...

R's,
John

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.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Feb 2018 09:18:08 -0800

> 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

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Feb 2018 09:20:26 -0800

> 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/

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Feb 2018 09:25:28 -0800

> 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/

---

From: "John R Levine" <[email-masked]>
Date: 10 Feb 2018 12:44:14 -0500

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

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

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

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

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

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

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

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY

---

From: "John R. Levine" <[email-masked]>
Date: 10 Feb 2018 12:55:31 -0500

> Sorry.  Where is the version number for SMTP?

MAIL FROM:<[email-masked]> SMTPUTF8    <--

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

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

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Feb 2018 09:55:31 -0800

>       line with nothing preceding the CRLF).

MIME is an overlay, flagged by the presence of the either/both of:

    MIME-Version:
    Content-Type:

The fact that the first of these says 'version' is distracting, for the 
current discussion.  It's significance is to say that MIME is used for 
the body, but really that's redundant with the mere presence of 
Content-type.

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.

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

> what you call something that exists but we pretend for now that it

So?  Some non-normative text notes that there is some other 
specification(s) that you might want to look for.

d/

---

From: "John R. Levine" <[email-masked]>
Date: 10 Feb 2018 12:59:15 -0500

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

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

Ditto EAI.

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

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

Regards,

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Feb 2018 10:04:49 -0800

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

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Feb 2018 10:12:19 -0800

On 02/10/2018 10:04 AM, Dave Crocker wrote:
>> 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.
>
> 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.

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

Angels, meet the pinhead.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sat, 10 Feb 2018 10:22:00 -0800

> 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/

---

From: Michael Thomas <[email-masked]>
Date: Sat, 10 Feb 2018 10:47:59 -0800

On 02/10/2018 10:22 AM, Dave Crocker wrote:
> 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 

I don't know when the last time you've written a line of code (my last 
time was about 5 minutes ago), but this is just silly.
It makes not a particle of difference code-wise, but it would require 
reconfiguration of the mailer configurations for a new
header. I'll take that back, code-wise. My assumption is that the actual 
header is passed into the DKIM library. If that's not
true, it would be more work vs. v=2. But I still think this entire 
conversation is silly in its theoreticality.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Feb 2018 11:39:40 -0800

On 2/10/2018 9:59 AM, John R. Levine wrote:
>> author and recipient and not by /any/ of the infrastructure.  IE, not 
>> by SMTP.
> 
> 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.

> 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/

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Feb 2018 17:46:13 -0800

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/

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Feb 2018 17:54:38 -0800

> Protocol complexity matters, especially for features that have no 
You guys have already spent 10 times the amount of effort prattling on 
about these theoretical differences than any amount
of supposed savings for us poor, poor programming types. You clearly 
have no idea what you are talking about.

Mike

---

From: Dave Crocker <[email-masked]>
Date: Sun, 11 Feb 2018 18:20:42 -0800

On 2/11/2018 5:54 PM, Michael Thomas wrote:
> You clearly have no idea what you are talking about.
> 
> Mike
> 

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/

---

From: Michael Thomas <[email-masked]>
Date: Sun, 11 Feb 2018 18:40:32 -0800

On 02/11/2018 06:20 PM, Dave Crocker wrote:
> 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/
>

Sorry, you don't know what you are talking about. I wrote code every day 
for a living. I wrote the first implementation of DKIM, followed
very quickly by Murray's. I know what I'm talking about here. You 
don't.  When is the last time you've written code? This is all very silly
to me, and your impugning my 30+ years of experience is a joke.

Mike