Subject: [dns-dir] FW: PRELIMINARY Agenda and Package for the August 25, 2011 IESG Teleconference

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 19 Aug 2011 09:49:23 +0200

Please find below the preliminary agenda of the 8/25 IESG telechat. Please send me your questions, comments and concerns related to the documents and WG charters on the agenda before 8/24 COB. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of IESG Secretary

2. Protocol Actions
2.1 WG Submissions
2.1.1 New Items

  o draft-ietf-pwe3-fat-pw-07
    Flow Aware Transport of Pseudowires over an MPLS Packet Switched
    Network (Proposed Standard)
    Note: Matthew Bocci ([email-masked]) is the
    document shepherd
    Token: Adrian Farrel

  o draft-ietf-sidr-rescerts-provisioning-10
    A Protocol for Provisioning Resource Certificates (Proposed
    Standard)
    Note: Sandra Murphy ([email-masked]) is the document
    shepherd.
    Token: Stewart Bryant

  o draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09
    Non Penultimate Hop Popping Behavior and out-of-band mapping for
    RSVP-TE Label Switched Paths (Proposed Standard)
    Note: Martin Vigoureux ([email-masked]) is the
    document shepherd.
    Token: Adrian Farrel

  o draft-ietf-yam-rfc4409bis-02
    Message Submission for Mail (Standard)
    Note: S Moonesamy ([email-masked]) is the document shepherd.
    Token: Pete Resnick

  o draft-ietf-pim-hello-intid-01
    An Interface ID Hello Option for PIM (Proposed Standard)
    Note: Mike McBride ([email-masked]) is the document shepherd.
    Token: Adrian Farrel

  o draft-ietf-mpls-tp-on-demand-cv-06
    MPLS On-demand Connectivity Verification and Route Tracing (Proposed
    Standard)
    Note: Loa Andersson ([email-masked]) is the Document Shepherd.
    Token: Adrian Farrel

  o draft-ietf-krb-wg-clear-text-cred-02
    The Unencrypted Form Of Kerberos 5 KRB-CRED Message (Proposed
    Standard)
    Note: Sam Hartman ([email-masked]) is the document shepherd.
    Token: Stephen Farrell

2.1.2 Returning Items

  o draft-ietf-grow-geomrt-05
    Multi-threaded Routing Toolkit (MRT) Border Gateway Protocol (BGP)
    routing information export format with geo-location extensions
    (Proposed Standard)
    Note: Christopher Morrow ([email-masked]) is the
    document shepherd.
    Token: Ron Bonica

2.2 Individual Submissions
2.2.1 New Items

  NONE

2.2.2 Returning Items

  NONE

3. Document Actions
3.1 WG Submissions
3.1.1 New Items

  o draft-ietf-v6ops-3gpp-eps-03
    IPv6 in 3GPP Evolved Packet System (Informational)
    Note: Joel Jaeggli ([email-masked]), v6ops co-chair is the
    document shepherd.
    Token: Ron Bonica

  o draft-ietf-dane-use-cases-05
    Use Cases and Requirements for DNS-based Authentication of Named
    Entities (DANE) (Informational)
    Note: Ond?ej Surï¿½ ([email-masked]) is the Document Shepherd.
    Token: Stephen Farrell

3.1.2 Returning Items

  o draft-ietf-bmwg-igp-dataplane-conv-meth-23
    Benchmarking Methodology for Link-State IGP Data Plane Route
    Convergence (Informational)
    Note: Al Morton ([email-masked]) is the shepherd.
    Token: Ron Bonica

  o draft-ietf-bmwg-igp-dataplane-conv-term-23
    Terminology for Benchmarking Link-State IGP Data Plane Route
    Convergence (Informational)
    Note: Al Morton ([email-masked]) is the shepherd.
    Token: Ron Bonica

3.2 Individual Submissions Via AD
3.2.1 New Items

  o draft-doria-genart-experience-04
    General Area Review Team (Gen-ART) Experiences (Informational)
    Token: Russ Housley

  o draft-yevstifeyev-ion-report-07
    Moving RFC 4693 to Historic (Informational)
    Token: Russ Housley

3.2.2 Returning Items

  NONE

3.3 IRTF and Independent Submission Stream Documents
3.3.1 New Items

  o draft-boucadair-pppext-portrange-option-06
    Huawei Port Range Configuration Options for PPP IPCP (Informational)
    Note: ISE Submission
    Token: Jari Arkko

3.3.2 Returning Items

  NONE

3.3.3 For Action

  o draft-weeb-research-to-internet-stds-02
    How to Contribute Research Results to Internet Standardization
    (Informational)
    Note: ISE Submission
    Token: Russ Housley

4. Working Group Actions
4.1 WG Creation
4.1.1 Proposed for IETF Review

  o Javascript Object Signing and Encryption (jose)
    Token: Sean

4.1.2 Proposed for Approval

  NONE

4.2 WG Rechartering
4.2.1 Under Evaluation for IETF Review

  o Layer 2 Virtual Private Networks (l2vpn)
    Token: Stewart

  o STORage Maintenance (storm)
    Token: David

---

From: Peter Koch <[email-masked]>
Date: Thu, 25 Aug 2011 11:45:30 +0200

>     Note: Ond?ej Surï¿?? ([email-masked]) is the Document Shepherd.
>     Token: Stephen Farrell

this is the only one on the list with relevance to DNS as far as i can see.
The document is well written, but i have a concern regarding the repeated
use of the term "domain holder" throughout the document. In the introduction
it says

   With the advent of DNSSEC [RFC4033], it is now possible for DNS name
   resolution to provide its information securely, in the sense that
   clients can verify that DNS information was provided by the domain
   holder and not tampered with in transit. [...]

where the first conclusion simply isn't true.  All that DNSSEC provides
is data origin authentication with the origin being the DNS zone.
DNSSEC dos not help to identify the party applying or authorizing
entries into that zone.  Later on, section 3.3 correctly makes that
distinction:

   By the same token, this use case puts the most power in the hands of
   DNS operators.  Since the operator of the appropriate DNS zone has de
   facto control over the content and signing of the zone, he can create
   false DANE records that bind a malicious party's certificate to a
   domain.  This risk is especially important to keep in mind in cases
   where the operator of a DNS zone is a different entity than the
   holder of the domain, as in DNS hosting/outsourcing arrangements,
   since in these cases the DNS operator might be able to make changes
   to a domain that are not authorized by the holder of the domain.

However, it's not only a malicious operator that can interfere. Nowhere
does it say that the operator has specific duties to verify or validate
DANE information before entering data into the zone. Negligence or malice
don't make a difference.   The fact that the zone is DNSSEC signed does
not change that since the only meaning of the RRSIGs is that the zone
operator attests the data was present as signed.

Also "domain holder" is usually understood as equivalent to a registrant,
meaning someone who registered a 2nd (or 3rd, where applicable) domain
name.  It is not obvious how to apply this logic to nodes further down
the tree.

-Peter