IETF61 DNSEXT Minutes

["Olaf M. Kolkman" <[e-mail]>]

DNSEXT WG notes  11/10/04 @ 13:00
Washington DC, IETF 61
Scribe: Scott Rose
Jabber scribe: George Michaelson

- 2538bis Request for input
  proxy: Olafur Gudmundsson
  draft-josefsson-rfc2538bis-00.txt

  RFC2538bis CERT RR Simon Josefsson has taken on the task of updating
  and advancing the document along the standards track. Send him
  comments on the document and reports of implementations.  If no
  changes, we can advance it, otherwise rev it and then advance it.
  Goal: to finish this before next IETF meeting

- Key crypto                                     
  Donald Eastlake
  draft-ietf-dnsext-ecc-key-05 and 
  draft-ietf-dnsext-tsig-sha-00

  o ECC - Draft only defines key format, not RRSIG
    format.

    Questions for group:
    - Include RRSIG format back into draft?
    - Make format applicable to KEY/DNSKEY and IPSECKEY
 
    There was a question if there are any crypto libraries that
    contain ECC, at least one open source one was identified.

  o TSIG-SHA: Specification of the SHA with various
    http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-8/sld1.htm

    sizes. includes specification for truncation to shorter MACs
    Open questions that need to go to WG:
    - Why go to SHA1 it it is no longer than MD5?
    - Why not standardize on longer SHA1?

    Donald's answer:Some crypto people like SHA1, and it is quicker
    to compute.

    Follow up 
    -  why have to allocate all these names?
    - take discussion to list
    WGLC action to be issued soon


- QR clarification                                    
  Roy Arends 
  draft-arends-dnsext-qr-clarification-00.txt

  Summary in one line: Servers must not answer an incoming message
  with the QR bit set.

  Room does not object if this document becomes a WG document.

  Based on discussion Roy needs to update document to have slightly
  better definition on what the scope is (ie. only about the Q/R
  bits).


- Wildcard clarification
  Ed Lewis
  draft-ietf-dnsext-wcard-clarify-03.txt

  New material (editorial concerns)
     1. Drop "clarifying" from title
     2. include text on "*  IN  DS"   
        presentation on what "*   IN   DS" could mean
   RFC1034:  if the query has a qname="*", the results should not be cached...

     Example in presentation:
     ************************************************
     Zone has    *.example.   IN 3600 NS bogon.example.
                 *.example.   IN 3600 NSEC twn.example. NS NSEC RRSIG

                 twn.example. IN 3600 NSEC twp.example. ...
                 twn.example. IN 3600 RRSIG NSEC ... signed by example. ...

                 twp.example. IN 3600 NSEC example. ...

      Query: two.example. IN NS

      Answer has (?):
      AA = 1, RCODE = 0 (not name error)
      Answer:       two.example. IN 3600 NS bogon.example.
      Authority:    twn.example. IN 3600 NSEC twp.example. ...
                    twn.example. IN 3600 RRSIG NSEC ... signed by example. ...

  Suggested fixes:
	a. outlaw loading zones with *  NS
	b. exempt certain types from wildcard processing
	c. instruct DNSSEC validators to ignore "problem"
	d. Specify * label can't have certain types and cannot be subdomained

  Questions:

  There where some statements that c. was the right way to go, but
  need for a clear definition what that means. There was also
  discussion that this is an answer not a referral but that needs to
  be discussed on the mailing list.

- Requirements for future work on Denial of Existence (approx 20 minutes)
  Olaf Kolkman

  Chairs had a meetings with req. editors and others to prioritize
  reqs and solution sets at the IETF to facilitate high bandwidth
  exchanges.
	
  Rip Loomis presentation on the priority of requirements"
  http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-2/sld1.htm
  Please read slides for full contents of this presentation) New ID
  Will contain a list of the requirements as the priority: Required,
  med-level desire, low-level desire, very low-level desire.

  There was discussion on exposing online keys, not everyone is
  concerned with zone enumeration, but some are.  Some of the "don't
  care" about zone walking may care about having keys online

  In the discussion about "Universal signing": Which zones can (under
  which conditions) not be signed?
  Ans: some zones with long domain names may not be able to be signed
  with hashed based schemes (over 255 label limit)

  A comment was made that current NSEC design and DNSSEC does not
  cover the RCODE in the message.  Some of the proposed solutions to
  zone walking cover RCODE.

  Olaf K and proposals for zone walking:
  http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-0.pdf (pages
  9-11)

  There are basicly two characteristics of proposals, hash-based or
  online-signing both have various flavors, and they measure
  differently against requirements/constraints. WG needs to evaluate
  proposals against priority list of requirements and form plan for
  possible long term solution.

  The three main categories of solutions are
     Epsilon signing (white lies)
     New type for Negative answers that contains information from the
	query (called magic type in the discussion, better name
	needed)
     Hash based solutions with varying flavors of Opt-in and wildcards

  Proposed way forward:

  o Fast track Epsilon Signing as that has minimal impact on
    implementations (only authorative servers affected) and moves the
    cost of deployment on the parties that can not live with NSEC;

  o and work on a protocol change that does not need on-line keys.
 
  Goal is to have at most one DNSSECter (ie solutions that require
  changes in resolvers)

  Question:  Does this way forward make sense?  Room seems to think so.


- DNSSEC keymanagement issues 

  Johan Ihren
   draft-ietf-dnsext-trustupdate-threshold-00.txt 

  Mike StJohns

  Ben Laurie
   draft-laurie-dnssec-key-distribution-00.txt


  DNSSEC key management issues
  Johan Ihren (Threshold based trust update)
  http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-3/sld1.htm
  Possible IPR issues with schema editors will investigate.
  Draft is better, implementation of version 00 is available

  Changes in draft:
     o Simplified Definition of M and N threshold params
     o Documented the state machine better
     o Fixed the replay attack that was possible before
  No questions

  Question: how long to complete?

  Ihren: fairly complete with some issues.  Priming stuff needs more
	 work.  Overall it works.  IPR issues are up in the air.


  Mike St Johns  (rolling over the trust anchor)
  http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-4/sld1.htm

  No major changes from prior version mainly related to timers and
  DNSKEY removal from apex.

  Question to group - is it worth pursuing an in-band mechanism?


  Ben Laurie (DNS Key distribution)

  new, individual submission
  (draft-laurie-dnssec-key-distribution-00.txt) not a WG item yet:
  need more readers/comments/etc!  Islands of trust issues, some
  people don`t like single auth. inband stuff is tricky. lots of keys,
  lots of data Mechanism is cross-signing scheme. start with one,
  fetch more. can recurse or stop


  Closing remarks

  Olafur Gudmundsson: WG is to consider which KEY mechanisms to promote.
  Timers and Threshold both say they are close to be ready for LC.
  Chair to check with Security AD if there are any obvious security
  problems with either proposal.


- Cross fertilization 
  (DNS related work in other groups that needs review)

   James Snell
   draft-snell-dnsepd-00.txt  

   draft-iab-dns-choices-00.txt
   Patrik Faltstrom

   DNS issues in SPF           
   Stephane Bortzmeyer


   + James Snell(DNS Endpoint discovery)
     http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-5/sld1.htm
     Individual submission not seeking to be a WG document
    (draft-snell-dnsepd-00.txt)

     This is used for providing web-services tools
        2 new RR:  XML and EPR

    There where concerns that the XML RR was to open and should be
    changed to Web services only with restrictions. Number of people
    suggested that they use NAPTR records for this.  Editors thanked
    for feedback and will update documents based on that.


   + Patrik Faltstrom (DNS Design Choices)
     IAB draft:  (draft-iab-dns-choices)
     - discussion of DNS choices in protocol design.

     - question about scope of who to go to with DNS questions
       involving new DNS RRs

    - TomasN:  2 part response:
      1 is it going to hurt DNS?

      2. Does it help the protocol in question that is requesting it?
         DNSEXT or successor will deal with topic 1. .

    - Is there a need to have a separate draft to request the new RR type?
      A:  no.

  Stephane Bortzmeyer (DNS and SPF)
  http://www1.ietf.org/proceedings_new/04nov/slides/dnsext-6.pdf
  non-wg draft:  draft-lentczner-spf-00.txt

    SPF: Sender Policy Framework. this is a request for a new RR type
    used by mail-servers to detect spoofed email's. SPF is defined as
    TXT RR with a new name.  

    There where concerns with reusing TXT due to implementation
    problems in the past.  Suggestion from WG to specify a new RR with
    one RDATA field and use RDLEN as indicator of how long the data
    is.  There where also questions raised about the recommendation
    that Mail server check for both types (TXT and SPF) and the
    policies for issuing these queries (serial, parallel, which one
    takes preference).


End of meeting


--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>