Re: [Dcrup] rsa-sha1 usage

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Jun 14, 2017 at 8:34 AM, Murray S. Kucherawy
<[e-mail]> wrote:
> 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.

I don't understand your line of reasoning. I certainly disagree with it.

DKIM is an IETF specification. If IETF makes a change then M3AAWG will
almost certainly follow suit. But I do not think it at all likely
M3AAWG would start making suggestions on technical matters like this
in preference to IETF action.

People ignore standards all the time. But there are consequences.
Getting people to upgrade their crypto is actually one of the easier
things to persuade people to do. The only circumstance when it becomes
hard is when the new crypto is not widely understood by the
applications that must receive the messages and there is no way to
negotiate an upgrade. That is why S/MIME was stuck doing 3DES for a
decade.


Any transition has to be driven by the state of the deployed
infrastructure. The sequence of facts that need to be gathered are as
follows:

X = proportion of implementations that accept RSA/SHA-2-256 signatures.

Y = proportion of implementations that accept Ed25519 signatures


>From these facts we then build a state machine that guarantees that
95-99% of all messages will be correctly processed by the deployed
infrastructure.

Phase 1) Dual sign with RSA/SHA-1 and RSA/SHA-2-256

Phase 2) Sign with RSA/SHA-2-256

Phase 3) Sign with Ed25519

The decision to use MUST, MUST NOT, etc. is then driven by math.
M3AAWG does not make the decision but they are probably best placed to
collect the data.