[DNSOP] SHA-1 chosen prefix collisions and DNSSEC

[Tony Finch]

I have written a blog post with my understanding of the implications of the 
SHAmbles attack for DNSSEC.

https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html

Conclusions from the article:

Whenever a DNS zone is signed with a SHA-1 DNSKEY algorithm it is vulnerable to 
chosen prefix collision attacks. This is a problem when a zone accepts updates 
from multiple parties, such as:

TLDs
enterprises
hosting providers
It is also a problem when a key is re-used by multiple zones.

Zones using algorithm numbers 7 or less should be upgraded. The recommended 
algorithms are 13 (ECDSAP256SHA256) or 8 (RSASHA256, with 2048 bit keys).

For extra protection against chosen prefix collision attacks, zones should not 
share keys, and they should have separate ZSKs and KSKs.

DNSSEC zone signing software should provide extra protection against chosen 
prefix collisions by adding more randomness to the inception and expiration 
times in RRSIG records.

Software implementing CDNSKEY and CDS checks must ensure that the records are 
properly signed by a KSK, not just a ZSK.

Top-level domain registry software must not accept over-sized DS records.


Tony.
-- 
f.anthony.n.finchhttp://dotat.at___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS stamps

[Vladimír Čunát]

On 1/9/20 6:37 PM, Ted Lemon wrote:
> On Jan 9, 2020, at 9:21 AM, Vladimír Čunát  > wrote:
>> Depends what you'd want from the stamps.
> If the stamps make assertions about what service is offered, I’d want
> that to be verifiable.  [...]

I'd personally have stamps without these assertions (or without giving
them any weight).

I see a bigger problem that some of desired assertions are in principle
unverifiable, e.g. "no logging".  Of course, we could (optionally)
extend the string by a signature, but I suspect that'd increase the
length a lot without sufficient gain in exchange.


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS stamps

[Ted Lemon]

On Jan 9, 2020, at 9:21 AM, Vladimír Čunát  wrote:
> Depends what you'd want from the stamps.

If the stamps make assertions about what service is offered, I’d want that to 
be verifiable.  Otherwise, I can send you a stamp that makes promises I don’t 
intend to keep, and there’s no signature on it, so you have no reason to 
complain when I don’t do what I said I would.   So what’s the point, in that 
case, of making promises?   It’s like the “please respect my privacy” browser 
bit.   Useless.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS stamps

[Vladimír Čunát]

These stamps do contain interesting ideas, I believe.

On 1/9/20 5:13 PM, Ted Lemon wrote:
> In order for this to actually be useful, two things would be required.
>
> 1. The assertions about resolver behavior (e.g., logging, etc) would
> have to be signed
> [...]

Depends what you'd want from the stamps.  If the main point is to
configure by an URI that's easy to copy, I don't think you really
need these details.  I imagine you'd copy it from an https site of the
operator or got through another trusted (chain of) means.  And I'd
certainly not expect binding such format to some legal mechanisms,
etc... perhaps you could just add policy and some "small print" legalese
to that site as well.

Someone would need to "author" it here.  I don't expect DNSCrypt people
to push it forward within IETF.  I'm not sure what would happen if WG
decides to change the format in an incompatible way, but perhaps that
could be avoided.

BTW, do we want to keep this (whole) thread in *both* mailing-lists at once?

--Vladimir

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] DNS stamps

[Ted Lemon]

On Jan 9, 2020, at 6:35 AM, Stephane Bortzmeyer  wrote:
> Could be useful specially for secure and public resolvers, may be
> worth of some IETF work?

In order for this to actually be useful, two things would be required.

1. The assertions about resolver behavior (e.g., logging, etc) would have to be 
signed
2. The signature would have to be validatable back to a specific entity that is 
legally competent to make promises
3. There would have to be some legal mechanism, whether actual law or 
precedent, saying that these assertions, when made by competent legal entities, 
constitute a contract.
4. It would have to be possible to automatically determine based on some trust 
model that a particular identity corresponded to an entity that qualified under 
(2)
5. Someone(s) would have to operate (4)

So basically this document does just the easy part, and none of the hard part.  
 And the bulk of the hard part is probably out of scope for the IETF, although 
a model like ACME could work.

I’m not arguing for or against doing this, but let’s be clear about how much 
work it is and what kind of work it is! :)

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

[DNSOP] DNS stamps

[Stephane Bortzmeyer]

Could be useful specially for secure and public resolvers, may be
worth of some IETF work?

https://github.com/DNSCrypt/dnscrypt-proxy/wiki/stamps

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop