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

[Michael Thomas]

On 02/10/2018 10:22 AM, Dave Crocker wrote:

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.


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

[ietf-dkim] features and versions and running code

[John R. Levine]

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


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


R's,
John

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

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

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

[Michael Thomas]

On 02/10/2018 10:04 AM, Dave Crocker wrote:

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


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

Angels, meet the pinhead.

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

[John R. Levine]

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


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


Ditto EAI.

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


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


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

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

[John R. Levine]

Sorry.  Where is the version number for SMTP?


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


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


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


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

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

[John R Levine]

Well, that's simply and completely false.

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


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

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

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

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

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

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

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

Re: [ietf-dkim] versions 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  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 of RFC822 mail messages, Where is the formal definition of DKIM-Signature?

[John Levine]

In article <20180210092127.33398.qm...@f3-external.bushwire.net> you write:
>In any event, 822 is an existence-proof that decades-long upgrades are entirely
>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

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