Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-01.txt

[Michael StJohns <[e-mail]>]

I did a quick review - it's improving, but still is getting the basics 
wrong.

This document is written with language that works only with the start 
with one key/one key in/one key out/end with one key model for trust 
anchor keys.  5011 specifically recommends that there be at least two 
trust anchor keys and this document doesn't quite get the problem 
statement right given that both 5011 and DNSSEC support a steady state 
of more than one trust anchor key.

The actual issues related to the problem stated (of publisher guidance) 
are "How long must a publisher wait after publishing a new key before 
revoking ALL previous trust anchors?" And  "How long to wait before 
signing ONLY with the newest key?"  (These are actually the same 
question looked at from slightly different angles). The issue is not the 
more limited generic question of how long to wait before you start 
signing with the new key.  (Please avoid the phrasing "use the key" 
throughout).

For example, consider a trust point with trust anchor keys A, B and 
where A is generally signing the DNSKEY RR Set at the trust point.  The 
publisher desires to replace A with a new key C.   The publisher 
generates C, signs the RRSet with B and publishes the RRSet containing B 
and C.   At time T+holddown, C has probably joined the first of many 
validator trust point sets.  At some time T+holddown+N, most of the live 
validators will have added C.   At this point the publisher revokes A, 
publishes a trust set with A, B, C and signed with A and B and continues 
this for at least the hold down time.  At which point the published 
RRSet is now B, C signed by B (C is a standby key) and most validators 
trust points have B,C installed in them.  (Or B signed by B for that 
matter - "Missing" is an abnormal state, not an illegal one and was 
there mainly because  RRSet size issues  mostly weren't brought up while 
5011 was being discussed).

Note that A could have been revoked starting with the first publication 
of C  at the cost of reducing the validator trust anchor set to a single 
key.  That would be the model for an emergency revocation of A.

So:  Minimum time to start signing with the new key is the hold down 
time (you can sign earlier, but no validator will trace trust through it 
so why bother?).
Minimum time to wait before revoking all previous trust anchors OR 
signing the RRSet ONLY with the new key is hold down time counted from 
expiration date of the signature over previous DNSKey RRSET plus some 
slop - in the example the slop is 7 days and that's a reasonable value 
for the parameters.   That's also the minimum time a new key should be 
published and signed even if you're planning on using it as a backup key 
and not including it in further RRSets for now.

Note that the example in the draft at section 6 is missing a 
consideration.  It's not the expiration time, but the expiration date 
that needs to be considered - if you issue a new RRSet while the 
signature on the old one has only 4 days to go, you have the 4 day 
exposure, not 10.


Mike







On 5/24/2017 1:40 AM, [e-mail] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Domain Name System Operations of the IETF.
>
>          Title           : Security Considerations for RFC5011 Publishers
>          Authors         : Wes Hardaker
>                            Warren Kumari
> 	Filename        : draft-ietf-dnsop-rfc5011-security-considerations-01.txt
> 	Pages           : 12
> 	Date            : 2017-05-23
>