Subject: Re: [Dcrup] new version draft-ietf-dcrup-dkim-crypto-04

From: "John R Levine" <[email-masked]>
Date: 6 Aug 2017 22:53:55 -0400

> This looks pretty good.

Thanks,

> The abstract still says "and deprecates an obsolete signing
> algorithm",

Right, it's gone.

> In the spirit of leaving the removal of the crusty old stuff to the
> other draft, I think that you should:
>
> 1. remove the clause from the abstract
> 2. remove the first paragraph of Section 6 (which specifies the update
> to RFC 6376)
> 3. remove the requirement to use 1024-bit keys for "rsa-sha256"

That makes no sense to me.  Going forward, if DKIM signers and verifiers 
are going to interoperate, the verifiers have to handle every signature 
that a signer can create.  It's not like TLS where they get to negotiate 
at connection time.  So we have to update 6376 to add all the new 
signature methods that a signer might use.  Also remember that the current 
unhashed RSA works just fine for the large fraction of signers whose DNS 
provisioning system isn't broken, so we're not deprecating it.

For the editorial stuff, you're right that I confused p= and k= which I 
think are right in the -05 version.  The text changes don't seem any 
clearer to me so I'll wait and see what other people say.

> Final unrelated comment:
>
> You recommend that "rsafp signatures SHOULD use key lengths of 1536 or
> 2048 bits".

Well, actually, I said 1536 to 2048 bits in one place and 1024 to 2048 in 
another.  Oops.  I took out the second and now says signatures MUST be at 
least 1024 bits and SHOULD be 2048 bits, and verifiers MUST NOT accept 
shorter than 1024.  I think that matches reality, particularly the final 
MUST NOT to get the remaining 512 bit signers to increase the key size.

R's,
John

---

From: Martin Thomson <[email-masked]>
Date: Mon, 7 Aug 2017 14:20:44 +1000

On 7 August 2017 at 12:53, John R Levine <[email-masked]> wrote:
> So we have to update 6376 to add all the new signature
> methods that a signer might use.  Also remember that the current unhashed
> RSA works just fine for the large fraction of signers whose DNS provisioning
> system isn't broken, so we're not deprecating it.

That wasn't my point.  And it might just come back to us disagreeing
what "updates" means, but 6376 clearly establishes an extension point
for new signature algorithms.  Part of that includes the assumption
that verifiers have to be willing to verify any defined algorithm (and
the converse, that signers risk messages being marked as bad because
they fail to include signatures over old algorithms when they add new
ones).

I don't believe that adding a signature algorithm means that you need
to update 6376.

> I took out the second and now says signatures MUST be at
> shorter than 1024.

That works for me.

---

From: "John R Levine" <[email-masked]>
Date: 7 Aug 2017 11:51:00 -0400

> I don't believe that adding a signature algorithm means that you need

Well, OK, but where does all the new ABNF go?

Our plan here is that once this is published, people implement 6376 plus 
this draft plus (or perhaps minus) Scott's anti-SHA1, which tells me that 
these have to update 6376, but in any event, this is a decision for the 
WG or the chairs, not for us.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Martin Thomson <[email-masked]>
Date: Tue, 8 Aug 2017 14:46:22 +1000

> Well, OK, but where does all the new ABNF go?

In your draft?

It's not like you can't define new values, but it's also the case that
you don't have to.  The already-defined extension point covers all
valid values.

> these have to update 6376,

Yes, that's possible without updating 6376.  One problem I've
encountered is that 6376 plus its updates and 6376 plus some other RFC
are materially different to some people.  "Updates" is taken to mean
corrections, and we're not really correcting it - it's perfectly fine.

> but in any event, this is a decision for the WG
> or the chairs, not for us.

I don't think that it's the chairs who decide these things, though I
would certainly respect their views on this.  Ultimately, it's a
community-consensus thing.

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 08 Aug 2017 01:10:30 -0400

> corrections, and we're not really correcting it - it's perfectly fine.

I've never heard that interpretation.  I've seen updates used in the way we 
are discussing lots of times.  See RFC 7208 and RFC 7372 for a reasonably on 
the nose example.

Scott K

P.S.  Any document that considers 512 bit RSA keys OK, is not 'perfectly fine' 
in 2017.

> _______________________________________________
> Dcrup mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dcrup