6:19 p.m.
Hi,
In an off-list conversation, it's been decided that logging of _removal_
of DS RRs would be useful. If those understanding why this should be
done could explain what attack(s) this will detect, that'd be great.
The next question is how this should be done in practice, in our current
experiment. IIRC we decided in Yokohama that Paul would hack up an
unbound to submit DS records it stumbled over, together with a chain of
keys and signatures up to a trust anchor that the log had configured.
I'm going to show my ignorance and ask how this would be detected and
expressed while pointing out that "duh, NSEC*" is _not_ enough for me to
understand. :) I do accept terse descriptions and pointers to relevant
litterature though!
Thanks,
Linus
6:37 p.m.
Hello list.
On 1.2.2016 18:19, Linus Nordberg wrote:
In an off-list conversation, it's been decided
that logging of _removal_
of DS RRs would be useful. If those understanding why this should be
done could explain what attack(s) this will detect, that'd be great.
I think that this is not only useful but essential. An evil parent zone
can decide to forge an arbitrary record in it's child zone. To make it
possible, the parent can (1) change the trust path or (2) remove the DS
record rendering the child zone insecure.
In the first case, the attempt will be hopefully logged by the CT.
In the second case, the attempt will go unnoticed to CT. And current
client applications don't indicate whether the zone is DNSSEC-secure or not.
The next question is how this should be done in
practice, in our current
experiment. IIRC we decided in Yokohama that Paul would hack up an
unbound to submit DS records it stumbled over, together with a chain of
keys and signatures up to a trust anchor that the log had configured.
I'm going to show my ignorance and ask how this would be detected and
expressed while pointing out that "duh, NSEC*" is _not_ enough for me to
understand. :) I do accept terse descriptions and pointers to relevant
litterature though!
This is the easiest way to start.
Jan
2:48 p.m.
Jan Včelak <jan.vcelak at nic.cz> wrote
Wed, 3 Feb 2016 18:37:22 +0100:
| > The next question is how this should be done in practice, in our current
| > experiment. IIRC we decided in Yokohama that Paul would hack up an
| > unbound to submit DS records it stumbled over, together with a chain of
| > keys and signatures up to a trust anchor that the log had configured.
| > I'm going to show my ignorance and ask how this would be detected and
| > expressed while pointing out that "duh, NSEC*" is _not_ enough for me to
| > understand. :) I do accept terse descriptions and pointers to relevant
| > litterature though!
|
| This is the easiest way to start.
How is this done in practice?
3020
days inactive
3023
days old
dnssec-transparency@lists.sunet.se
2 comments
2 participants
participants (2)
-
jan.vcelak＠nic.cz -
linus＠nordu.net