Subject: [ietf-dkim] DKIM Key Size Constraints

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 May 2015 13:06:11 -0400

RFC 6376 (which I think is the latest) includes:

> 3.3.3.  Key Sizes
> 
>    Selecting appropriate key sizes is a trade-off between cost,
>    performance, and risk.  Since short RSA keys more easily succumb to
>    off-line attacks, Signers MUST use RSA keys of at least 1024 bits for
>    long-lived keys.  Verifiers MUST be able to validate signatures with
>    keys ranging from 512 bits to 2048 bits, and they MAY be able to
>    validate signatures with larger keys.  Verifier policies may use the
>    length of the signing key as one metric for determining whether a
>    signature is acceptable.

Since receivers have no good way of knowing what keys are long-lived, there's 
no way on the receiver side to reliably determine if a key shorter than 1024 
bits is being appropriately used or not.  I think it's time to kill keys 
shorter than 1024 bits dead.  It's not like the risks associated with them are 
new [1].

I propose a short draft that updates 6376 to say MUST use at least 1024 bits 
and setting that as the minimum size verifiers must be able to validate.  I'm 
volunteering to write it if people agree it's appropriate.

Scott K

[1] http://www.wired.com/2012/10/dkim-vulnerability-widespread/
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Mon, 11 May 2015 12:04:19 -0700

Dear Scott,

Signatures normally offer options not easily supported by
DKIM.  One being use of a binary keys, rather than base64. 
Indeed shorter keys were a mistake.  What other mistakes
should be corrected?  I can name a few.

Regards,
Douglas Otis

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 11 May 2015 15:27 -0400

On Monday, May 11, 2015 12:04:19 PM Douglas Otis wrote:
> > Since receivers have no good way of knowing what keys are long-lived,
> > there's no way on the receiver side to reliably determine if a key
> > shorter than 1024 bits is being appropriately used or not.  I think it's
> > time to kill keys shorter than 1024 bits dead.  It's not like the risks
> > associated with them are new [1].
> > 
> > I propose a short draft that updates 6376 to say MUST use at least 1024
> > bits and setting that as the minimum size verifiers must be able to
> > validate.  I'm volunteering to write it if people agree it's appropriate.
> > 
> > Scott K
> > 
> > 

I'm not particularly interested in a comprehensive update to DKIM.  Time has 
passed.  Moore's Law has operated.  It's time to change the minimum key size 
(past time, IMO).  I'd much rather get that done as I don't think it will be 
controversial rather than get into a broader debate that might get bogged 
down.

Scott K

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 12 May 2015 07:23:26 +0000

> volunteering to write it if people agree it's appropriate.

I think it is appropriate - and I agree with others that we shouldn't go beyond that.

Though why not make it even stronger and say that verifiers MUST (or SHOULD, perhaps) consider signatures with keys shorter than 1024 bits invalid? This makes it even more explicit.

Martijn.

________________________________

Virus Bulletin Ltd, The Pentagon, Abingdon, OX14 3YP, England.
Company Reg No: 2388295. VAT Reg No: GB 532 5598 33.

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 07:28:25 -0400

-1

Please stop! No more DKIM code changes ok?  The IETF just made it a STD.

Maybe we should remove the STD status first, move it back to proposed 
standard or experimental if this and other changes are coming.

If signers want 1024 bits, then can do so ready.

-- 
HLS

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 May 2015 08:56:17 -0400

>If signers want 1024 bits, then can do so ready.

True, but irrelevant.

The change that's needed is to remove the requirement for receivers to verify signatures with keys to small to be secure. 

Any cryptographic protocol will need periodic adjustment to remain secure.  I'm surprised you are surprised. 

Presumably your implementation already checks for the current minimum key size of 512 bits. If changing that constant to 1024 is too hard, I think you're doing it wrong. 

Scott K

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 09:16:29 -0400

I am not concern about us (Santronics) and our DKIM implementation 
with 1024 bit support on both ends per STD.  I am concern about 
everyone else.   In other words, I am not about to begin invalidating, 
rejecting perfectly signed DKIM 512 bit hashed messages purely based 
on your revised MUST.   That is when the engineering begins to go 
wrong.  If I would even consider it, it would be made optional anyway:

     [_] Enforce 1024 bit hashing

If you are going to proposes changes, then think about all the other 
considerations already being done to revise, "enhanced" DKIM.    I am 
tired of all the "patch work" and lack of engineering insights 
requiring later "adjustments."  Perhaps it was premature to make DKIM 
a STD.

All you can at best is a "SHOULD" and I am pretty sure that is how the 
more STD closer DKIM implementations currently does it at this point 
in time.   In other words, most likely the default settings are 1024 
bits.  Maybe you can write an informational I-D recommending 
implementations to change their defaults and/or even perhaps suggest, 
not mandate they they remove the option.

By why?   We don't have this theoretical exploit in action and its 
easily addressable with all the current DKIM features and options.

-- 
HLS

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 12 May 2015 13:16:05 +0000

> -----Original Message-----
> From: [email-masked] [mailto:ietf-dkim-
> [email-masked]] On Behalf Of Martijn Grooten
> Sent: Tuesday, May 12, 2015 3:23 AM
> To: [email-masked]
> Subject: Re: [ietf-dkim] DKIM Key Size Constraints
> 
> > I propose a short draft that updates 6376 to say MUST use at least
> > 1024 bits and setting that as the minimum size verifiers must be able
> > to validate.  I'm volunteering to write it if people agree it's appropriate.
> 
> Though why not make it even stronger and say that verifiers MUST (or
> SHOULD, perhaps) consider signatures with keys shorter than 1024 bits
> invalid? This makes it even more explicit.
> 

+1

I think that Scott is correct in suggesting that this proposed update be limited to setting the minimum size (and nothing else). I also like the suggestion of considering anything smaller than 1024 invalid (Thank you Martijn). This should be a quick and easy update.

Apart from that I think we should start a (separate) effort to determine where we go from here. For the most part 2048 length keys seem not to be a problem in the wild at this time. On the other hand, given the speed (or lack thereof) involved in working groups generating useful output, if we start now (for some definition of now) we should (hopefully) have a solution before 2048 keys are at risk.

Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 10:34:40 -0400

STD76, DKIM is an Internet Standard, already has a Signer/Verifier 
migration path in section 3.3 towards the higher key with backward 
compatibility support for the verification of the smaller key.

Why remove 512 support from the verification side?  Does this mean the 
verifier will take valid 512 signature and make it invalid, no 
signature message?  Is there a correlation out there that 512 bits 
signers are more prune to be Bad Guys? Spammers?

Lets also remember what the rest of STD76 section 3.3 says:

   Factors that should influence the key size choice include the
    following:

    o  The practical constraint that large (e.g., 4096-bit) keys might
       not fit within a 512-byte DNS UDP response packet

    o  The security constraint that keys smaller than 1024 bits are
       subject to off-line attacks

    o  Larger keys impose higher CPU costs to verify and sign email

    o  Keys can be replaced on a regular basis; thus, their lifetime can
       be relatively short

    o  The security goals of this specification are modest compared to
       typical goals of other systems that employ digital signatures

    See [RFC3766] for further discussion on selecting key sizes.

IMO, this is all still true. It hasn't change.  Has it?

-- 
HLS

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 12 May 2015 15:31:30 +0000

> verifier will take valid 512 signature and make it invalid, no signature
> message?  Is there a correlation out there that 512 bits signers are more
> prune to be Bad Guys? Spammers?

The problem here is that 512-bit keys can be trivially broken: it takes less than 8 hours and about 100 USD to do so[1]. So there is no way to be certain that the signer of the message is the same organisation that published the (512-bit) DKIM key, even if that organisation only were to send email that everyone would want to receive.

You are right to point out that the RFC says that "[t]he security goals of this specification are modest", which indeed they are, but I think 100 USD is well within the means of the kind of adversary DKIM is trying to protect against. The story of Google's 512-bit key that Scott already pointed to[2] gives at least some anecdotal evidence about why this matters in practice.

Martijn.

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 12 May 2015 15:35:55 +0000

PS References that were left out of the version of the email I did not send to Hector only:

[1] http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html
[2] http://www.wired.com/2012/10/dkim-vulnerability-widespread/

---

From: "John R. Levine" <[email-masked]>
Date: 12 May 2015 10:44:14 -0400

> Apart from that I think we should start a (separate) effort to determine 
> where we go from here. For the most part 2048 length keys seem not to be 
> a problem in the wild at this time. On the other hand, given the speed 
> (or lack thereof) involved in working groups generating useful output, 
> if we start now (for some definition of now) we should (hopefully) have 
> a solution before 2048 keys are at risk.

The only problem I'm aware of is the 512 byte UDP DNS packet size.  Is 
anyone aware of actual stats on how often larger packets fail?

The IETF is not useful here.  The IETF DNS crowd swears that it's not a 
problem at all and anyone who believes otherwise is stupid.

R's,
John

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 12 May 2015 17:55:38 +0200

> anyone aware of actual stats on how often larger packets fail?

for that reason I started using 4096 bit dkim keys years ago.
but message modifications are the only relevant reason of broken dkim  
sigs here.

Andreas

---

From: "MH Michael Hammer (5304)" <[email-masked]>
Date: Tue, 12 May 2015 17:07:57 +0000

> From: John R. Levine [mailto:[email-masked]]
> Sent: Tuesday, May 12, 2015 10:44 AM
> To: MH Michael Hammer (5304)
> Cc: [email-masked]
> > Apart from that I think we should start a (separate) effort to
> > determine where we go from here. For the most part 2048 length keys
> > seem not to be a problem in the wild at this time. On the other hand,
> > given the speed (or lack thereof) involved in working groups
> > generating useful output, if we start now (for some definition of now)
> > we should (hopefully) have a solution before 2048 keys are at risk.
> 

I suppose in one sense they are correct in that between TCP fallback and EDNS0 there shouldn't be a problem. On the other hand we know (or should know) that there are a number of firewall implementations that don't allow for TCP fallback (DOH!) for larger packets and/or have a hard limit of 512 bytes for UDP DNS packets (I believe first gen Cisco ASAs will be with us through 2018 or something like that timeframe) by default. I don't know how big either of these issues are. Presumably there should be some sort of breakage info from our DNSSEC brethren (due to larger DNSSEC generated packets). 

Mike

---

From: Hector Santos <[email-masked]>
Date: Tue, 12 May 2015 17:06:30 -0400

> You are right to point out that the RFC says that "[t]he security goals of this specification are modest", which indeed they are, but I think 100 USD is well within the means of the kind of adversa…

Hi Martijn,

Agree, but verifiers still need to support the 512 key signer, unless 
the new update is mandate new logic of "invalidate all 512 bit 
signers" or "Verifiers MUST NOT support 512" or in short, don't code 
for it.

-- 
HLS

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 May 2015 15:35:37 -0700

On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten <
[email-masked]> wrote:

> The problem here is that 512-bit keys can be trivially broken: it takes
> less than 8 hours and about 100 USD to do so[1]. So there is no way to be
> certain that the signer of the message is the same organisation that
> published the (512-bit) DKIM key, even if that organisation only were to
> send email that everyone would want to receive.
>
> You are right to point out that the RFC says that "[t]he security goals of
> this specification are modest", which indeed they are, but I think 100 USD
> is well within the means of the kind of adversary DKIM is trying to protect
> against. The story of Google's 512-bit key that Scott already pointed to[2]
> gives at least some anecdotal evidence about why this matters in practice.

Is it appropriate to change the protocol document for this?  Isn't it
really more of a BCP?

The size of the key doesn't affect interoperability, but rather the
receiver's choice to accept the signature as valid when it's based on a
weak key.

I'm not arguing that it's a bad idea to discourage this practice, but
rather ruminating about whether this is the right way to do it.

Then again, RFC6376 doesn't expressly say that keys smaller than 512 have
to be accepted either.  Hmmm.

-MSK

---

From: Scott Kitterman <[email-masked]>
Date: Tue, 12 May 2015 23:28:10 -0400

> Is it appropriate to change the protocol document for this?  Isn't it

I think when key size got put in the protocol, then it's a protocol update to 
change it.

> receiver's choice to accept the signature as valid when it's based on a

To me that's equivalent to saying choice of crypto algorithm doesn't affect 
interoperability since it only affects the receivers choice to accept the 
signature as valid.

I think that of course it's an interoperability issue.  There has to be a 
meeting of the minds on key signing and key verification in order for DKIM to 
be interoperable.

> to be accepted either.  Hmmm.

You have to set a floor below which it's not reasonable to accept signatures as 
valid.  Since receivers have no way to vet sender's key rotation policies, 
taking an out like RFC 6376 and its predecessors do and say that keys smaller 
that 1024 bits are OK for keys that aren't long lived is not tenable.  That 
and since DKIM was first deployed, at least for 512 bit keys, the not long 
lived required to meet even the modest security goals of DKIM are 
substantially shorter than the amount of time typically needed to ensure that 
mail deliveries are completed (some fraction of a day at longest).

Key lengths less than 1024 need to be killed dead.

BTW (for reference), I'm prompted to do the work to make this change by a 
recent change in opendkim [1] that removed the ability to mark messages with 
small keys as DKIM fail.  

Scott K

[1]

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Tue, 12 May 2015 21:27:51 -0700

> I think when key size got put in the protocol, then it's a protocol update

Is it part of the protocol, or is it part of the prose around the protocol?

The DKIM algorithms don't break if you use weak keys any more than they
break if you put false information in a header field.  More generally, I
don't believe DKIM itself cares about the size of the key.  All of our
advice absolutely does, and rightly so.

Do we have any other crypto-related protocols where the protocol itself
legislates the appropriate key parameters for the encoding, decoding,
signing or verifying?  Section 6 of RFC3207 (STARTTLS) explains explicitly
that it's a local matter and out of scope, for example.  I scanned
RFC4033-4035 (DNSSEC) and didn't see any restrictions or advice about key
size selection at all.  I always go cross-eyed when I try to read the TLS
RFCs so I'll stop there for now.  ;-)

> interoperability since it only affects the receivers choice to accept the

There's also nothing wrong with a receiver deciding it doesn't like
signatures that use relaxed canonicalization, SHA1, or decline to sign the
Subject header field.  The algorithm itself worked fine -- that's
interoperability -- but the receiver doesn't like one of the parameters the
signer used and thereby makes a local policy decision.

You have to set a floor below which it's not reasonable to accept
> signatures as

I don't argue with any of that, except to say again that I'm not convinced
DKIM, the protocol, has to suddenly break for small keys.  I absolutely
agree with a BCP statement of some kind, and I also agree in retrospect
that the not-long-lived key advice in RFC6376 is probably not helpful.
(You could in theory observe the timestamp of when you first saw a key and
then watch how long it gets used, but that puts an unreasonable burden on
receivers.)

Do we also want to issue a BCP more generally that tries to compel all
implementations of TLS or anything doing signatures to flatly decline to
operate if someone tries to use a sub-1024-bit key size?

> recent change in opendkim [1] that removed the ability to mark messages

The change I think you're talking about (you didn't include a reference
URL; I think it's https://sourceforge.net/p/opendkim/bugs/221/) appears to
agree with what I'm saying above.  When talking about unacceptably small
keys, the "unacceptable" decision is not made by the protocol, but by the
receiver.  DKIM didn't fail, so it shouldn't be treated as a DKIM failure.
Accordingly, OpenDKIM now reports those as failures for policy reasons
rather than failures for protocol reasons.

-MSK

---

From: Roland Turner <[email-masked]>
Date: Wed, 13 May 2015 13:25:13 +0800

On 05/13/2015 12:27 PM, Murray S. Kucherawy wrote:

> https://sourceforge.net/p/opendkim/bugs/221/) appears to agree with 
> what I'm saying above.  When talking about unacceptably small keys, 
> the "unacceptable" decision is not made by the protocol, but by the 
> receiver.

+1

- Roland

---

From: Roland Turner <[email-masked]>
Date: Wed, 13 May 2015 13:21:36 +0800

On 05/13/2015 06:35 AM, Murray S. Kucherawy wrote:

> On Tue, May 12, 2015 at 8:31 AM, Martijn Grooten 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
>
>
>     You are right to point out that the RFC says that "[t]he security
>     goals of this specification are modest", which indeed they are,
>     but I think 100 USD is well within the means of the kind of
>     adversary DKIM is trying to protect against. The story of Google's
>     512-bit key that Scott already pointed to[2] gives at least some
>     anecdotal evidence about why this matters in practice.
>
>

I suspect that there are two parallel concerns here, which may warrant 
different approaches at different levels of organisation.

The first is a concern for the freedom of action by individual 
practitioners. This includes the need for protocol specifications to 
support a range of parameter values to support different cost/benefit 
trade-offs for differently situated practitioners, different 
costs/benefit trade-offs for the same practitioners at different times 
(particularly as increasing computational power invalidates shorter 
keys) and interoperability with older systems. This generally argues for 
specifications to cover widely-used existing elements (signature 
algorithms, key lengths, ...) - particularly including weaker values - 
and a wide enough range to cater to the needs of both the most exposed 
practitioners at present, and the majority in the foreseeable future. In 
this environment, removal of mandatory algorithm and key-length support 
at the low end makes sense only as opportunistic elimination of 
no-longer-in-use (not merely no-longer-advisable) options at the time 
that a major revision is taking place, however more frequent BCP updates 
seem appropriate to support this.

The second is an ecosystem concern because of the tendency for the 
minimum stance in documented standards to become the default position 
for a majority of implementations and, therefore, to establish what it 
is that criminals have to work with. It would seem extraordinarily 
unwise for a single protocol working group to make its own choices on 
this front (think OSGP 
<http://en.wikipedia.org/wiki/Open_smart_grid_protocol#Problems>), 
rather it makes sense to perform a broader periodic review, including 
thorough review by expert cryptographers, of cryptographic algorithm and 
parameter choices for use across all protocols and applications and, 
when the output of such a review changes, to treat it as a minimum 
standard for the cryptographic elements of all subsequent specification 
updates. So far as I can tell the IETF does not do this, but various 
other standards bodies do, notably NIST. If this group thinks it's 
appropriate to eliminate weaker options for the ecosystem reason, then 
it would appear appropriate to hew to NIST's recommendations (or to 
those of a comparable body elsewhere), specifically NIST SP 800-57 
<http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57_part1_rev3_general.pdf>:

> 4.2.4.2 RSA
> The  RSA  algorithm,  as  specified  in  [ANSX9.31]  and [PKCS#1]  
> (version  1.5  and  higher)  is adopted for the computation of digital 
> signatures in [FIPS186]. [FIPS186] specifies methods for generating 
> RSA key pairs for several key sizes for [ANSX9.31] and [PKCS#1] 
> implementations. Older systems (legacy systems) used smaller key 
> sizes. While it may be appropriate to continue to verify and honor 
> signatures created using these smaller key sizes, new signatures shall 
> not be created using these key sizes.

The specified methods in FIPS186 are for 1024, 2048 and 3072 bit keys 
only. Note that a method of secret key generation is ordinarily 
considered to be outside of scope for IETF communication protocol 
specifications, which leaves us with something like the current 
situation: that signers should not use <1024 bit keys, but that (a) 
verifier implementations need to remain capable of verifying them and 
(b) the operators of verifiers need to be able to make decisions about 
whether or not to ignore 512 bit keys. This all feels like BCP territory 
too.

> 8.1.4 Special Considerations for Key Sizes
> ...
> It is recommended that DNS administrators maintain 1024-bit RSA/SHA-1 
> and/or RSA/SHA-256 ZSK’s until October 1, 2015, or until it is proven 
> that the majority of routers, caches and other network middle boxes 
> can handle packet sizes over 1500 bytes (if before 2015).

This rationale would also appear to apply here too (note that the 
specific numbers are about DNSSEC ZSKs only; the relevant bit is the 
idea that a transition is predicated upon empirical data about 
widespread adoption). Any proposal to remove the requirement for 
verifiers to be capable of verifying 512 bit keys would appear to be 
burdened with an obligation to either prove that the number of signers 
still using 512 bit keys is negligible, or make the case that the abuse 
risk was serious enough that changing the spec without achieving that 
threshold would achieve sufficient improvement to make it permissible. 
(I recall comparable discussions around some element of DMARC, I can't 
recall how low a use threshold had to be reached before a feature could 
be removed; perhaps others here do.) Someone with access to relevant 
data would need to undertake and publish the research, discussion about 
what matters would be required (e.g. perhaps measurement discovers that 
512 bit keys are only used by low-risk domains; does this warrant 
killing the feature for the good of those who are being targeted, or 
retaining it because it's still in use, with a clear understanding that 
highly-targeted organisations aren't going to use 512 bit keys to begin 
with?), it may well be necessary for measurement and publication to be 
repeated periodically, etc.

I'd offer 3 conclusions:

  * That shifting signers to MUST use >=1024 bit keys is already
    reasonable, whether immediately or at the next major update.
  * That shifting verifiers to MUST NOT verify <1024 bit keys is _*not*_
    reasonable without empirical data about 512 bit key use and
    consensus on thresholds.
  * That issuing/updating a BCP to indicate that verifiers should treat
    512 bit keys as a weak signal (e.g. to ignore them for
    high-abuse-risk domains, provide the means to selectively ignore
    them, etc.) is reasonable.

- Roland

---

From: Michael Deutschmann <[email-masked]>
Date: Tue, 12 May 2015 22:07:01 -0700 (PDT)

> validate.  I'm volunteering to write it if people agree it's appropriate.

I don't see a benefit.  Entities that simply do not use DKIM at all are
a bigger problem than those that publish weak keys.  And the fact that
weak keys are presently legal does not provide a way to impersonate a
sender who only publishes strong keys.

The only point in specifying a limit at all is that it may allow shortcuts
in implementation.  I know the crypto library embedded in Exim fails
(safely, but with an unhelpful error) if asked to sign a message with a
key that is too weak.  Since keys that weak are formally banned, it's not
really a bug.

(I noticed when attempting to re-use a YDK key I had already published.
The format of the key in DNS is backwards compatible but YDK's recommended
size was smaller than DKIM's minimum size.)

And it's all irrelevant anyway in my view.  There is currently only one
accessory protocol for DKIM, and that protocol (DMARC) is even more
useless than SPF in identifying mail to outright reject in-transaction.
And that is the only mission I care about.

---- Michael Deutschmann <[email-masked]>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 13 May 2015 07:31:39 -0400

> then watch how long it gets used, but that puts an unreasonable burden on

It's been known for years (see the original reference I provided) the 512 bit 
keys were trivially spoofable.  All open source implementations I'm aware of 
have not accepted keys < 1024 bits for several years.  The only sudden is in 
an abstract sense if one hadn't been paying any attention at all to 
operational reality regarding DKIM.  I don't view this as a functional change 
to the operational protocol as much as making the IETF paperwork match that 
reality (which I think is important).  We're already several years late 
writing this, so I don't think any alleged suddenness should be considered at 
all.

If you take out the poorly considered aspect of giving an exception to the 
existing MUSTard about short lived keys (which is never defined), 1024 bits has 
always been the limit, it's just that people often ignored it.  Rapid key 
rotation is not something that's generally done.

> operate if someone tries to use a sub-1024-bit key size?

I think the considerations for other protocols might be different.  I'd rather 
focus on DKIM for the moment.  Once you get to all, it's no longer a quick, 
easy update.

> > recent change in opendkim [1] that removed the ability to mark messages
> > with small keys as DKIM fail.
> 

That is the issue in question.  I copied the URL, but then neglected to paste.  
Thanks.  If the analysis in that issue is correct, key length can never be a 
reason to call a signature invalid.  I don't think that's correct.

So, if I publish a DKIM key of 128 bits and rotate it every minute for 
security, is that a DKIM signature?  What if it's 2 bits?  The signature isn't 
in violation of any MUST or even an a SHOULD.  Neither is verifying it.

DKIM is a security protocol.  I find it very odd to claim that the security 
part of a security protocol isn't part of the protocol.  

While I have an opinion on what I think the right answer is, what I'd really 
like is whatever is easiest to get published in the IETF that gets signatures 
based on keys less than 1024 bits marked fail by opendkim again.

Scott K

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 May 2015 07:38:26 -0400

IMO, this suggestion would be better as an Informational and BCP note. 
   I don't think it warrants a change to STD76.

We went through this already.  We (DKIM WG) were well aware of the 
weakness of a smaller key but we had backward compatibility concerns 
so the proper verification migration path was set.

I see this more as an implementation note.  In our DKIM package,  it 
was provided in the API as a functional "numbits" parameter with a 
default of 1024 but it is not settable via the sysop configuration/UI. 
IOW, 1024 is always used. No option for setting 512.  What we can do 
in the future is add the option for higher sizes and even add the 
option to "[_] Invalidate 512 signatures".

But IMV, that is Informational/BCP material.  Not a change in the 
STD76 specification.

-- 
HLS

On 5/12/2015 6:35 PM, Murray S. Kucherawy wrote:
>     The problem here is that 512-bit keys can be trivially broken: it
>     takes less than 8 hours and about 100 USD to do so[1]. So there is
>     no way to be certain that the signer of the message is the same
>     organisation that published the (512-bit) DKIM key, even if that
>     organisation only were to send email that everyone would want to
>     receive.
>
> receiver's choice to accept the signature as valid when it's based on
> a weak key.
>
> Then again, RFC6376 doesn't expressly say that keys smaller than 512
> have to be accepted either.  Hmmm.
>
> -MSK
>
>

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 May 2015 07:39:23 -0400

+1

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 May 2015 07:57:59 -0400

> part of a security protocol isn't part of the protocol.

Good point. But we did take it into account. As you point out, the 
APIs seem to have limited the size.

> based on keys less than 1024 bits marked fail by opendkim again.

IMO, that would be a SUPPORT REQUEST for a specific implementation, 
not a STD76, across the board, change request.  You can't enforce this 
on other implementators.

Keep in mind what a STD76 means -- its a standard, thats it.  The bar 
is going to be very high to make changes to it.  Just like STD11 
(RFC822) and STD10 (RFC821) are real IETF standards, a fully compliant 
SMTP package still supports them and they might have strict options to 
turn off/on 822/821 related protocol features.  Those are 
implementation concepts.

Its a good suggestion to have an an "Informational or BCP" for DKIM.

-- 
HLS

---

From: Martijn Grooten <[email-masked]>
Date: Wed, 13 May 2015 11:54:04 +0000

On Wed, May 13, 2015 at 01:21:36PM +0800, Roland Turner wrote:
> (e.g. perhaps measurement discovers that 512 bit keys are only used by
> low-risk domains; does this warrant killing the feature for the good of those
> who are being targeted, or retaining it because it's still in use, with a clear
> understanding that highly-targeted organisations aren't going to use 512 bit
> keys to begin with?)

I did some measurements this morning. In a corpus of emails sent in the
past three weeks, I found ~400 different DKIM selector-domain
combinations used to sign legitimate emails. (This is out of ~11k such
emails.)

Out of these, three used a 512-bit RSA key. A further seven used 768-bit
RSA and a handful published SPF data in their DKIM record.

None of these were highly-targeted organisations. The 512-bit keys were
used to send (opt-in) bulk emails; most 768-bit keys were used to send
one-to-one emails.

Two out of the three selectors that used 512-bit keys included a year
(2011 and 2012) which is good news (as they haven't created weak keys
recently) and bad news (as they've been using weak keys for a very long
period of time).

I don't think this is just about highly-targeted domains though, even if
the risk there is larger. An adversary could crack the DKIM key of
LocalShop Ltd. to send a fake version of their weekly mailing with the
latest offers. Make the links go to crypto-ransomware and you've earned
back your investement of cracking the RSA key very quickly.

(Note that this does make the assumption that signing emails with the
DKIM key of a domain that has a reasonably good reputation significantly
improves delivery rates. I am not sure how correct this assumption is,
but I think DKIM was designed under the implicit assumption that this
could become correct one day.)

FTR, I do agree with others that in retrospect, including explicit key
parameters in the RFC wasn't a good idea. I'm also fine to address this
issue in a BCP if that is considered more appropriate - if only because
the STD already says not to use keys smaller than 1024 bits - and I
think it's a good idea to refer to NIST to determine what key parameters
are considered secure rather than us making a somewhat informed
decision.

I don't think such a BCP should be so broad as to cover other protocols,
including TCP, which is orders of magnitude more complicated.

Martijn.

---

From: Dave Crocker <[email-masked]>
Date: Wed, 13 May 2015 11:13:18 -0700

>> the "unacceptable" decision is not made by the protocol, but by the 

(I haven't been tracking this thread in detail, so please forgive my
missing some nuance.)

I think the issue separates between 'interoperability' vs. 'usage
policy'.  The former is the protocol.  The latter is either
Internet-wide BCP or local policy, depending upon strong community
consensus.

I did a quick search for (rfc ietf minimum key size cryptograph) and
found a series of RFCs that do indeed talk about minimum key size.  All
of them are Informational, rather than standards track or BCP.

As a non-crypto-geek, the solid constant I've observed is that crypto
algorithm and key size choices are highly malleable:  they change over
time.  So a protocol needs some agility with respect to these and MUST
NOT be locked in too tightly.

DKIM is algorithm-agile.  It needs to also be key-length-agile.

If there is strong community consensus on the choices of algorithm and
key-length, it needs to be asserted as an operational convention, not in
the base protocol

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 May 2015 15:19:40 -0400

There are several ways to offer the DKIM key size expectation for 
Receiver local policies to deal with:

1) Report the bit size in Authentication-Results (Auth-Res) header.

    Authentication-Results: mail.example.com
        dkim=pass ..... bitsize=num-bits;

2) Add a DMARC tag extension "ess=" Expected Signature Strength with 
values

     ess=std76,    default, tell receivers to follow DKIM STD76.(RFC6376)
     ess=num-bits, num-bits key size is or higher is acceptable

3) Or use "ess=" as a DKIM tag extension:

   DKIM-Signature: d=signer.domain; ess=1024; ......

Any method allows for local policy filtering engines to deal with it.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Wed, 13 May 2015 15:23:13 -0400

> Any method allows for local policy filtering engines to deal with it.

The last one can be spoofed so nix #3.

-- 
HLS

---

From: Alessandro Vesely <[email-masked]>
Date: Tue, 19 May 2015 11:40:12 +0200

Apologies for jumping in late; just to note that 1024-bit keys seem to have
been accepted until quite recently:
https://www.sophos.com/en-us/support/knowledgebase/122327.aspx

On Wed 13/May/2015 13:54:04 +0200 Martijn Grooten wrote: 

> [...]

BCP 86, which DKIM refers to, makes statements such as "1024-bit RSA moduli
will not be factored until about 2037."  Should it be updated?

Ale

-- 
Small keys are fine for test suites.  And I wish 8-bit keys were functional,
for illustrative and educational purposes.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Martijn Grooten <[email-masked]>
Date: Tue, 19 May 2015 11:08:22 +0000

> https://www.sophos.com/en-us/support/knowledgebase/122327.aspx

This refers to certificates signed with RSA-1024 keys, which are being
phased out. See e.g.

  https://blog.mozilla.org/security/2014/09/08/phasing-out-certificates-with-1024-bit-rsa-keys/

It's good to note that when using SSL/TLS your reasons to be paranoid
are orders of magnitude larger than when using DKIM. The fact that some
people believe that cracking RSA-1024 in the not too distant future may
be feasible is considered enough reason to ditch certificates using
them.

> will not be factored until about 2037."  Should it be updated?

It doesn't exactly make that as a statement; rather it quotes R D
Silverman who made some educated guesses around the turn of the
century. It doesn't make any explicit statements about what key sizes
are safe for which algorithms, nor does the BCP aim to do so. 

I don't think it needs updating; at least not because of the bit you
quote.

(Actually, the BCP isn't all that relevant for DKIM, but probably the
best BCP on key sizes out there.)

Martijn.