Re: [Dcrup] rsa-sha1 usage

[Peter Goldstein <[e-mail]>]

> 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.


The phases as described here do not fit the situation at hand.  As written
they mix two separate questions - rsa-sha1 vs rsa-256 and RSA vs Ed25519.
Those need to be considered separately.  Moreover, for the
rsa-sha1/rsa-sha256 the phases are also inappropriate because X is already
~100%

Verifiers were required to support rsa-sha256 by RFC 6376 -
https://tools.ietf.org/html/rfc6376#section-3.3 - and I'm unaware of any
verifier who does not support rsa-sha256.  Combine that with the fact that
a large number of systems (easily the majority of DKIM signers) currently
sign with rsa-sha256 (G Suite, Office365, Facebook, Twitter, etc.) and see
no need to dual sign with rsa-sha1, there's no reason to believe that there
is any significant non-zero population of receivers that validate DKIM for
rsa-sha1 but not for rsa-sha256.  Dual signing with rsa-sha1 and rsa-sha256
is not a necessary step in the rsa-sha1 deprecation process.

Rolling out Ed25519 signing support is a separate question, and it should
not be mixed with the rsa-sha1 deprecation question, even if they are
rolled into one document.  There is, as far as I know, no intention to
deprecate RSA in favor of Ed25519.  Rather the intention is to add Ed25519
as a more modern option for senders that supports shorter keys with better
resistance to attacks.

The current question before the working group is basically a procedural one
- Should we use the RFC2119 MUST NOT language for verifiers and their
acceptance of rsa-sha1 (transitioning from the affirmative SHOULD in RFC
6376) or avoid the use of such language?

Best,

Peter

-- 


[image: logo for sig file.png]

Bringing Trust to Email

Peter Goldstein | CTO & Co-Founder

[e-mail]
+1.415.793.5783 <(415)%20793-5783>