[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
IETF61 DNSEXT Minutes
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 namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>