Hacker News Reader

Comment by sva_ | Hacker News Reader

First sentence:

> In our study on the SPF, DKIM, and DMARC records of the top 1M websites, we were surprised to uncover more than 1,700 public DKIM keys that were shorter than 1,024 bits in length

View on HN

I must do something about my short-term memory/attention. I must have read that and promptly blanked it during the scanning of the rest of the article.

The interesting question is: Did these sites forget that they have these records, or have they perhaps forgot how to rotate their keys.

dns server limitations.

txt records are 1024bits... add the prefix for the key and you get <1024.

to use a larger key you must combine many txt records in a never ending comical interoperability issues. the first one usually being that your regional monopoly scoundrel, a.k.a. registrar, run a server which doesn't even allow more than one entry.

TXT records are 255 bytes or 2040 bits. This is plenty of space to support RSA-1024 keys even with a small prefix and after base64 encoding them. However, it is obviously not enough to support RSA-2048 which is the minimum recommended size according to NIST right now. It's also not quite enough even for RSA-1536 (not widely used) due to base64 expanding the key by 33%.

There actually is a standard for adding more than 255 bytes to a TXT record and it's fairly widely supported, but it can be tricky to configure properly on a name server.

> but it can be tricky to configure properly on a name server.

I wouldn't say it is tricky with a good name server: for instance with bind just split the value into multiple quoted strings and it'll do the rest¹.

Though while it is well known, it doesn't seem to be well documented away from many forum posts discussing the matter: after a little searching I can't find reference to the issue in bind documentation or relevant RFCs. The RR format allows RDATA to be longer than 255 octets (RDLENGTH is an unsigned 16-bit value, not 8-bit) so presumably the limit is imposed by the zonefile format. The only reference to 255 octet limits in RFCs 1034 & 1035 is the length of a full name (with individual labels making up a name being limited to 63 octets).

Of course many UIs for editing zone files or other stored RR information, or other DNS management interfaces, might implement longer RDATA support in a worse way or not support longer RDATA values at all.

----

[1] I'm not sure what “the rest” is (I might look deeper later)

You're only halfway there. Also from RFC 1035:

  TXT-DATA        One or more <character-string>s.

Looking up what a character-string is:

  .... <character-string> is a single
  length octet followed by that number of characters.  <character-string>
  is treated as binary information, and can be up to 256 characters in
  length (including the length octet).

So the 255-byte limit for each string within the TXT record is a core part of DNS. But so is having more than one such string in the record data (which I thought was a later extension). I have no idea why this strange format was chosen when, as you noted already, the RDATA is already sized by the RDLENGTH, which is 16 bits. However, it is not a mere artifact of the zonefile format; indeed the format follows from the spec.

I'm not sure that all clients and servers out there handle more than one string in the record properly, though in my experience, most do. Still, having to split the values, and being able to split them before exactly 255 bytes, makes it trickier than it needed to be to administer and validate such configurations manually.

yeah my point is that most dns servers used outside the major markets do not support any of this double key stuff.

if you want TLD not available at your us registrar, you're stuck with low dkim keys. period. doesn't matter what specs says.

dunno if that's just a consequence of the monopoly design of the dns business, or more nefarious reasons, but that's the situation on most TLD not easily registered such as .br

Ok, using your registrar to serve your DNS records for you is a choice on your part, and if so, then yes you would be subject to their limitations. But the vast majority of registrars, and this includes registro.br as far as I can tell according to a machine translation from Portuguese to English [1], allow you to delegate a domain to your own nameservers, and this is the standard way to use a registrar. You pay a registrar to lease a domain, not to host it. Once they have delegated to your nameservers via NS records, you can serve whatever other records you want (subject to the registrar's legal policies). Now, maybe a lot of client software commonly used in Brazil does not support multi-string TXT records, and that would still be an issue, but it's not on the server side.

[1]: In the 5th bullet under section 1.2 of https://registro.br/ajuda/tutoriais-administrativos/ it says (roughly) "In DNS (OPTIONAL), you can inform the DNS servers previously configured for your domain. If you do not have this information, ignore this field. Our system will automatically use the DNS servers made available free of charge by Registro.br."

I guess most of these keys are decades old and no longer in use. They're likely just sitting in the DNS because someone forgot to delete them. Now, no one's sure if they're still needed and is afraid to remove them in case it breaks something. Or maybe they're still used by a legacy system, and no one realizes the impact an old DKIM record could have.

So 1,700 out of 1,000,000, i.e. around 0.2%. "Not common" is one way of putting it, I guess.

Those 1,700 are easy to find though, just need to dig a bunch of domain names and you'll find plenty vulnerable ones that you can spoof.

Yahoo Mail has a market share on the order of 3%. So a black hat could then target a decent chunk of users with @yahoo addresses specifically.

Has anyone heard of this being exploited in the wild? Would be interesting to find out whether there are some reputable domains among the 1.7k vulnerable ones.

Your claim that yahoo uses a 512bit key are counterfactual.

Please adhere to honesty and good faith arguments.

I never suggested that Yahoo uses 512bit keys, that's a misunderstanding.

The article clearly states that Yahoo is one of the 3 clients that didn't reject 512bit keys the way they should per RFC.

Yahoo Mail inbox users are vulnerable _receivers_ of spoofed emails.

remember when yahoo mail was the first one to implement DKIM validation and then all mailing list owners added a footer telling their subscribers not to use yahoo mail because it was broken, instead of calling their mailing list providers to upload a key? yeah nobody remembers, but yahoo probably do. i doubt they will err on the side of security again.

The Yahoo that built Yahoo Mail no longer exists, so actually they probably don't remember.

I agree, but to be precise, it was 1,726 out of 476,617 DKIM keys found across those 1M domains, or about 0.36%. Since it's impossible to determine all DKIM records a domain might have from the outside, I used a list of commonly used selectors (e.g., "default' or 'key1") for the search. It's likely there are additional short keys under selectors I didn't check.

The top million domains are more likely to be on top of their security than less prominent domains. 0.2% is therefore a fairly strict lower bound for the overall internet.

Reply on news.ycombinator.com