Re: [Dcrup] rsa-sha1 usage

["Murray S. Kucherawy" <[e-mail]>]

On Wed, Jun 14, 2017 at 3:02 AM, Seth Blank <[e-mail]> wrote:

> On Wed, Jun 14, 2017 at 5:24 AM, Phillip Hallam-Baker <
> [e-mail]> wrote:
>>
>> It is a two step process in my view. First you rip out the generate,
>> then once the transition is complete, you rip out the accept.
>>
>
> I disagree. SHA-1 has been deprecated for far too long, but is still in
> wide use by major players. I'd argue step 1 was taken ages ago (with a
> SHOULD, not a MUST, but still...) and we're at step 2 *now* because senders
> aren't complying with up-to-date crypto standards on their own.
> [...]
>

I think that's an interesting perspective, specifically that step 1 was
taken a while ago, and I agree.  What we're discussing is the right way to
"rip out the accept".

I don't believe that either actor will be compelled to do anything more by
"MUST NOT" than by simply "We don't use that anymore because $REASONS."
I've been a medium-sized receiver before, and I work for a large sender
now.  If I decide I'm going to comply with the update, either prose is
compelling to me.  Am I exceptional in that regard?  Maybe I'm atypical
because I'm an IETF participant, but to me the general issue here plain old
operational inertia rather than the absence of an RFC telling them what to
do.

If a receiver says "update within 90 days or else", it will happen no
matter what the text says.  It could happen today even without us
publishing anything at all.  I would even posit that it's more likely for
M3AAWG to trigger that action than the IETF.

Please note that I'm not only being sticky on this point because I think
it's wrong.  Unnecessary use of RFC2119 language is a topic that's come up
with nearly every email-related standards track RFC where I've been a
contributor and has resulted in DISCUSSes during IESG Evaluation.  I'm
hoping to head off some of that back-and-forth later by getting it sorted
out now.

-MSK