Re: [DNSOP] Simplified Updates of DNS Security Trust Anchors, for rolling the root key

[Warren Kumari <[e-mail]>]

On Tue, Jun 30, 2015 at 9:34 AM, John Dickinson <[e-mail]> wrote:
>
>
> On 29/06/2015 21:48, Warren Kumari wrote:
>>
>> I'd appreciate any feedback, the draft announcment is here:
>> Name:           draft-wkumari-dnsop-trust-management
>> Revision:       00
>> Title:          Simplified Updates of DNS Security (DNSSEC) Trust Anchors
>> Document date:  2015-06-29
>> Group:          Individual Submission
>> Pages:          8
>> URL:
>>
>> https://www.ietf.org/internet-drafts/draft-wkumari-dnsop-trust-management-00.txt
>> Status:
>> https://datatracker.ietf.org/doc/draft-wkumari-dnsop-trust-management/
>> Htmlized:
>> https://tools.ietf.org/html/draft-wkumari-dnsop-trust-management-00
>>
> Hi,
>
> This draft appears to be trying to solve several problems.
> 1. Signalling by a validator to an authoritative server which keys it knows
> about.
> 2. Signalling by an authoritative server the mechanism it is using to roll
> it's keys
> 3. Defining an alternative to 5011 with a different mechanism to roll keys.


I think it is more just:
1: Signalling by a validator to an authoritative server which keys it
knows about.
3: Defining an alternative to 5011 with a different mechanism to roll keys.

An auth server *can* include a TDS record to signal that it supports
TDS (your #2), but it doesn't have to stop doing 5011. If it doesn't
publish the record, it still gets the signalling information.

This mechanism works with 5011 if that is what the auth server want to use.
An auth can:
A: use 5011 AND NOT publish a TDS record -- everyone will use the 5011
logic. The auth servers will still get the queries for the TDS record
from new clients, and so will be able to see the population change
(from new clients).

B: use 5011 AND publish a TDS record -- new clients will do the TDS
processing, older clients will still follow 5011 logic. The auth
server will still be able to follow the population change (from new
clients) (I need to add a priority section explaining what to do if
you support both TDS and 5011)

C: only use TDS - new clients will do TDS processing, old ones will
simply die when the roll happens. The TA maintainer will at least know
who all will die - those folk who talk to the root, but don't ever
send a TDS query. This is, um, not recommended :-)

>
> This seems a big ask for one draft.
>
> I have been planning to write a draft to address 1 by having validators send
> the DS of known TA's in an edns0 option code. This info, could then be
> logged by the authoritative nameservers.

Inserting it in edns0 implies (I think) that all of the queries will
contain this, which seems like a fairly big query size / efficiency
hit. I guess you could just do it every N queries, or M time, or
something. Very similar idea though...

I could simply pull all of the "and then install the new TA" stuff out
of the draft, and this could just be signaling of what TAs are
deployed.
I suspect that simply including a signalling mechanism that announces
what you know, without tying it to getting something in return, will
not get as widely deployed -- where is my incentive to send this? "To
be a good citizen" doesn't work as well as it used to / should :-( The
implicit suggestion that TDS may end up being the preferred mechanism,
and removal of the need to double-sign provides an incentive to do
this -- "I'll show you mine if you show me yours..."

>
> For problem 2 I was going to suggest advice to implementers of validators to
> (by default) treat all TA's as potentially 5011. A non 5011 TA is just one
> that is never seen to do 5011 stuff.

RFC 5011 requires significantly increasing the response sizes / double
signing. It is unclear if this really is a problem or not, but some
folk believe it is...

>
> Given the above, My feeling is that there is no need to propose an
> alternative to 5011 unless it adds a significant increase in security/ease
> of use.
>

I think it *does* provide a significant ease of use / operational win
over RFC5011-- it provides an incentive to report your TA set (you
need to, to get the next TAs), and also doesn't require increasing the
response size. It is unclear if this is a good enough tradeoff. It
might not be. Decoupling the signalling from the roll, and not
providing a 5011 alternative is, um, an alternative :-)

> In addition, if I have understood your intent correctly, I have a few
> questions regarding the security of your proposed mechanism.
>
> Assuming the traditional large (strong) KSK used as trust anchor and smaller
> ZSK scenario.
> It appears that the TDS RRSet will be signed only by the smaller ZSK.
> Doesn't this effectively create a circular dependency that effectively
> reduces the security of the zone down to the strength of the ZSK?
>

Hmmm. Good point. This may be a major issue... You could require that
the TDS records be signed by the KSK (like the ZSK), but this feels
like it may be hackish...

> You mention nothing like the add hold down timer in 5011. There seems to be
> good justification its need in 5011.

Yup, you are right. I had initially stuffed some text in the draft
saying that you simply follow all of the RFC5011 key timing logic /
parameters, but this didn't really seem to fit very well for some
cases. Rather than rewrite all of the 5011 timing stuff I decided to
publish this and get initial feedback. The draft still needs
significant work  before it would be finished, the full timing, much
better examples, the IANA section, the security section, priority of
5011 vs TDS, etc are included in that...


Anyway, thank you for reading and providing feedback, hopefully we can
make this better and / or remove the roll part and / or decide it is
not worth pursuing....


W

>
> regards
> John
>
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf