Subject: [ietf-dkim] need for clarification

From: "A. Schulze" <[email-masked]>
Date: Tue, 27 Jan 2015 17:43:42 +0100

Hello everybody,

Murray encourage me to ask here:

https://tools.ietf.org/html/rfc6376#section-3.3.3 say
  "Signers MUST use RSA keys of at least 1024 bits for long-lived keys."

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

Signer using a key larger then 2048 (like I do for years now) aren't  
inside the specification
because there is no MUST on the validation side.
 From operational perspective I experience no drawback using 4k RSA  
keys for DKIM.

I see these options:
  - the signer could use smaller keys and rotate them more often
  - the specification support other key types which gather same level  
of security with smaller keys
    ( elliptic curve crypto )
  - the specification REQUIRE validators to handle larger keys.

I would kindly ask for other options or advise.

Thanks,
Andreas

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 Jan 2015 10:16:35 -0800

> From operational perspective I experience no drawback using 4k RSA  

How do you know? A sender of email doesn't know whether the
mail they're sending has a signature that validates for all recipients.

> I would kindly ask for other options or advise.

RSA said that 2048 bit RSA keys are likely secure until 2030, NIST say
that they're acceptable for cryptographic signature generation.

Given that they're considered strong enough for real crypto problems,
they're definitely strong enough for the low-security, short time frame
task of providing some level of authentication about an email to a 
spam filter.

So there's no reason to use anything bigger than 2048 bits for DKIM,
I don't believe. I'd be far more concerned about other attacks on the
system, or even on the RSA algorithm, than I would be about people
brute-forcing 2048 bit keys this decade.

What advantage do you see to using larger keys?

Keys larger than 2048 bits could cause operational problems - as well
as being outside spec, they're going to be more expensive to handle
in software, too big to handle on some hardware (does anyone do that,
I wonder?) and they're going to make keys bigger, which might cause
problems with older DNS infrastructure.

How big is your DNS TXT record?

Cheers,
  Steve

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 27 Jan 2015 20:00:02 +0100

John R. Levine:

> The most likely issue would be that the TXT records don't fit in a  
> 512 byte response packet which is a problem for some cruddy  
> middleboxes.

that was exactly the reason I started using 4k keys. I wanted to make sure
at least my infrastructure could handle DNS over TCP everywhere.

> Could you explain what problem you believe needs 4K rather than 2K  
> keys? DKIM is not PGP or S/MIME and is not intended for long term  
> protection of confidential data.  It's just a short term assurance  
> that a particular message in transit was signed by a particular  
> signer.
correct.

> I rotate my keys every month, which appears to be the shortest DKIM  
> rotation time in the world.  Most people do it every six months or a  
> year.
I agree, too.
In practice it's a trade off between keysize and key age...

Do you think, the DKIM specification should be more detailed on this  
pros and cons?

Andreas

---

From: "John R. Levine" <[email-masked]>
Date: 27 Jan 2015 14:14:43 -0500

>> The most likely issue would be that the TXT records don't fit in a 512 byte 
>> response packet which is a problem for some cruddy middleboxes.
>

That's nice, but I don't see what that has to do with interoperating with 
the rest of the world whose DNS does what it does.

> Do you think, the DKIM specification should be more detailed on this pros and 
> cons?

No, the advice to use 2K keys will be reasonable for the forseeable 
future even for very infrequent rotation.

R's,
John

---

From: "A. Schulze" <[email-masked]>
Date: Tue, 27 Jan 2015 20:24:08 +0100

Steve Atkins:

> How do you know?

Not for sure. There was a feature to request reports in opendkim. Some people
used that and I got mostly no unexpected reports. Today DMARC reports  
are a good source too.
I have some smaller "send only" domains. The DMARC reports also show  
mostly positive results.

> brute-forcing 2048 bit keys this decade.
That's the point. The RFC don't make that clear enough.
It leave one side open.

> How big is your DNS TXT record?
# dig J4bWGJQcBmxMQ._domainkey.andreasschulze.de. txt
;; Truncated, retrying in TCP mode.
...
;; MSG SIZE  rcvd: 851

Andreas

---

From: "John R. Levine" <[email-masked]>
Date: 27 Jan 2015 13:44:01 -0500

> inside the specification because there is no MUST on the validation 
> side.

> From operational perspective I experience no drawback using 4k RSA

I'm not surprised that 4K keys work.  Most crypto software can handle 
abitrary key sizes.  The most likely issue would be that the TXT records 
don't fit in a 512 byte response packet which is a problem for some cruddy 
middleboxes.

Could you explain what problem you believe needs 4K rather than 2K keys? 
DKIM is not PGP or S/MIME and is not intended for long term protection of 
confidential data.  It's just a short term assurance that a particular 
message in transit was signed by a particular signer.

I rotate my keys every month, which appears to be the shortest DKIM 
rotation time in the world.  Most people do it every six months or a year.

R's,
John

---

From: Steve Atkins <[email-masked]>
Date: Tue, 27 Jan 2015 11:53:13 -0800

> I have some smaller "send only" domains. The DMARC reports also show  

That's a self-selecting group of recipients who choose to run bleeding edge
protocols and software, and to configure them in a non-vanilla way. The
overlap between that group and the group who aren't seeing your email
because they're using older resolvers is probably zero.

So that's not evidence that you're not experiencing operational problems,
just that the way you're looking for them means you can't see them.

> ;; Truncated, retrying in TCP mode.

DNS responses that exceed UDP size are considered a very bad thing,
and will cause queries for that record to fail in many places. Given the demographics
of people making that query it's not as big a problem as it would be for end user
visible records, but it's still going to be a problem. And in the places
where it does work it's consuming a much, much more expensive pool
of resources than correctly configured DNS records do.

Cheers,
  Steve

---

From: "Mark Delany" <[email-masked]>
Date: 27 Jan 2015 19:12:04 +0000

> I would kindly ask for other options or advise.

On the matter of smallish keys, it was originally stressed that
validation should only occur at the time of delivery rather than many
years later, so the notion of smaller keys being vulnerable to future
technology is less of a risk. So from the perspective, shorter keys
are not as terrible. But others will disagree.

On the matter of EC and larger keys, both of those are valid
suggestions in 2015, however not so much in 2004 when many of these
original decisions were made. At that time:

o there was limited support for EDNS0 - even today it's not 100%

o (as I recall) openssl exhibited erratic behavior with 2048 < keys <
  4096. This made me pretty nervous about the true level of support
  for large keys in general.

o EC was nascent in 2004 - I don't recall whether there was much if
  any s/w that supported it.

I don't recall how much re-evaluation of those limits was done in
later incarnations of the specs. EC at least is probably worth as it
reduces DNS payload sizes.

Of course introducing larger keys and/or a new algorithm is within the
protocol but will be quite a challenge due to the installed base.

I also note that we original had the notion of the verifier having to
choose the signature with the "most secure signing algorithm", so in
theory you could create signatures with RSA and EC, but that notion
was lost/dropped in later iterations of the specs. Perhaps it should
be revivified?

Mark.

---

From: Franck Martin <[email-masked]>
Date: Tue, 27 Jan 2015 20:08:31 +0000

> of resources than correctly configured DNS records do.

With EDNS you can go up to 4k UDP packet size, tho fragmentation is an issue. DNS with UDP packets <1200 pass most broken firewalls.

With DNSSEC, you see more and more big UDP DNS requests. DNSSEC resolution is deployed enough. Just don’t put a TTL of 5mn on these entries…

I don’t think a DNS answer of 851 bytes is a serious issue today (especially for DKIM).

I think an addendum to DKIM, to allow more flexibility in key size could be useful. The times it takes to reach standard, about 3 years (then deployment another 2-3 years), we need to prep the work long before we need it.

It is like quantum computing, the time to create a new encryption is longer than the projected availability of a quantum computer that will crack all current encryptions within minutes.