[dnssec-deployment] Answers to questions asked at the DNSSEC meeting

[Mike StJohns]

At 07:04 PM 5/24/2004, Paul Vixie wrote:
>dynamic SEP management is a lot to ask of every 3G device and 802.11 PDA
>and 802.11 VoIP portable to execute, either on a scheduled basis, or when
>they see a REVOKE bit, or whatever.  a lot of these devices will remain
>powered off, or off-network, for weeks or months at a time.  when they are
>actually online, it's possible that their owners will want to use their
>bandwidth for non-DNSSEC-key-maintainance activities.  on an endstation
>by endstation basis, i'm not sure we can implicitly demand this level of
>sophistication.  it's a lot more likely that endstations will get their
>SEPs from their DHCP server than as a side effect of executing DNSSEC.
>
>(i'm keeping in mind the reasons why the community rejected A6/bitstring.)

I think you're exactly correct for the dynamic end devices that do 
this.  (And we need to add a work item to produce a DHCP DNSSEC trust 
anchor option... ah well).

  The ID and Johan's proposal are mostly targeted at the statically 
configured infrastructure devices such as caching resolvers.  It may be 
that the eventual right answer is to have them do a limited DHCP dip to 
grab the locally configured trust anchor policy information.  Or a global 
grab to a central registry.  Or something else?  I'd just like a common 
mechanism in the resolvers earlier rather than later.

re bandwidth:  Both of the proposals are in-band proposals - the client is 
doing key management based on the keys it sees which it would need anyway 
to do the DNSSEC validation.  I *think* there's no additional traffic above 
that of the DNSSEC engorged packets.