Unbound 1.21.1 released

[Yorgos Thessalonikefs]

Hi Petr,

On 07/10/2024 23:26, Petr Menšík wrote:
> It would be nice, if there were a list of PGP keys, which are considered 
> okay for unbound signatures. In Fedora we try to verify package 
> signatures as part of package build process [1]. But it expects all keys 
> considered okay to sign in code to be in single file. Ideally somewhere 
> at your web servers to download and protected by HTTPS.
> 
> I have failed to find such file anywhere on nlnetlabs download close to 
> release. keys [2] at downloads lists some keys, but not something like 
> who is relevant in which project, where code signinig might occur.
With the upcoming plans to have a dedicated key for signing released 
code, the key will have a more prominent appearance on the website, same 
way as the security key has now.

> 
> By the way, have you considered publishing keys also as an OPENPGP 
> record? As an organization closely related to DNS and with a signed 
> zone, it might be useful. gnupg has some support for it as --auto-key- 
> locate dane. Published as experimental RFC 7929 [3].
Good suggestion. Not sure about the discover-ability of those since it 
is experimental and mainly for email but another thing to consider.
I'll bring it up with the team when the time comes.

Best regards,
-- Yorgos
> 
> Regards,
> Petr
> 
> 1. https://src.fedoraproject.org/rpms/unbound/blob/rawhide/f/ 
> unbound.spec#_58
> 2. https://nlnetlabs.nl/downloads/keys/
> 3. https://datatracker.ietf.org/doc/html/rfc7929
> 
> On 04/10/2024 09:39, Yorgos Thessalonikefs wrote:
>> Hi Petr,
>>
>> The canonical place for our keys is https://nlnetlabs.nl/people/.
>> Wouter has a link to that key server, I have the key on the webserver.
>>
>> I went ahead and uploaded my key also to https://keys.openpgp.org.
>>
>> This release was exceptional because Wouter is unavailable at this time.
>>
>> In the future we are thinking of having a dedicated key for signing 
>> releases, but this is something that will be properly communicated 
>> when time comes.
>>
>> I may do more releases in the future with the Yorgos key, if you want 
>> to store that.
>>
>> Best regards,
>> -- Yorgos
>>
>>
>> On 03/10/2024 21:26, Petr Menšík wrote:
>>> Hi!
>>>
>>> I have tried to update to this key. When searched for it on the same 
>>> source as Wouter Wijngaards has link, it has found expired key only.
>>>
>>> Perhaps could the GPG key be refreshed also on link
>>>
>>> https://keys.openpgp.org/pks/lookup? 
>>> op=get&search=948EB42322C5D00B79340F5DCFF3344D9087A490
>>>
>>> ?
>>>
>>> It would be better, if the older Wouter's key signed 948E B423 22C5 
>>> D00B 7934  0F5D CFF3 344D 9087 A490 key.
>>>
>>> Would be all releases from now signed by this Yorgos key or is this 
>>> exceptional case?
>>>
>>> Regards,
>>> Petr
>>>
>>> On 03. 10. 24 18:00, Yorgos Thessalonikefs via Unbound-users wrote:
>>>> Hi,
>>>>
>>>> Unbound 1.21.1 is available:
>>>> https://nlnetlabs.nl/downloads/unbound/unbound-1.21.1.tar.gz
>>>> sha256 3036d23c23622b36d3c87e943117bdec1ac8f819636eb978d806416b0fa9ea46
>>>> pgp https://nlnetlabs.nl/downloads/unbound/unbound-1.21.1.tar.gz.asc
>>>>
>>>> ** This release is signed by yorgos at nlnetlabs.nl. Please find the 
>>>> relevant key at https://nlnetlabs.nl/people/ **
>>>>
>>>> This security release fixes CVE-2024-8508.
>>>>
>>>> A vulnerability has been discovered in Unbound when handling replies
>>>> with very large RRsets that Unbound needs to perform name compression
>>>> for.
>>>>
>>>> Malicious upstreams responses with very large RRsets can cause Unbound
>>>> to spend a considerable time applying name compression to downstream
>>>> replies. This can lead to degraded performance and eventually denial of
>>>> service in well orchestrated attacks.
>>>>
>>>> The vulnerability can be exploited by a malicious actor querying 
>>>> Unbound
>>>> for the specially crafted contents of a malicious zone with very large
>>>> RRsets.
>>>> Before Unbound replies to the query it will try to apply name
>>>> compression which was an unbounded operation that could lock the CPU
>>>> until the whole packet was complete.
>>>>
>>>> Unbound version 1.21.1 introduces a hard limit on the number of name
>>>> compression calculations it is willing to do per packet.
>>>> Packets that need more compression will result in semi-compressed
>>>> packets or truncated packets, even on TCP for huge messages, to avoid
>>>> locking the CPU for long.
>>>>
>>>> This change should not affect normal DNS traffic.
>>>>
>>>> We would like to thank Toshifumi Sakaguchi for discovering and
>>>> responsibly disclosing the vulnerability.
>>>>
>>>>
>>>> Bug Fixes:
>>>> - Fix CVE-2024-8508, unbounded name compression could lead to denial of
>>>>   service.
>>>>
>>>> Best regards,
>>>> -- Yorgos
>>>>
>>