Subject: Re: [Dcrup] I-D Action: draft-ietf-dcrup-dkim-usage-00.txt

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Jun 2017 00:24:47 -0400

On Tuesday, May 30, 2017 05:58:51 PM [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the DKIM Crypto Update of the
> IETF.
> 
>         Title           : Cryptographic Algorithm and Key Usage to DKIM
>         Author          : Scott Kitterman
> 	Filename        : draft-ietf-dcrup-dkim-usage-00.txt
> 	Pages           : 5
> 	Date            : 2017-05-30
> 
> Abstract:
>    The cryptographic algorithm and key size requirements included when
>    DKIM was designed in the last decade are functionally obsolete and in
>    need of immediate revision.  This document updates DKIM requirements
>    to those minimaly suitable for operation with currently specified
>    algorithms.  This document updates RFC 6376.

This is a pretty simple draft.  It does two things:

1.  Changes signers SHOULD sha-256 and verifiers MUST support both sha-1 and 
sha-256 to signers/verifiers MUST sha-256 and MUST not sha-1.  It does nothing 
about adding anything new as there will be other documents for that.

2.  Changes signers MUST at least 1024 bits for long live keys (long lived is 
never defined) and verifiers MUST support 512 bits to 2048 bits to signers 
SHOULD use 2048 bit keys and MUST use at least 1024 and verifiers MUST support 
1024 to 4096 bits.

I think the ABNF for the a=tag in 3.5 and the h= tag in 3.6.1 should be 
updated to remove sha1.  I missed that in the first draft.

Based on the discussion before I submitted the draft, I don't think any of 
this is very controversial.  We've already discussed the trade-offs on key 
length.  I don't recall that we explicitly discussed MUST NOT sha1.  Given the 
WG will later add other new algorithms and it's been required to support 
sha256 from the beginning, I think that's the right answer, but it might merit 
some further discussion.

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Fri, 2 Jun 2017 12:49:05 +0800

On Jun 2, 2017 8:24 AM, "Scott Kitterman" <[email-masked]> wrote:

>       Filename        : draft-ietf-dcrup-dkim-usage-00.txt

I think that this does not quite go far enough in shifting the algorithms
and acceptable key lengths into an IANA registry to future-proof the spec
and allow more rapid response in the case of exploit advancement.

I'd like to see both of those pieces "out sourced" to a registry with
updates to be driven by crypto-competent people.

--Kurt

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Jun 2017 05:35:09 +0000

>updates to be driven by crypto-competent people.

I think that belongs in draft-ietf-dcrup-dkim-crypto.  

Once we know what the new crypto is, how it will be represented in DNS, and what key lengths are appropriate, then it will be easy to lay out a proper registry.  When that registry is created, this document can serve as the reference for the initial values.

Let's not draw the additional complexity of other than the minimal IANA updates that are already specified into this draft.

Scott K

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jun 2017 22:35:24 -0700

(sans chapeau)

I realize I have some threads to catch up on, but...

> updates to be driven by crypto-competent people.

This notion feels weird to me.  What would such a registry look like?  Are
there any other protocol registries that contain just a list of key sizes
or lengths of things currently approved by the community?  What would the
update rules be on such a registry?

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Jun 2017 05:40:48 +0000

>update rules be on such a registry?

Great examples of the kinds of questions that would take some time to answer and thus why I think this document, which is supposed to be the quick, easy bits of the update isn't the place for it.

Scott K

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Jun 2017 15:41:11 +1000

On 2 June 2017 at 15:35, Murray S. Kucherawy <[email-masked]> wrote:
> there any other protocol registries that contain just a list of key sizes or
> lengths of things currently approved by the community?  What would the

TLS does this for cipher suites.  The policy there is to allow
registration of entries with a low bar, but to require a higher bar
(Standards Track) for entries that mark the entry as "recommended".

See https://datatracker.ietf.org/doc/html/draft-ietf-tls-iana-registry-updates#section-7

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jun 2017 22:41:41 -0700

As a participant only here:

> SHOULD use 2048 bit keys and MUST use at least 1024 and verifiers MUST

I think my only issue with the document is the use of RFC2119 language
about key sizes.  I'm totally comfortable with saying what implementations
have to support, because that goes to interoperability, which is what I
understood the RFC2119 nomenclature to be for.  But I'm not so sure about
its use to talk about key sizes.

More specifically: DKIM interoperates just fine with 512 bit keys or even
smaller; the protocol itself doesn't break.  The choice to use smaller keys
is a risk issue, not an interoperability concern.  We should certainly call
that out firmly, but I'm iffy about the MUSTard here.

Are there other standards track documents that do this?

-MSK, hatless

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Jun 2017 15:45:46 +1000

On 2 June 2017 at 15:41, Murray S. Kucherawy <[email-masked]> wrote:
> I think my only issue with the document is the use of RFC2119 language about
> key sizes.  I'm totally comfortable with saying what implementations have to
> support, because that goes to interoperability, which is what I understood
> the RFC2119 nomenclature to be for.  But I'm not so sure about its use to
> talk about key sizes.

RFC 7540 does just that.

The recent trend is to signal fixed key sizes for algorithms, which
does the same thing in a different way.  For example,
https://datatracker.ietf.org/doc/html/draft-ietf-tokbind-protocol#section-3.3
 That boat sailed for DKIM, but it is another way of applying MUSTard
to key sizes.

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jun 2017 22:45:52 -0700

> registry-updates#section-7

So in our context, we would register a pile of entries that look something
like:

rsa-sha256-with-1024-bit-keys
rsa-sha256-with-2048-bit-keys
rsa-sha256-with-4096-bit-keys

...and possibly numerous other size-specific entries, each referencing a
defining document?

We already have a registry of supported signing algorithms, of which
"rsa-sha256" would be the only valid one after this is published.  So there
would really be just a registry of permitted key sizes.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Jun 2017 05:55:22 +0000

On June 2, 2017 1:41:41 AM EDT, "Murray S. Kucherawy" <[email-masked]> wrote:
>> 1.  Changes signers SHOULD sha-256 and verifiers MUST support both
>sha-1
>> and
>> sha-256 to signers/verifiers MUST sha-256 and MUST not sha-1.  It
>does
>> nothing
>> 2.  Changes signers MUST at least 1024 bits for long live keys (long
>lived
>> is
>> SHOULD use 2048 bit keys and MUST use at least 1024 and verifiers
>MUST
>> support
>> 1024 to 4096 bits.
>>
>

I don't know, but it seems to me that if a signer uses a key length that receivers will consider invalid, you've absolutely got an interoperability problem.  

It's no different than saying MUST use a particular crypto algorithm.  It's one of the parameters that if the signer doesn't use something that the verifier supports, there is no interoperability.

Scott K

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Jun 2017 16:05:51 +1000

> ...and possibly numerous other size-specific entries, each referencing a

Nah, you already have a generic codepoint for just "rsa", so keep
that.  ed25519 will come with a fixed size, and maybe anything *new*
should.

I'm just pointing to a trend that supports the notion that standards
can choose key sizes.  After all, if you don't standardize on a
513-bit rsa key, then you can't signal and use it (and everyone wins,
because that would be too small).

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jun 2017 23:06:15 -0700

On Thu, Jun 1, 2017 at 10:55 PM, Scott Kitterman <[email-masked]>
wrote:

> I don't know, but it seems to me that if a signer uses a key length that
> receivers will consider invalid, you've absolutely got an interoperability
> problem.
>

You can do this in OpenDKIM today with a configuration setting.  That's
perhaps why I'm asking this question; to me, today, it's a local policy
decision, not one that's demanded by the implementation, which means it's
not truly an interoperability issue.

It's no different than saying MUST use a particular crypto algorithm.  It's
> one of the parameters that if the signer doesn't use something that the
> verifier supports, there is no interoperability.
>

I disagree.  RSA works fine even with tiny keys.  It's obviously not smart
to use RSA that way, but publishing a document that says tiny keys are bad
doesn't mean RSA breaks when you use them.  It interoperates just fine.

We're establishing an artificial interoperability constraint on RSA here by
saying keys must be at least X size to use them with RSA in the context of
DKIM.  I don't disagree that this is the right thing to do, I just want to
say it the right way.

I had never seen the examples Martin presented, and perhaps they're
precedent enough.

-MSK

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 1 Jun 2017 23:11:59 -0700

> because that would be too small).

Yeah, that's new information to me, and it's possibly good enough to
address the concern.  I'll wait and see what the registry looks like as
these documents evolve.

We don't signal anything about key sizes though, do we?  They're an
intrinsic part of the key that's fetched from DNS; openssl tells me the
size of the key after I've opened it up.  The only thing actually imposed
right now by DKIM is a minimum size.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Fri, 02 Jun 2017 06:17:41 +0000

>I had never seen the examples Martin presented, and perhaps they're

Okay, but your 'just fine' only works if both signer and verifier make compatible choices.  When a correctly signed message fails verification, I would definitely think that there's a lack of interoperability.

Scott K

---

From: Martin Thomson <[email-masked]>
Date: Fri, 2 Jun 2017 16:18:15 +1000

On 2 June 2017 at 16:11, Murray S. Kucherawy <[email-masked]> wrote:
> intrinsic part of the key that's fetched from DNS; openssl tells me the size
> of the key after I've opened it up.  The only thing actually imposed right
> now by DKIM is a minimum size.

Yeah, most RSA public keys just encode the numbers with a length
prefix.  You just look to see how big they are and decide if it's
strong enough based on policy.

You are right to point out that the question of whether you *could*
use a key is orthogonal to whether you *want* to use the key.  The
former is interoperability, the latter is - yes - policy.  Sometimes
it makes sense to agree on a baseline for policy though.  Fewer
surprises that way.

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2017 13:15:34 -0000

>(Standards Track) for entries that mark the entry as "recommended".

TLS does cipher negotiation, DKIM doesn't, because TLS has a two-way
path between sender and recipient.  That means that adding new
algorithm to DKIM is hard and slow, because signers can't use them
(other than in parallel with older algorithms) until a sufficient
number of verifiers implement them.  That's why my draft adds one (1)
new algorithm that is intended to be good enough to last for a long
time.  The current draft may not have the best algo for that goal, but
that's why it's still a draft.

I'm also somewhat sceptical of outsourcing key strength advice.  You
don't pick key strengths in a vacuum and DKIM is in an odd place with
signatures that last for a week, not a few seconds like in TLS or
years like S/MIME or PGP signatures.  Writing a new RFC that updates
key strength advice needn't be hard unless we make it hard.

R's,
John

---

From: "Rose, Scott" <[email-masked]>
Date: Fri, 2 Jun 2017 10:02:27 -0400

Some communities have a larger security policy on algorithms, key 
lengths, etc. that they are compelled to comply to rather than 
per-protocol recommendations. Usually admins follow it out of routine or 
simply to keep auditors from complaining.  Listing what a validator MUST 
be able to support is good, but dictating what a sender MUST use might 
lead to issues.

I agree on only adding 1 (two at most) algorithms to DKIM.  Too many 
algorithms leads to confusion among implementors and deployments as to 
what is the recommended algorithm.  DNSSEC is facing this now and there 
are now several drafts about which algorithms should be mandatory, which 
should be retired, etc.

Scott

On 2 Jun 2017, at 9:15, John Levine wrote:

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

===================================
Scott Rose
NIST ITL
[email-masked]
+1-301-975-8439
GV: +1-571-249-3671
===================================

---

From: Russ Housley <[email-masked]>
Date: Fri, 2 Jun 2017 14:54:51 -0400

> On Jun 2, 2017, at 1:35 AM, Murray S. Kucherawy <[email-masked]> wrote:
> 
> (sans chapeau)
> 
> On Thu, Jun 1, 2017 at 9:49 PM, Kurt Andersen <[email-masked] <mailto:[email-masked]>> wrote:
> I think that this does not quite go far enough in shifting the algorithms and acceptable key lengths into an IANA registry to future-proof the spec and allow more rapid response in the case of exploit advancement.
> 
> I'd like to see both of those pieces "out sourced" to a registry with updates to be driven by crypto-competent people.
> 
> This notion feels weird to me.  What would such a registry look like?  Are there any other protocol registries that contain just a list of key sizes or lengths of things currently approved by the community?  What would the update rules be on such a registry?

I am aware of some registries that include a column to mark aged algorithms as “Not recommended.”

I have not seen a registry that included a minimum key size column.

Russ

---

From: "Rose, Scott" <[email-masked]>
Date: Mon, 5 Jun 2017 12:21:08 -0400

I’ve read the draft and I admire the willingness to plant a stake in 
the ground in making rsa-sha1 obsolete.

I think it would help to be more explicit about which requirement 
applies to which role (implement vs deploy/administrate).  For example:

3 DKIM Signing and Verification Algorithms

    This section replaces [RFC6376] Section 3.3 in its entirety.

    DKIM supports multiple digital signature algorithms.  Two algorithms
    were defined by [RFC6376]: rsa-sha1 and rsa-sha256.  Signers MUST
    implement and sign using rsa-sha256.  Verifiers MUST implement rsa-
    sha256 and MAY implement rsa-sha1 for backwards compatibility.
    The rsa-sha1 signing algorithm is obsolete and MUST NOT be
    used.

3.1.  The rsa-sha1 Signing Algorithm

    This algorithm is obsolete and MUST NOT be used by signers.

This doesn’t change the main idea, but calls out the fact that 
rsa-sha1 will be sticking around for a period of time as administrators 
are not going to read this doc and/or not going to change things that 
are working for them now.

Scott

On 30 May 2017, at 20:58, [email-masked] wrote:

> directories.
> This draft is a work item of the DKIM Crypto Update of the IETF.
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dcrup-dkim-usage/
>
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dcrup-dkim-usage-00
> https://datatracker.ietf.org/doc/html/draft-ietf-dcrup-dkim-usage-00
>
>
> Please note that it may take a couple of minutes from the time of 
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Jun 2017 12:53:38 -0400

I hear you.  I expect this to be the most contentious part of the draft.

Here's my counter argument:

The first DKIM RFC (RFC 4871), published in 2007 said:

> Signers MUST implement and SHOULD sign using rsa-sha256

I believe that the only reason rsa-sha1 was included at all was to make 
transition from domainkeys easier (see RFC 4870).  That's also (as I 
understand it where the 512 bit minimum key size came from).

We've already had a decade for transition.  I think we are well into the 
territory that if there are signatures being done with rsa-sha1, it's unlikely 
to change until they stop working.

In related news, I added an informative reference to RFC 6194 and mentioned it 
in security considerations.

Fundamentally, I don't think anything other than removing it entirely changes 
anything.  As long as receivers MAY, they probably will and if they don't 
senders will complain "Why didn't you?", it's still allowed.  MUST NOT on both 
sides of the equation gives a clear answer.  "Go read RFC XXXX.  If it's a 
problem for you, you aren't doing something you SHOULD have been doing since 
2007, so you own the interoperability problem."

If someone doesn't want to drop rsa-sha1, they are free to not implement that 
change, so I don't see leaving the MAY in there for receivers as advantageous.

We know we need to add a new algorithm to replace it and two is plenty.  Let's 
kill it dead.

As a working group document editor, I'll change it however the group wants (of 
course), but I think we should either kill rsa-sha1 entirely in this document 
or leave it out entirely and let one of the follow-on documents add a new 
algorithm and remove rsa-sha1.  Preferably a clean kill or, failing that, not 
at all is what I think we should do.

Scott K

On Monday, June 05, 2017 12:21:08 PM Rose, Scott wrote:
> >         Title           : Cryptographic Algorithm and Key Usage to
> > 
> > DKIM
> > 
> >         Author          : Scott Kitterman
> > 	
> >    DKIM was designed in the last decade are functionally obsolete and
> > 
> > in
> > 
> >    need of immediate revision.  This document updates DKIM
> > 
> > requirements
> >

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 5 Jun 2017 13:18:13 -0700

> understand it where the 512 bit minimum key size came from).

As I recall, there were also implementations of DKIM made during its
development (even before its IETF time) that supported both, and defaulted
to rsa-sha1 because support for SHA256 in OpenSSL was new and not
universally deployed.  Some of them were still running in the wild, and
SHA1 wasn't fully deprecated, so the choice was made to be inclusive while
encouraging use of the newer stuff as much as possible.

> at all is what I think we should do.

I would omit it from the updated version entirely, and mark it "obsolete"
in the registry.

-MSK, from the floor

---

From: Jim Fenton <[email-masked]>
Date: Mon, 5 Jun 2017 13:23:41 -0700

On 6/5/17 1:18 PM, Murray S. Kucherawy wrote:
> On Mon, Jun 5, 2017 at 9:53 AM, Scott Kitterman <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> development (even before its IETF time) that supported both, and
> defaulted to rsa-sha1 because support for SHA256 in OpenSSL was new
> and not universally deployed.  Some of them were still running in the
> wild, and SHA1 wasn't fully deprecated, so the choice was made to be
> inclusive while encouraging use of the newer stuff as much as possible.

That matches my recollection. There was an effort to maintain DomainKeys
compatibility for selector (DNS TXT) records but the choice of hash
doesn't affect them. The signatures were different anyway.
> I would omit it from the updated version entirely, and mark it
> "obsolete" in the registry.

Concur.

-Jim

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Jun 2017 16:24:39 -0400

> I would omit it from the updated version entirely, and mark it "obsolete"

OK.  Unfortunately I mashed the upload button on -01 before I saw this, but 
that makes sense to me.  I'll do it for -02.  

Unfortunately the draft submission site got confused about me being me, so I'm 
waiting for an email to confirm it's OK to change the author of the draft from 
me to me, so it may be a few minutes before it shows up.

Thanks,

Scott K

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 05 Jun 2017 16:35:08 -0400

> I would omit it from the updated version entirely, and mark it "obsolete"

How about this (rfcdiff attached)?

Scott K