5 ms·

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 w

by sva_ 2y ago

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

unwind 2y ago
So 1,700 out of 1,000,000, i.e. around 0.2%. "Not common" is one way of putting it, I guess.
- croemer 2y ago
  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.
  - elif 2y ago
    Your claim that yahoo uses a 512bit key are counterfactual. Please adhere to honesty and good faith arguments.
    - croemer 2y ago
      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.
      - 1oooqooq 2y ago
        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.
        jaza 2y ago
        The Yahoo that built Yahoo Mail no longer exists, so actually they probably don't remember.
- awulf 2y ago
  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.
- philipwhiuk 2y ago
  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.
mrweasel 2y ago
The interesting question is: Did these sites forget that they have these records, or have they perhaps forgot how to rotate their keys.
- 1oooqooq 2y ago
  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.
  - kbolino 2y ago
    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.
    - dspillett 2y ago
      > 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)
dspillett 2y ago
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.

by sva_ 2y ago

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

unwind 2y ago

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

croemer 2y ago
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.
- elif 2y ago
  Your claim that yahoo uses a 512bit key are counterfactual. Please adhere to honesty and good faith arguments.
  - croemer 2y ago
    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.
    - 1oooqooq 2y ago
      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.
      - jaza 2y ago
        The Yahoo that built Yahoo Mail no longer exists, so actually they probably don't remember.
awulf 2y ago
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.
philipwhiuk 2y ago
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.

mrweasel 2y ago

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

1oooqooq 2y ago
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.
- kbolino 2y ago
  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.
  - dspillett 2y ago
    > 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)

dspillett 2y ago

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.