Subject: [Dcrup] Progress Evaluating DCRUP

From: Scott Kitterman <[email-masked]>
Date: Sat, 17 Feb 2018 23:46:45 -0500

I think we'll have an example header here shortly.  In the meantime, I've got 
a DKIM milter running (experimentally) that signs/verifies Ed25519 (see the 
signatures that hopefully won't get stripped off this message).

I am in need of a Sendmail user to help me out with this effort.  What I have 
works in Postfix, but I've no way (or interest) in figuring out Sendmail.  If 
you're interested in having a milter to support Ed25519 and aren't allergic to 
Python, please contact me off list.

Scott K

---

From: Jeremy Harris <[email-masked]>
Date: Sun, 18 Feb 2018 11:42:35 +0000

On 18/02/18 04:46, Scott Kitterman wrote:
>  In the meantime, I've got 

On the parallel development stream, I have committed the Exim changes to
the public git repo.  Anyone

a) running Exim
b) able to build from source
c) having GnuTLS 3.6.0 or later

is welcome to try it.  I have a public-facing MTA running, on Fedora
Rawhide; anyone needing a test target or source for Ed25516 signatures
please contact me offlist.
-- 
Cheers,
  Jeremy

---

From: Hector Santos <[email-masked]>
Date: Sun, 18 Feb 2018 11:55:30 -0500

> signatures that hopefully won't get stripped off this message).

These is three signatures I see (top down):

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org;
    s=ietf1;  t=1518929216; .....

DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=kitterman.com;
  i=@kitterman.com; q=dns/txt; s=201802; t=1518929205; ......

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kitterman.com;
  i=@kitterman.com; q=dns/txt; s=201802r1; t=1518929205;  .....

and the results,

Authentication-Results: dkim.winserver.com;
  dkim=pass header.d=ietf.org header.s=ietf1 header.i=ietf.org;
  adsp=none author.d=kitterman.com signer.d=ietf.org;
  dkim=fail (DKIM_BAD_SYNTAX) header.d=none header.s=none header.i=none;
  adsp=none author.d=kitterman.com signer.d=;
  dkim=fail (DKIM_BODY_HASH_MISMATCH) header.d=kitterman.com 
header.s=201802r1
      header.i=@kitterman.com;
  adsp=none author.d=kitterman.com signer.d=kitterman.com;

Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral
  reason="invalid (unsupported algorithm ed25519-sha256)"
          header.d=kitterman.com header.b=CitK92hG;
  dkim=pass (1024-bit key) header.d=kitterman.com header.b=rnAglVrs

The list Auth-Res was specific with the unsupported method but with a 
(subjective) "dkim=neutral" or is it "dkim=pass?" result.

The local Auth-RES failed the verification and it cleared the data as 
a bad-syntax. Nothing good about it.

This is what is to be expected for many years to come.   The good 
news, is that the original signatures always failed anyway at the list 
server, generally with a DKIM_BODY_HASH_MISMATCH.  The bad news is 
that some unsuspected AVS heuristic could add more weight to the 
failure.

Personally, I think we should update v=1  to v1.1.  It is a different 
updated API DKIM now, and one that could also offer logic to 
invalidate SHA1 signatures.  Thats definitely not a DKIM STD V=1 feature.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Sun, 18 Feb 2018 18:55:33 +0000

>invalidate SHA1 signatures.  Thats definitely not a DKIM STD V=1

Neutral is a valid result:

https://www.iana.org/assignments/email-auth/email-auth.xhtml

Bumping the version doesn't help.  There's no reason to believe a system that treats unknown algorithms badly wouldn't do the same for unknown signature versions.

Scott K

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 18 Feb 2018 14:31:10 -0500

> On Feb 18, 2018, at 11:55 AM, Hector Santos <[email-masked]> wrote:
> 
> Personally, I think we should update v=1  to v1.1.  It is a different updated API DKIM now, and one that could also offer logic to invalidate SHA1 signatures.  Thats definitely not a DKIM STD V=1 feature.

One could argue that, if successful, you'll end up trading implementations that mess up handling algorithms for implementations that mess up handling version numbers.

Thanks,
Stan

---

From: "John R. Levine" <[email-masked]>
Date: 18 Feb 2018 15:08:23 -0500

> One could argue that, if successful, you'll end up trading implementations that mess up handling algorithms for implementations that mess up handling version numbers.

There are scenarios where bumping the version number makes sense (see my 
flamefest with Dave Crocker) but this isn't one of them.  Any existing 
DKIM verifier that doesn't ignore an ed25519 signature is already badly 
broken.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Hector Santos <[email-masked]>
Date: Sun, 18 Feb 2018 18:24:10 -0500

On 2/18/2018 3:08 PM, John R. Levine wrote:
>>> Personally, I think we should update v=1  to v1.1.  It is a
>>> different updated API DKIM now, and one that could also offer logic
>>> to invalidate SHA1 signatures.  Thats definitely not a DKIM STD V=1
>>> feature.
>>
>> One could argue that, if successful, you'll end up trading
>> implementations that mess up handling algorithms for implementations
>> that mess up handling version numbers.
>
> There are scenarios where bumping the version number makes sense (see
> my flamefest with Dave Crocker) but this isn't one of them.  Any
> existing DKIM verifier that doesn't ignore an ed25519 signature is
> already badly broken.

Its already broken at this elevated point.  The question has always 
been since day one, "How do you report/evaluate invalid signatures?"

Since day one, as it is written in DKIM STD stone, the DKIM invalid 
signature concept was to viewed as an invalid result as if the 
signature never existed. No invalid data is passed.  Many policy 
advocates felt otherwise, it should|could be included in heuristic/AI 
algorithms, the idea that invalid condition(s) may exist in a transport.

Nonetheless,  there is good logic when a verifier sees "v1.1" because 
it tells them there is a number of new DKIM STD considerations 
supported by the signer:

   1)  A new hash algorithm exist,
       1.1) Pay more attention to POLICY "k=" tags,

   2)  SHA1-hashed signatures MAY be rejected (invalidated).
       2.1) The original domain policy MAY expect it.

At the end of the day, its about API code change.  You can't do DRUP 
without changing DKIM code. This update is not DKIM STD v1=0 as it was 
written.   It is v=1.1

The updated API should be able to handle both and more.

-- 
HLS

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 18 Feb 2018 18:55:18 -0500

> On Feb 18, 2018, at 3:08 PM, John R. Levine <[email-masked]> wrote:
> 
> There are scenarios where bumping the version number makes sense (see my flamefest with Dave Crocker) but this isn't one of them.

I thought of that thread after I posted. 0:-)

I should have been clear that I'm not espousing an opinion on version bumps in general—it just seems to me that with this with this particular trade, there's a rather relatively high opportunity cost.  It also wouldn't surprise me if a number of sites that mess up with signatures/algorithms also mess up with the version number, in which case you have a driver who interprets the sign pointing to the new roadway as a sign that reads, "Don't drive."

> Any existing DKIM verifier that doesn't ignore an ed25519 signature is already badly broken.

Yes.

Thanks,
Stan

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 18 Feb 2018 19:16:27 -0500

> On Feb 18, 2018, at 6:24 PM, Hector Santos <[email-masked]> wrote:
> 
> Nonetheless,  there is good logic when a verifier sees "v1.1" because it tells them there is a number of new DKIM STD considerations supported by the signer:

Using just "1.1" isn't sufficient.  If you want to use the version numbering approach, you have to do something like what John Levine proposed in that thread on the ietf-dkim list or what TLS 1.3 does in masquerading as TLS 1.2.

Thanks,
Stan

---

From: Hector Santos <[email-masked]>
Date: Sun, 18 Feb 2018 19:20:16 -0500

>> Any existing DKIM verifier that doesn't ignore an ed25519 signature is already badly broken.

Define broken.  If it doesn't understand ed25519, then having v=1.1 
would also preempt non-supporters.  Keep in mind that one the basic 
tenets in DKIM STD verification is that an invalid signature MUST be 
viewed as if the signature never existed.

So you need to define what "Broken" means.  Breaking due to an unknown 
hash resulting in an invalid signature is perfectly valid -- No 
Signature Exist at that point.

-- 
HLS

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 18 Feb 2018 19:32:27 -0500

On Feb 18, 2018, at 7:16 PM, I wrote:
> 
> Using just "1.1" isn't sufficient.  If you want to use the version numbering approach,

Well, really, to cover all the scenarios,  perhaps it's better to say "versioning approach", although all the scenarios do involve version numbers.

Stan

---

From: Hector Santos <[email-masked]>
Date: Sun, 18 Feb 2018 19:49:56 -0500

>> Any existing DKIM verifier that doesn't ignore an ed25519 signature is already badly broken.

If a signer uses a=ed25519-sha256, all non-supportive verifiers are 
purposely "broken" in which case, the signature MUST be deemed 
invalid, and by design, in DKIM STD methodology, the signature must be 
viewed as never to exist.  Any verifier that continues to consider to 
evaluate a non-supportive hash could be viewed as "broken" and a 
"security risk."

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Feb 2018 03:09:14 +0000

>evaluate a non-supportive hash could be viewed as "broken" and a 

It's really simple (RFC 6376 and predecessors):

"3.3.4.  Other Algorithms Other algorithms MAY be defined in the future. Verifiers MUST ignore any signatures using algorithms that they do not implement."

Any verifier that does that is not "broken" and there's no problem.  Any verifier that does something else is "broken".  No version nonsense needed.

Scott K

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 19 Feb 2018 04:57:44 +0000

There is no API defined in the documents, so I that doesn't seem like motivation to change the version number.

    

    Thanks,
    Stan
    _______________________________________________
    Dcrup mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dcrup

---

From: Hector Santos <[email-masked]>
Date: Mon, 19 Feb 2018 17:04:07 -0500

> Any verifier that does that is not "broken" and there's no problem.  Any verifier that does something else is "broken".  No version nonsense needed.

If the new logic is to encourage ignoring/invalidate a DKIM STD76 
feature, i.e. SHA1, then that technically is a STD version upgrade. 
The real "nonsense" is that software COULD break if you bumped the 
number.  It couldn't be then even if it was desired.  Thats the real 
problem here.

At the end of the day, it is NOT STD76 v=1 behavior.

-- 
HLS

---

From: Jim Fenton <[email-masked]>
Date: Mon, 19 Feb 2018 14:14:47 -0800

On 2/19/18 2:04 PM, Hector Santos wrote:
>> "3.3.4.  Other Algorithms Other algorithms MAY be defined in the
>> future. Verifiers MUST ignore any signatures using algorithms that
>> they do not implement."
>>
>> Any verifier that does that is not "broken" and there's no problem. 
>> Any verifier that does something else is "broken".  No version
>> nonsense needed.
>
Would bumping the version number to 1.1 tell us anything that the
a=ed25519-sha256 tag doesn't already tell us? Seems like bumping the
version number is redundant.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Feb 2018 17:23:51 -0500

On Monday, February 19, 2018 05:04:07 PM Hector Santos wrote:
> >>>> Any existing DKIM verifier that doesn't ignore an ed25519 signature
> >> 
> >> is already badly broken.
> >> 
> >>> Yes.
> >> 
> > "3.3.4.  Other Algorithms Other algorithms MAY be defined in the future.
> > Verifiers MUST ignore any signatures using algorithms that they do not
> > implement."
> > 
> > Any verifier that does that is not "broken" and there's no problem.  Any
> > verifier that does something else is "broken".  No version nonsense
> > needed.

That's not what we're talking about here.  Even if that was correct, and I 
don't think it is, then the time to have that conversation would have been 
before RFC 8301 was published.  At this point, SHA1 is gone.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 19 Feb 2018 17:50:07 -0500

> before RFC 8301 was published.  At this point, SHA1 is gone.

Not sure what you mean "SHA1 is gone."

That is my point.  SHA1 is NOT gone in STD76 v=1 behavior, it will 
always be supported by those who know nothing about the updated 
proposed RFC8301 STD76 updated version.  Are you ready to throw the 
book on packages that don't support RFC8301? Even if they support 
STD76 v=1?    As it is now, IMTO, it creates documentation and code 
ambiguity.

Anyway, this is a perfect opportunity for a version bump in my opinion.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Mon, 19 Feb 2018 17:51:28 -0500

> version number is redundant.

I agree, it can be viewed as redundant but it is more precise and we 
probably can use some more precision in this group.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 19 Feb 2018 18:11:37 -0500

> Anyway, this is a perfect opportunity for a version bump in my opinion.

It's not, but clearly this isn't a productive discussion, so I'm done.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Mon, 19 Feb 2018 20:49:59 -0500

> It's not, but clearly this isn't a productive discussion, so I'm done.

It is unfortunate you feel privileged enough to begin to disparage me 
and resort to such unproductive "WG" tones.  Since you already stated 
your opinion on the matter, you could of just step back and allow more 
folks to chime in, or not.  I don't appreciate your tone.

This is my technical opinion:

STD76 says:

    v= Version (plain-text; REQUIRED).  This tag defines the version of
       this specification that applies to the signature record.  It MUST
       have the value "1" for implementations compliant with this version
       of DKIM.

       ABNF:

       sig-v-tag       = %x76 [FWS] "=" [FWS] 1*DIGIT

          INFORMATIVE NOTE: DKIM-Signature version numbers may increase
          arithmetically as new versions of this specification are
          released.

The "Request For Comment" RFC8301 proposed update to STD76 should be 
done with a version bump because SHA1 is being removed which is a 
standard DKIM STD76 feature.  RFC8301 has language that will allow new 
compliant STD76+RFC8301 to invalidate compliant STD76 v=1 messages 
with legitimate SHA1 signatures.

To me, that is "version bump" behavior.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 20 Feb 2018 02:01:47 +0000

It seems to me that if the syntax and semantics of the existing labels are not changed, then there is no need to change the version.  Adding or removing algorithms within the current syntax does not seem to require a version change.

If anyone else is in favor of changing the version, please speak up within a week.

---

From: denis bider <[email-masked]>
Date: Tue, 20 Feb 2018 00:23:34 -0600

I can see Hector's point, not as a technical necessity, but as a tool to be
able to say "You're still accepting SHA-1 signatures? Bah, so you don't
support v1.1?"

If you don't raise the version number, then you don't get to say that
product X implements "only version 1.0" (because no Ed25519) or that they
are "non-compliant with version 1.1" (because they accept SHA-1).

So raising the version could be a useful tool from a social perspective, to
more easily cajole people into improvements. However, it does not seem to
be a technical necessity.

On Mon, Feb 19, 2018 at 8:01 PM, Salz, Rich <[email-masked]> wrote:

> It seems to me that if the syntax and semantics of the existing labels are
> not changed, then there is no need to change the version.  Adding or
> removing algorithms within the current syntax does not seem to require a
> version change.
>

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 20 Feb 2018 01:35:36 -0500

For buzzword compliance, you can whinge about not implementing RFC 8301.

Scott K

---

From: "Mark D. Baushke" <[email-masked]>
Date: Mon, 19 Feb 2018 23:31:24 -0800

+1 to bumping the version number per Hector Santos' argument.
   (I agree with denis bider that it is not a mandatory technical
   necessity, but it still seems like good hygene to me.)

	-- Mark

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 20 Feb 2018 06:50:21 -0800

On Mon, Feb 19, 2018 at 11:31 PM, Mark D. Baushke <[email-masked]> wrote:

> <https://www.ietf.org/mailman/listinfo/dcrup>
>

The problem with using the version number as a compliance marker is that
most people would expect that support for 1.1 includes support for 1.0
rather than cutting off the the "bad" parts of 1.0. The same goes for
N+anything - forward compatibility is expected rather than breaking old
behaviour.

--Kurt

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 20 Feb 2018 07:59:26 -0800

Hi Kurt,

> N+anything - forward compatibility is expected rather than breaking old

Hmmm... There are counter examples (OpenSSL). However, many bump the
version to a new major number when leaving older things behind.

There are RFC drafts out there to deprecate or remove older algorithms
such as RC4 and SHA1 from many protocols.

I would have no problems with v=2 rather than v=1 if that is what is
needed to kill SHA1.

	-- Mark

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 20 Feb 2018 13:02:25 -0500

> such as RC4 and SHA1 from many protocols.

Yes, RFC 8301 changed SHA1 in DKIM to historic last month.

> I would have no problems with v=2 rather than v=1 if that is what is

Again, this seems like a lot of pain for something that might break version numbers, especially when the same verifiers that badly mishandle algorithms might mishandle version numbers as well.

This having been said, if people are serious about this, it seems to me then that people might as well consider https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ in parallel.  Consider how much it might/might not collide with bad implementations, how much that matters in the grand scheme of things if it's going to be used for other modifications to DKIM, and so forth.

Thanks,
Stan

---

From: Jim Fenton <[email-masked]>
Date: Tue, 20 Feb 2018 10:18:51 -0800

On 2/19/18 10:23 PM, denis bider wrote:
> I can see Hector's point, not as a technical necessity, but as a tool
> to be able to say "You're still accepting SHA-1 signatures? Bah, so
> you don't support v1.1?"

The problem I see with this is that the version number is associated
with the signer, not the verifier. You can already tell that the signer
isn't using SHA1 (because they didn't). The signer and the verifier for
a particular domain aren't necessarily the same entity, so it may or may
not say something about the acceptance of SHA1 by a verifier.

But non-usage of SHA1 was the subject of RFC 8301, not this draft. If we
were going to bump the version number to indicate non-usage of SHA1, it
belonged there.

-Jim

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 20 Feb 2018 10:23:21 -0800

Hi Stan,

Many thanks for pointing out draft-levine-dkim-conditional-03 as I had
missed it. I agree that those changes would likely need a version bump
as J. Levine has written.

As has been said, the version bump is not really a mandatory technical
change. It is a "nice to have" change. Implementors do need to worry
about the installed base. 

That said, after having live through over 15 years of SSH 1.99 still
having SSHv1 AND having SSHv2, I would like to have seen the SSHv2
change happen more quickly than it did. 

I am not sure if a version bump for DKIM will help or hurt transition
away from SHA1 or not.

	-- Mark

---

From: "John Levine" <[email-masked]>
Date: 20 Feb 2018 15:36:04 -0800

>If anyone else is in favor of changing the version, please speak up within a week. 

For reasons already rehashed, I specifically think that changing the
version is a terrible idea.  No.

---

From: "John Levine" <[email-masked]>
Date: 20 Feb 2018 15:42:41 -0800

>I would have no problems with v=2 rather than v=1 if that is what is

Given that RFC 8301 was published last month, it seems a little late
to raise this argument.

I can assure you that no matter what we do, DKIM v=1 will never go
away, ever.  The only way to get people to stop signing with sha1 is
to persuade large mail receivers to stop accepting it, and that is a
social process unrelated to publishing RFCs.

R's,
John

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 20 Feb 2018 18:55:29 -0500

> On Feb 20, 2018, at 6:42 PM, John Levine <[email-masked]> wrote:
> 
> The only way to get people to stop signing with sha1 is
> to persuade large mail receivers to stop accepting it,

I suspect this is what will eventually happen, and that one or two of them will actually be proactive in this regard.

Stan

---

From: "John Levine" <[email-masked]>
Date: 20 Feb 2018 16:36:15 -0800

In article <[email-masked]> you write:
>This having been said, if people are serious about this, it seems to me then that people might as well consider
>https://datatracker.ietf.org/doc/draft-levine-dkim-conditional/ in parallel.

Please don't.  That was a strawman proposal for what eventually turned
into ARC.  Nobody plans to implement it.

This whole version number argument is a distraction.  We don't need a
new version number to add a new signing algorithm, and it will do nothing
whatsoever to discourage sha1 signatures.

R's,
John

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 20 Feb 2018 19:50:12 -0500

> On Feb 20, 2018, at 7:36 PM, John Levine <[email-masked]> wrote:
> 
> into ARC.

Fair enough.

> Nobody plans to implement it.
> 

I still think there are potentially useful bits in it that might stand on their own, but my motivation in mentioning it is that it still seems better than just changing a number, if that's what people were interested in.  I agree it isn't necessary for adding or removing algorithms, and I agree that this wouldn't make SHA1 go away.

Thanks,
Stan

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Feb 2018 01:14:57 +0000

>  We don't need a
  
Speaking as chair:  yes this is accurate.

---

From: "Mark D. Baushke" <[email-masked]>
Date: Tue, 20 Feb 2018 17:42:59 -0800

> Speaking as chair:  yes this is accurate.

Okay. I withdraw my support for bumping the version number.

	-- Mark

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Feb 2018 21:33:04 -0500

On 2/20/2018 7:36 PM, John Levine wrote:
> This whole version number argument is a distraction.

Strawman proposals?   So it was a joke? To waste people's time?  Talk 
about distractions.  :(

I never expected the version number to change. Wasn't technically 
necessary, but the RFC8301 update is changing a STD76 standard with 
SHA1 invalidation and it won't take large systems to make to happen. 
Any updated system can do it now, today.

BTW, STD76+RFC8301 is already obsolete with its statement:

     "Signers MUST sign using rsa-sha256."

DRUP will need to update STD76-RFC8301 again to allow signers to use 
ed25519-sha256.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Feb 2018 02:54:33 +0000

ed25519-sha256.
   
Will we?  Our intent was to shut down after this last draft is published.  Is there more to do?  Let's get that on the table, if so.  Aleksey, your thoughts?

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Feb 2018 22:17:30 -0500

> Will we?  Our intent was to shut down after this last draft is published.  Is there more to do?  Let's get that on the table, if so.  Aleksey, your thoughts?

A primary purpose of the split was to better address the spread of 
implementations, which include:

   - Those who will wait for ed25519 support (library wise, i.e. 
openssl),

   - Those who can invalidate SHA1 today to address security concerns, 
and

   - Those who will do ed25519 support and not remove support for SHA1,
     just yet, for customer support reasons and make sure it will of a
     policy option.

I agreed with the split to minimize "malpractice" compliancy concerns. 
  But it was probably a better idea to do both together for better 
integrated software engineering and implementation.

Those who implement RFC8301 today and remove SHA1, including new 
implementations who are now encourage to not code for SHA1 and only 
hash with SHA256 will eventually need to be ready to update for 
ed25519 support. They need to be aware of this new STAD76+RFC5301+DRUP 
("v1+") version of DKIM.

-- 
HLS

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 21 Feb 2018 03:24:16 +0000

When this draft is published as an RFC, there will be a link forward/backward saying it updates 8301.  Isn't that enough?

It's not a new version.

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Feb 2018 22:46:48 -0500

> When this draft is published as an RFC, there will be a link forward/backward saying it updates 8301.  Isn't that enough?

Pending review of text change, that will generally fix it.

> It's not a new version.

Well, I think it is. lol, we lets keep it v=1.  :)

thanks

-- 
HLS

---

From: Stan Kalisch <[email-masked]>
Date: Tue, 20 Feb 2018 23:06:34 -0500

> On Feb 20, 2018, at 9:33 PM, Hector Santos <[email-masked]> wrote:
> 
> Strawman proposals?   So it was a joke? To waste people's time?  Talk about distractions.  :(

Speaking of distractions:

> I never expected the version number to change.

Instead of serially asking for the version number to be changed and saying that the concern regarding implementations mishandling version numbers was "nonsense", it would have been helpful if you had said this, instead.

Stan

---

From: Hector Santos <[email-masked]>
Date: Tue, 20 Feb 2018 23:54:57 -0500

> Instead of serially asking for the version number to be changed and saying that the concern regarding implementations mishandling version numbers was "nonsense", it would have been helpful if you h…

First, I stated an opinion why it should be changed.  I responded to 
someone else's statement indicating this was "nonsense" and I 
indicated the real problem or "nonsense" is that we unfortunately have 
implementations that could "break" if the v= value is changed. So 
right there, it was clear there was issues with bumping.   While 
unknown tags are ignored, a "v=1" change could cause a problem.   I 
just felt we might consider finally addressing it now that we are 
updating a standard STD76. A rare opportunity.  I threw it out there 
and I never expected it to be endorsed. I was rather surprised a few 
"agreed."  Thanks for your input.  We all agreed it wasn't necessary. 
  However, expecting it would come, once Levine commented, well, I 
knew the game was over. Your acceptance of his "Strawman" comment 
well, not cool.  No one knew this was another Levine "strawman" 
proposal, I didn't, like ADSP was which many in the industry wasted 
many years with it.   To repeat this, it is really not cool to do it 
again with DKIM-Conditional.

Nonethesless, No I didn't think a version bump would be endorsed.

Thanks

-- 
HLS

---

From: "John Levine" <[email-masked]>
Date: 21 Feb 2018 08:37:48 -0800

>When this draft is published as an RFC, there will be a link forward/backward saying it updates 8301.  Isn't that enough?

RFC 8301 is an update to 6376, and this will also be an update to
6376.  It doesn't need to update 8301, since sha1 and 512 bit rsa are
still dead.

It's not like we reissue RFC 5322 every time someone invents a new
mail header, after all.

R's,
John

---

From: Stan Kalisch <[email-masked]>
Date: Wed, 21 Feb 2018 16:03:34 -0500

Your original language about "nonsense" wasn't clear to me in that regard, but I now see what you intended, so thanks.  As for John Levine's document, it's still helpful as a thought exercise, and I'll concede I wasn't around for much of the discussion that led to the genesis of ARC.  I don't think a draft that's not intended to be seen to completion is necessarily a bad thing; it has its place.

Thanks,
Stan

> On Feb 20, 2018, at 11:54 PM, Hector Santos <[email-masked]> wrote:
> First, I stated an opinion why it should be changed.  I responded to someone else's statement indicating this was "nonsense" and I indicated the real problem or "nonsense" is that we unfortunately have implementations that could "break" if the v= value is changed. So right there, it was clear there was issues with bumping.   While unknown tags are ignored, a "v=1" change could cause a problem.   I just felt we might consider finally addressing it now that we are updating a standard STD76. A rare opportunity.  I threw it out there and I never expected it to be endorsed. I was rather surprised a few "agreed."  Thanks for your input.  We all agreed it wasn't necessary.  However, expecting it would come, once Levine commented, well, I knew the game was over. Your acceptance of his "Strawman" comment well, not cool.  No one knew this was another Levine "strawman" proposal, I didn't, like ADSP was which many in the industry wasted many years with it.   To repeat this, it is really not cool to do it again with DKIM-Conditional.
>

---

From: Hector Santos <[email-masked]>
Date: Thu, 22 Feb 2018 09:34:49 -0500

> 6376.  It doesn't need to update 8301, since sha1 and 512 bit rsa are

I suppose someone who applies RFC8301 and not DRUP could indicate the 
updated STD76 only supports sha256 and nothing more, why, because it 
now says so:  STD76 Section 3.3 was updated by RFC8301 to include a 
sentence:

     Signers MUST sign using rsa-sha256.

What DRUP section 5 has is:

    5.  Key and algorithm choice and strength

    Section 3.3 of [RFC6376] describes DKIM's hash and signature
    algorithms.  It is updated as follows:

    Signers SHOULD implement and verifiers MUST implement the
    ed25519-sha256 algorithm.

DRUP should update RFC8301's section 3.1 to replace its text or have a 
similar clear replacement text for STD76 section 3.3 that includes 
SHA256 and ED25519 as possible hashes.

I also have a problem with a Verifier MUST implement.  I think ed25519 
is too early code to be enforcing it on a fixed and stable STD76 
standard.  Removing SHA1 is one thing, telling implementations they 
MUST add something new or risk being slapped with non-compliance and 
"malpractice" when they really don't need to do is another, especially 
when STD76+ now mandates signers MUST sign with SHA256.

I suggest changing it to Verifiers SHOULD implement and also correct 
the STD76 text with non-ambiguous functional specification.

> It's not like we reissue RFC 5322 every time someone invents a new

No, but RFC5322 updates do make references among themselves.  I'm sure 
we can find many examples of this.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Sun, 25 Feb 2018 00:30:08 -0800

On Tue, Feb 20, 2018 at 6:54 PM, Salz, Rich <[email-masked]> wrote:

> Will we?  Our intent was to shut down after this last draft is published.
> Is there more to do?  Let's get that on the table, if so.  Aleksey, your
> thoughts?
>

I don't think that's strictly necessary.  As I recall, 8301 updated 6376 to
specifically deprecate a practice the community believes is insecure.
Adding a new algorithm is a step in the opposite direction, so I think
adding ed25519 as a key type just requires IANA actions and the appropriate
documentation, which I believe is what our remaining document already does.

What am I missing?

-MSK

---

From: Stan Kalisch <[email-masked]>
Date: Sun, 25 Feb 2018 22:17:01 -0500

> On Feb 25, 2018, at 3:30 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> I don't think that's strictly necessary.

I don't think it is, either.  To play devil's advocate, the only thing that I see that potentially facilitates mild confusion, in retrospect, is where RFC 8301 reads, "Two algorithms are defined by this specification at this time: rsa-sha1 and rsa-sha256."  This is, of course, correct, but, in theory, in the not-too-distant future, someone modifying an implementation could be up late one night and go, "Oh.  It says 'January 2018' and 'at this time', so I'm good," without checking to see if anything else updates 6376.

This, however, doesn't change the fact that you're supposed to check each RFC to see if something else updates it.  Which is why I don't buy Hector's argument.

Stan

> As I recall, 8301 updated 6376 to specifically deprecate a practice the community believes is insecure.  Adding a new algorithm is a step in the opposite direction, so I think adding ed25519 as a key type just requires IANA actions and the appropriate documentation, which I believe is what our remaining document already does.
> 
> What am I missing?
> 
> -MSK

---

From: Hector Santos <[email-masked]>
Date: Sun, 25 Feb 2018 23:07:18 -0500

That includes the DROP author who is fully aware of RFC8301 and it 
"should" make a reference in order to relax the sha256 mandate imposed 
by RFC8301.

It can't ignorant of the STD76+RFC8301 update.

My opinion.

On 2/25/2018 10:17 PM, Stan Kalisch wrote:
> On Feb 25, 2018, at 3:30 AM, Murray S. Kucherawy <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>> On Tue, Feb 20, 2018 at 6:54 PM, Salz, Rich <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>     Will we?  Our intent was to shut down after this last draft is
>>     published.  Is there more to do?  Let's get that on the table,
>>     if so.  Aleksey, your thoughts?
>>
>>
> I don't think it is, either.  To play devil's advocate, the only thing
> that I see that potentially facilitates mild confusion, in retrospect,
> is where RFC 8301 reads, "Two algorithms are defined by this
> specification at this time: rsa-sha1 and rsa-sha256."  This is, of
> course, correct, but, in theory, in the not-too-distant future,
> someone modifying an implementation could be up late one night and go,
> "Oh.  It says 'January 2018' and 'at this time', so I'm good," without
> checking to see if anything else updates 6376.
>
> This, however, doesn't change the fact that you're supposed to check
> each RFC to see if something else updates it.  Which is why I don't
> buy Hector's argument.
>
>
> Stan
>
>> As I recall, 8301 updated 6376 to specifically deprecate a practice
>> the community believes is insecure.  Adding a new algorithm is a
>> step in the opposite direction, so I think adding ed25519 as a key
>> type just requires IANA actions and the appropriate documentation,
>> which I believe is what our remaining document already does.
>>
>> What am I missing?
>>
>> -MSK
>> [email-masked] <mailto:[email-masked]>

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 26 Feb 2018 00:52:56 -0500

So you think that ed25529 only signing is a good strategy now?

Scott K