MIME-Version: 1.0
In-Reply-To: <44047203.rS5CgVd1do@kitterma-e6430>
References: <33024B2C-DBF1-44DC-A18E-973D4C8ACD12@kitterman.com>
 <3226783.Zmkt5g0zON@kitterma-e6430>
 <c38cbdf473a54a649a5acf4228909741@usma1ex-dag1mb1.msg.corp.akamai.com>
 <44047203.rS5CgVd1do@kitterma-e6430>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Sun, 11 Jun 2017 20:03:30 -0700
Message-ID: <CAL0qLwawfbehfHuz_BoL+pwcA4767MecxPem6EySHZ++M_vtfA@mail.gmail.com>
To: Scott Kitterman <sklist@kitterman.com>
Cc: "dcrup@ietf.org" <dcrup@ietf.org>
Content-Type: multipart/alternative; boundary="f403043eee1c5c6a500551ba90c4"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dcrup/38aNpYoMhsKRXyR9I-v_1xhBYk8>
Subject: Re: [Dcrup] sequence of drafts,
 draft-ietf-dcrup-dkim-usage and document shepherds
Precedence: list

--f403043eee1c5c6a500551ba90c4
Content-Type: text/plain; charset="UTF-8"

I'll reply about the document sequence separately, but on this point:

On Sat, Jun 10, 2017 at 1:29 PM, Scott Kitterman <sklist@kitterman.com>
wrote:

> Personally, I prefer the explicit MUST NOT we had in -01 and I think that's
> along the lines of what Martin Thomson was suggesting.  A hatless msk
> preferred something more like what's there now.
>
> Technically, I think the amount to the same thing.  Is it better to be more
> explicit about what's being removed or be implicit by removing it from
> what's
> specified?  Personally, I think explicit is better than implicit, but
> being a
> Python guy, I would [1]
>

I think the discussion never fully landed, and it may have gotten mixed in
with the discussion about how to regulate key sizes, if it's even possible
to do that.  Only a few opinions have been expressed, and nobody's
commented up or down on the -02 text yet.

Remaining hatless, I prefer the current approach because, like key sizes,
we're not talking about an interoperability concern but rather a policy
one.  There's nothing broken about DKIM implementations that use rsa-sha1.
It's just a bad idea now although it wasn't yet when RFC4871 came out.
Although many receivers may choose to treat all rsa-sha1 signatures as
failed on principle, that's not (and, I would argue, shouldn't be)
intrinsic in the protocol.

My understanding of the use of RFC2119 language is that it's used to
describe choices that affect interoperability, while small key sizes and
use of SHA1 are choices that clearly reduce security but interoperate just
fine.  Then Martin suggested that there's precedent in other RFCs for using
RFC2119 language to discourage use of obsolete security mechanisms.  If
that's the case and we're fine with it, then I'll go along with consensus.

That aside, simply not describing rsa-sha1 going forward, and including an
IANA action to mark it "deprecated" in the registry, seems right to me.  If
we want to add a paragraph in an appendix paying homage to it and including
advice about why its use is no longer a good idea, that's fine too.

-MSK

--f403043eee1c5c6a500551ba90c4
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">I&#39;ll reply about the document sequence separately, but=
 on this point:<br><br>On Sat, Jun 10, 2017 at 1:29 PM, Scott Kitterman <sp=
an dir=3D"ltr">&lt;<a href=3D"mailto:sklist@kitterman.com" target=3D"_blank=
">sklist@kitterman.com</a>&gt;</span> wrote:<br><div class=3D"gmail_extra">=
<div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi=
n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=3D"">=
</span>Personally, I prefer the explicit MUST NOT we had in -01 and I think=
 that&#39;s<br>
along the lines of what Martin Thomson was suggesting.=C2=A0 A hatless msk<=
br>
preferred something more like what&#39;s there now.<br>
<br>
Technically, I think the amount to the same thing.=C2=A0 Is it better to be=
 more<br>
explicit about what&#39;s being removed or be implicit by removing it from =
what&#39;s<br>
specified?=C2=A0 Personally, I think explicit is better than implicit, but =
being a<br>
Python guy, I would [1]<br></blockquote><div><br></div><div>I think the dis=
cussion never fully landed, and it may have gotten mixed in with the discus=
sion about how to regulate key sizes, if it&#39;s even possible to do that.=
=C2=A0 Only a few opinions have been expressed, and nobody&#39;s commented =
up or down on the -02 text yet.<br><br></div><div>Remaining hatless, I pref=
er the current approach because, like key sizes, we&#39;re not talking abou=
t an interoperability concern but rather a policy one.=C2=A0 There&#39;s no=
thing broken about DKIM implementations that use rsa-sha1.=C2=A0 It&#39;s j=
ust a bad idea now although it wasn&#39;t yet when RFC4871 came out.=C2=A0 =
Although many receivers may choose to treat all rsa-sha1 signatures as fail=
ed on principle, that&#39;s not (and, I would argue, shouldn&#39;t be) intr=
insic in the protocol.<br><br></div><div>My understanding of the use of RFC=
2119 language is that it&#39;s used to describe choices that affect interop=
erability, while small key sizes and use of SHA1 are choices that clearly r=
educe security but interoperate just fine.=C2=A0 Then Martin suggested that=
 there&#39;s precedent in other RFCs for using RFC2119 language to discoura=
ge use of obsolete security mechanisms.=C2=A0 If that&#39;s the case and we=
&#39;re fine with it, then I&#39;ll go along with consensus.<br><br></div><=
div>That aside, simply not describing rsa-sha1 going forward, and including=
 an IANA action to mark it &quot;deprecated&quot; in the registry, seems ri=
ght to me.=C2=A0 If we want to add a paragraph in an appendix paying homage=
 to it and including advice about why its use is no longer a good idea, tha=
t&#39;s fine too.<br><br></div><div>-MSK<br></div></div></div></div>

--f403043eee1c5c6a500551ba90c4--