Subject: Re: [Dcrup] Adam Roach's No Objection on draft-ietf-dcrup-dkim-usage-04: (with COMMENT)

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 19 Oct 2017 00:37:16 -0700

Reducing distribution since this has been approved, but just to close the
issues raised by the IESG Review:

On Tue, Sep 26, 2017 at 10:40 PM, Adam Roach <[email-masked]> wrote:

>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I would have expected section 4 to be explicit in the interaction between
> the
> requirement that "rsa-sha1 MUST NOT be used for signing or verifying" and
> the
> Authentication-Results header defined in RFC 7001. In particular, I would
> have
> expected to see guidance here whether receipt of a message using sha1
> should be
> coded as "neutral" or "policy": as an implementor, I would be unsure which
> one
> to use.

I think this is worth considering.  What guidance (if any) should we
provide to a verifier that receives an "rsa-sha1" signature in terms of how
to record it in an A-R field?  One could make an argument for either of the
two proposed results.

-MSK

---

From: Martin Thomson <[email-masked]>
Date: Thu, 19 Oct 2017 19:47:30 +1100

On Thu, Oct 19, 2017 at 6:37 PM, Murray S. Kucherawy
<[email-masked]> wrote:
> I think this is worth considering.  What guidance (if any) should we provide
> to a verifier that receives an "rsa-sha1" signature in terms of how to
> record it in an A-R field?  One could make an argument for either of the two
> proposed results.

I would agree, it's worth putting some text in even.  Perhaps you
could simply state:  "A valid "rsa-sha1" signature provides only a
weak signal about the origin of a message and it SHOULD NOT be used as
a signal that a message is authentic.  However, until stronger
signature methods are widely available, a signature using "rsa-sha1"
MAY be used to distinguish messages from those that have no or invalid
signatures."

You might also say, "Receipt of a message with only an "rsa-sha1"
signature from a domain that has previously used stronger signatures
might be treated as suspicious."  But that's getting into crazy-land.

---

From: Scott Kitterman <[email-masked]>
Date: Thu, 19 Oct 2017 10:54:46 +0000

On October 19, 2017 4:47:30 AM EDT, Martin Thomson <[email-masked]> wrote:
>provide

My assumption had been that since there's no valid signature with rsa-sha1, there's nothing to even consider putting in an A-R header field.

I think the only result that can go in this case is None.  I hadn't thought we'd need to say that, but I guess maybe we do.

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Thu, 19 Oct 2017 08:46:27 -0700

On Thu, Oct 19, 2017 at 3:54 AM, Scott Kitterman <[email-masked]>
wrote:

>
> My assumption had been that since there's no valid signature with
> rsa-sha1, there's nothing to even consider putting in an A-R header field.
>
> I think the only result that can go in this case is None.  I hadn't
> thought we'd need to say that, but I guess maybe we do.
> <https://www.ietf.org/mailman/listinfo/dcrup>
>

I agree with Scott. The presence of a DKIM signature that is too weak to
trust (whether that is too short of a key or a non-supported hash
algorithm) equates to no DKIM signature at all.

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Oct 2017 12:58:10 -0700

> thought we'd need to say that, but I guess maybe we do.

I think "policy" is the right way to go.  There's nothing technically wrong
with an rsa-sha1 signature, but you're deciding not to accept it.  It's the
same as you deciding you're not going to accept a perfectly valid
rsa-sha256 signature on a message simply because that signature didn't
include the Subject field.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Oct 2017 13:03:57 -0700

On Tue, Oct 24, 2017 at 12:58 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> I think "policy" is the right way to go.  There's nothing technically
> wrong with an rsa-sha1 signature, but you're deciding not to accept it.
> It's the same as you deciding you're not going to accept a perfectly valid

In fact I would claim that by the definitions in Section 2.7.1 of RFC7601,
"policy" is the only option.

-MSK

---

From: Seth Blank <[email-masked]>
Date: Tue, 24 Oct 2017 13:05:36 -0700

> "policy" is the only option.

I wanted to strongly argue for "fail" over "policy" here - but I concur
that within the confines of the current definition of fail in 7601,
"policy" is the only option that fits.

   fail:  The message was signed and the signature or signatures were
      acceptable to the ADMD, but they failed the verification test(s).

-- 

Bringing Trust to Email

Seth Blank | Director of Industry Initiatives
[email-masked]
+1-415-894-2724 <415-894-2724>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Oct 2017 13:48:43 -0700

On Tue, Oct 24, 2017 at 1:05 PM, Seth Blank <[email-masked]> wrote:

>> In fact I would claim that by the definitions in Section 2.7.1 of
>> RFC7601, "policy" is the only option.
>>
>

What about "permerror"?

-MSK

---

From: Seth Blank <[email-masked]>
Date: Tue, 24 Oct 2017 13:52:03 -0700

> What about "permerror"?

   permerror:  The message could not be verified due to some error that
      is unrecoverable, such as a required header field being absent.  A
      later attempt is unlikely to produce a final result.

Yes, that's much better.

-- 

Bringing Trust to Email

---

From: Kurt Andersen <[email-masked]>
Date: Tue, 24 Oct 2017 23:35:22 +0000

On Tue, Oct 24, 2017 at 8:03 PM, Murray S. Kucherawy <[email-masked]>
wrote:

> On Tue, Oct 24, 2017 at 12:58 PM, Murray S. Kucherawy <[email-masked]
> > wrote:
>

Are we talking about before or after this group consigns sha1 to the ash
heap? Perhaps I'm confused about the sequencing of events that we are
discussing. If the original DKIM spec had allowed rsa-md5 and a previous
(hypothetical) instance of DCRUP had similarly deprecated MD5, what sort of
designation would we expect to be recorded today for such usage?

--Kurt

---

From: Brandon Long <[email-masked]>
Date: Tue, 24 Oct 2017 16:46:28 -0700

On Tue, Oct 24, 2017 at 4:35 PM, Kurt Andersen <[email-masked]> wrote:

>> On Tue, Oct 24, 2017 at 12:58 PM, Murray S. Kucherawy <
>> [email-masked]> wrote:
>>

This is obviously a bit different, but today google uses policy for keys
under 1024 bits.  I say "different", because prior to the dcrup work being
published, that's our policy choice.  After, it's the standard, so
permerror might be more appropriate.

Brandon

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Oct 2017 00:24:19 +0000

>permerror might be more appropriate.

I prefer None, but I think permerror is reasonable.  Policy means local policy (as you are doing now).  Once this is approved, not accepting short keys ( < 1024 ) or rsa-sha1 is not just a local policy call.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 24 Oct 2017 21:15:05 -0700

On Tue, Oct 24, 2017 at 4:35 PM, Kurt Andersen <[email-masked]> wrote:

> heap?

Concurrent with.

Perhaps I'm confused about the sequencing of events that we are discussing.
> If the original DKIM spec had allowed rsa-md5 and a previous (hypothetical)
> instance of DCRUP had similarly deprecated MD5, what sort of designation
> would we expect to be recorded today for such usage?
>

The question's never been asked before, so I don't know how to answer
that.  But I don't think "none" is right unless we also want to contend
that a DKIM-Signature field with a syntax error in it also warrants a
"none", which I don't believe is the case.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 25 Oct 2017 00:32:05 -0400

> "none", which I don't believe is the case.

You've convinced me "none" is not what we want.  I think that your 
hypothetical DKIM signature warrants a "permerror" and that's what we should 
use here.

Scott K

---

From: Seth Blank <[email-masked]>
Date: Wed, 25 Oct 2017 04:59:21 -0700

> hypothetical DKIM signature warrants a "permerror" and that's what we

As a report receiver, "permerror" is a much clearer signal than "fail" that
there's an error on the domain owner's end that requires fixing. I'm now
convinced and retract my earlier "it should be fail" comment.

-- 

Bringing Trust to Email

---

From: Kurt Andersen <[email-masked]>
Date: Wed, 25 Oct 2017 14:52:51 +0000

On Wed, Oct 25, 2017 at 4:32 AM, Scott Kitterman <[email-masked]>
wrote:

> RFC7601,

Makes sense to me - thanks for hashing through this (no pun intended).

--Kurt

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 25 Oct 2017 09:49:11 -0700

> hypothetical DKIM signature warrants a "permerror" and that's what we

OK, then I think we're in agreement on how to edit the draft to respond to
the raised issues and resubmit so Alexey can send it off to the RFC Editor.

Thanks everyone!

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 27 Oct 2017 17:52:59 -0400

> the raised issues and resubmit so Alexey can send it off to the RFC Editor.

I have uploaded -05 to address these two issues and a typo fix that had been 
previously identified:

https://www.ietf.org/rfcdiff?url1=draft-ietf-dcrup-dkim-usage-04&url2=draft-ietf-dcrup-dkim-usage-05

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 27 Oct 2017 18:20:26 -0700

Alexey, was there anything else or are we all set here?

-MSK

On Fri, Oct 27, 2017 at 2:52 PM, Scott Kitterman <[email-masked]>
wrote:

> https://www.ietf.org/rfcdiff?url1=draft-ietf-dcrup-dkim-
> usage-04&url2=draft-ietf-dcrup-dkim-usage-05
>
> Scott K
>
> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup
>