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

[John R. Levine]

Sorry.  Where is the version number for SMTP?


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


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


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


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

Re: [ietf-dkim] versions, 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  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?

[Alessandro Vesely]

On Fri 09/Feb/2018 23:31:41 +0100 John R. Levine wrote:
> 
> 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.

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

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

[Mark Delany]

On 09Feb18, John R. Levine allegedly wrote:

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

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

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

[John R. Levine]

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

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


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

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

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

Nonetheless, we seem to have survived.

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


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

Re: [ietf-dkim] 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?

[Mark Delany]

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.

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 :-)

> Besides if you wanted to go from DKIM to EKIM, you'd be opening 
> pandora's box imo.

Indeed. As mentioned previously MIME-Version: 1.0 has set the standard for us to
emulate.


Mark.
___
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?

[Michael Thomas]

On 2/8/18 4:45 PM, Dave Crocker wrote:

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.


Thankfully nobody's seriously talking about that from what i can tell, 
so this strikes me as so many angels on a pinhead.


Mike
___
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] versions, Where is the formal definition of DKIM-Signature?

[Michael Thomas]

On 2/8/18 12:32 PM, Mark Delany wrote:

I think this is the biggest flaw with the whole v= rationale. There is never
going to be a v=2 change that doesn't leave everyone continuing to
generate/validate a v=1 header. Is a new header by stealth better engineering
than formalizing a new header?

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


Besides if you wanted to go from DKIM to EKIM, you'd be opening 
pandora's box imo.


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

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

[John Levine]

In article <20180208203207.26575.qm...@f3-external.bushwire.net> you write:
>After all, what are most senders going to do? They will not want their
>signatures to be suddenly unrecognized by 99% of the planet so they'll continue
>to generate a v=1 header and they will also want to reap the bennies of your
>fantastic SpamAssassin feature so they'll additionally generate a v=2 header.

In my application, the feature that requires v=2 is double signing,
i.e. this signature is valid only if there's also a signature from X.  It
was intended as a workaround for the DMARC mailing list problem

The idea is that in addition to your regular v=1 signature, you'd also
put a weak v=2 signature that requires re-signing by the mailing list.
If you don't use conditional signing (or something else subsequently
added that depends on v=2 semantics), then v=1 signatures are fine
forever.

The reason to make then both DKIM-Signature headers is that there is
code, some of which I've written, that looks for DKIM-Signature
headers in a message and calls a DKIM verifier library if it sees
them.  DKIM is slow, do you don't want to waste time verifying
messages with nothing to verify.  If you don't change the
DKIM-Signature header, all of this code keeps working when you upgrade
your DKIM library.  If you invent a new header, it doesn't.

>The end result is two DKIM-Signature headers with different versions for 
>decades
>to come. This will no doubt tweak some receiver is a negative way.

Only if their validators are broken.  I realize that's likely to be
the case now and then but I can't feel too sorry for them.

R's,
John
___
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?

[Mark Delany]

> True, but not very interesting.  In my spamassassin example, the outside 
> code knows nothing about DKIM versions, it just sees a dkim-signature 
> header and sends it to the DKIM library.
> 
> The point of a v=2 flag is to ensure that old v=1 code doesn't

As a practical matter haven't you effectively invented a new header?

After all, what are most senders going to do? They will not want their
signatures to be suddenly unrecognized by 99% of the planet so they'll continue
to generate a v=1 header and they will also want to reap the bennies of your
fantastic SpamAssassin feature so they'll additionally generate a v=2 header.

The end result is two DKIM-Signature headers with different versions for decades
to come. This will no doubt tweak some receiver is a negative way.

I think this is the biggest flaw with the whole v= rationale. There is never
going to be a v=2 change that doesn't leave everyone continuing to
generate/validate a v=1 header. Is a new header by stealth better engineering
than formalizing a new header?


Mark.
___
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] 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?

[John R. Levine]

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


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


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


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

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

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

[John R. Levine]

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


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


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

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

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

[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] versions, Where is the formal definition of DKIM-Signature?

[Mark Delany]

On 08Feb18, John R. Levine allegedly 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.

Yes, one can certainly contrive a situation in which they prefer a v=2 solution,
but as you say, the requirement can be just as easily satisfied in a number of
other ways too.

A new header is one as is the presence of a new tag and v= is a third. There are
other ways as well.

Given we're talking about standards, it's de rigueur that we end up with at
least three competing ways of achieving the same outcome without any guidance
whatsoever as to which mechanism to choose when and why.

Underlying all this of course is the assumption that programmers intuit the
possibility of change inherent in these non-essential mechanisms and code and
test accordingly. Now that's a goodun.


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

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

[John R. Levine]

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


Except really they don't.


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


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

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

[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] versions, Where is the formal definition of DKIM-Signature?

[John R. Levine]

On Thu, 8 Feb 2018, Mark Delany wrote:

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


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


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

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