Subject: [dane] comments on draft-ietf-dane-use-cases-02

From: =JeffH <[email-masked]>
Date: Fri, 13 May 2011 09:34:07 -0700

overall, I support the WG decision to produce this document.

If the WG wishes it to remain simply an I-D for WG-internal reference, then it 
doesn't necessarily need the full polish of all the below editorial comments, 
but still should be updated w.r.t. the more substantive comments, I believe.

However, if it is to be issued as an RFC, then it needs polishing IMV such that 
it is not unnecessarily misleading or obtuse to readers who are not enmeshed in 
the WG's work. If DANE work ultimately is successful and deployed, it will be 
very helpful if a foundational document such as this one is clear and accurate 
detail-wise.

I am willing to help edit the doc source if needed/desired.

HTH,

=JeffH
------
comments on draft-ietf-dane-use-cases-02
Jeff Hodges

overall comments:

   1. state explicitly that these use cases are applicable to any app service
      protocol layered over TLS, i.e. they don't apply to only HTTP/TLS.

   2. leverage terminology from RFC6125.

global editorial edits (though may need to be applied in case-by-case basis)..

   s/service/application service/g

   s/TLS client/application service client/g

   s/domain owner/domain holder/g

   s/owners of domains/domain holders/g

Stylistically, I'd prefer to use terms such as "Trent's CA" rather than "the CA 
Trent". Maybe it's just me, but the former seems to read better since we're 
using anthropomorphic natural names to denote the actors.

detailed inline comments...

[ some page headers/footers and boilerplate are elided ]

> DANE                                                           R. Barnes
> Internet-Draft                                          BBN Technologies
> Intended status: Informational                            April 29, 2011
> Expires: October 31, 2011
>
>
>     Use Cases and Requirements for DNS-based Authentication of Named
>                             Entities (DANE)
>                     draft-ietf-dane-use-cases-02.txt
>
> Abstract
>
>    Many current applications use the certificate-based authentication
>    features in TLS to allow clients to verify that a connected server
>    properly represents a desired domain name.

this first sentence needs rewriting; detailed comments below in Introduction 
section.

>                                                    Traditionally, this
>    authentication has been based on PKIX trust hierarchies, rooted in
>    well-known CAs, but additional information can be provided via the
>    DNS itself.  This document describes a set of use cases in which the
>    DNS and DNSSEC could be used to make assertions that support the TLS
>    authentication process.
>
> Status of this Memo
>
<snippage/>
>
>
> Table of Contents
>
>    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
>    2.  Definitions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
>    3.  Use Cases  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
>      3.1.  CA Constraints . . . . . . . . . . . . . . . . . . . . . .  4
>      3.2.  Certificate Constraints  . . . . . . . . . . . . . . . . .  5
>      3.3.  Domain-Issued Certificates . . . . . . . . . . . . . . . .  6
>      3.4.  Delegated Services . . . . . . . . . . . . . . . . . . . .  7
>      3.5.  Opportunistic Security . . . . . . . . . . . . . . . . . .  8
>      3.6.  Web Services . . . . . . . . . . . . . . . . . . . . . . .  8
>    4.  Other Requirements . . . . . . . . . . . . . . . . . . . . . .  9
>    5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
>    6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
>    7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
>    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
>      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
>      8.2.  Informative References . . . . . . . . . . . . . . . . . . 10
>    Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11
>
>
>
>
> 1.  Introduction
>
>    Transport-Layer Security or TLS is used as the basis for security

s/Transport-Layer Security or TLS/Transport Layer Security (TLS)/

>    features in many modern Internet applications [RFC5246].  It
>    underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207],
>    and provides hop-by-hop security in real-time multimedia and instant-
>    messaging protocols [RFC3261][RFC6120].
>
>    One feature that is common to most uses of TLS is the use of
>    certificates to authenticate domain names for services.

The latter sentence seems to me to make an inaccurate claim about TLS and its 
relation to domain names.

The TLS handshake, and thus "the TLS layer", doesn't itself "authenticate 
domain names for services". Rather, "server identity checking" is done in the 
application service layer (not in the TLS layer), after a successful TLS 
handshake, and is comprised only of checking whether there's a match between 
presented identifier(s) found in the cert (potentially in various locations) 
and reference identifier(s) derived from the source domain(s) and optionally, 
an application service type. It is sort of a crude form of channel binding. 
RFC6125 specifies the gory details.

Additionally, this matching is not "authentication" of the source domain name 
in a strict sense because there's no cryptographic authentication of the data 
resulting from the dereferencing of the domain name via DNS, neither is there 
cryptographic peer-entity authn of the DNS server, hence the DNS resolution can 
be transparently spoofed.

DANE is about binding cryptographically-based domain name resolution (i.e. 
DNSSEC-secured DNS resolution) into application service TLS connection 
establishment such that we do in fact have cryptographic assurance of the 
bindings between the matched domain name, its DNS records, the presented TLS 
certificate, and the connection with the peer entity.

I've massaged the introduction accordingly. I leverage terms from RFC6125 as 
appropriate (see its glossary for details). it also introduces the "mis-issued" 
situation..

>    Transport-Layer Security or TLS is used as the basis for security
>    features in many modern Internet applications [RFC5246].  It
>    underlies secure HTTP and secure email [RFC2818][RFC2595][RFC3207],
>    and provides hop-by-hop security in real-time multimedia and instant-
>    messaging protocols [RFC3261][RFC6120].
>
>    One feature that is common to most uses of TLS is the use of
>    certificates to authenticate domain names for services.  The TLS
>    client begins the TLS connection process with the goal of connecting
>    to a server with a specific domain name.  (The process of obtaining
>    this domain name is application-specific.  It could be entered by a
>    user or found through an automated discovery process, e.g., via an
>    SRV or NAPTR record.)  After obtaining the address of the server via
>    an A or AAAA record, the client conducts a TLS handshake with the
>    server, during which the server presents a PKIX certificate for
>    itself [RFC5280].  Based on this certificate, the client decides
>    whether the server properly represents the desired domain name, and
>    thus whether to proceed with the TLS connection or not.
>
>    In most current applications, this decision process is based on PKIX
>    validation and application-specific name matching.  The client
>    validates that the certificate chains to a trust anchor [RFC5280],
>    and that the desired domain name is contained in the certificate
>    [RFC6125].  Within this framework, bindings between public keys and
>    domain names are asserted by PKIX CAs.  Authentication decisions
>    based on these bindings rely on the authority of these CAs.
>
>    The DNS is built to provide information about domain names, and with
>    the advent of DNSSEC [RFC1034][RFC4033], it is possible for this
>    information to be provided securely, in the sense that clients can
>    verify that DNS information was provided by the domain owner.  The
>    goal of technologies for DNS-based Authentication of Named Entities
>    (DANE) is to use the DNS and DNSSEC to provide additional information
>    to inform the TLS domain authentication process.  This document
>    describes a set of use cases that capture specific goals for using
>    the DNS in this way, and a set of requirements that the ultimate DANE
>    mechanism should satisfy.
>

Transport Layer Security (TLS) is used by many modern Internet
application service protocols to provide secure client-server
connections [RFC5246].  It underlies secure HTTP and secure email
[RFC2818][RFC2595][RFC3207], and provides hop-by-hop security in
real-time multimedia and instant messaging protocols
[RFC3261][RFC6120].

Application service clients typically establish TLS connections to
application servers denoted by DNS domain names.  The process of
obtaining this "source" domain name is application specific (it
could be entered by a user or found through an automated discovery
process, e.g., via an SRV or NAPTR record).  After obtaining the
address of the server via an A or AAAA DNS record, the client
conducts a TLS handshake with the server, during which the server
presents its PKIX certificate [RFC5280]. The TLS layer performs
PKIX validation of the certificate including verification that the
certificate chains to a trust anchor. If successful, then the
application layer ascertains whether the application service DNS
name in the presented certificate matches the source domain name
[RFC6125], and typically proceeds with the TLS connection if so.

Thus certificate authorities (CAs) are asserting bindings between
domain names and the public keys they certify, and application
service clients are making authorization decisions--whether to
proceed with connections--based on these bindings. However, unless
there is a cryptographic binding between information in the TLS
channel and information in the DNS resolution channel, as well as
authentication of the DNS interaction and the returned DNS data,
the information obtained via the DNS is vulnerable to being
misrepresented or tampered with, thus allowing for
man-in-the-middle (MITM) impersonation of the application service.

Such MITM impersonation can today be accomplished by a network
attacker by obtaining a so-called "mis-issued" certificate
(obtained, for example, from a compromised member of the set of
well-known widely trusted-by-default CAs [ref?]) for some victim
application service domain, and using it along with "poisoned" DNS
resolution such that an arbitrary server of the network attacker's
choice appears to legitimately serve the victim application
service.

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. The goal of
technologies for DNS-based Authentication of Named Entities (DANE)
is to use DNSSEC-secured DNS information to provide cryptographic
assurance of domain name resolution in application service TLS
connection establishment.

This document describes a set of use cases that capture specific
goals for using the DNS in this way, and a set of requirements that
the ultimate DANE mechanism should satisfy.

> 2.  Definitions
>
>    This document also makes use of standard PKIX, DNSSEC, and TLS
>    terminology.  See RFC 5280 [RFC5280], RFC 4033 [RFC4033], and RFC
>    5246 [RFC5246], respectively, for these terms.
>
>    Note in particular that the term "server" in this document refers to
>    the server role in TLS, rather than to a host.  Multiple servers of
>    this type may be co-located on a single physical host, using
>    different ports, and each of these can use different certificates.

also reference terminology section in RFC6125 ?

>
>
> 3.  Use Cases
>
>    In this section, we describe the major use cases that the DANE
>    mechanism should support.  This list is not intended to represent all
>    possible ways that the DNS can be used to support TLS authentication.

s/the DNS/secure DNS/

>    Rather it represents the specific cases that comprise the initial
>    goal for DANE.
>
>    In the below use cases, we will refer to the following dramatis
>    personae:
>
>    Alice  The operator of a TLS-protected service on the host
>       alice.example.com, and administrator of the corresponding DNS
>       zone.
>
>    Bob  A client connecting to alice.example.com
>
>    Charlie  A well-known CA that issues certificates with domain names
>       as identifiers
>
>    Oscar  An outsourcing provider that operates TLS-protected services
>       on behalf of customers
>
>    Trent  A CA that issues certificates with domain names as
>       identifiers, but is not generally well-known.

I'd fix up the source to better align the above items

>    These use cases are framed in terms of adding protections to TLS
>    server certificates, since the use of these certificates to
>    authenticate server domain names is very common.  In applications
>    where TLS clients are also identified by domain names (e.g., XMPP
>    server-to-server connections), the same considerations and use cases
>    can also be applied to TLS client certificates.

rewrite latter para:

These use cases are framed in terms of adding verification steps to
TLS server identity checking on the part of application service
clients. In application services  where the clients are also
identified by domain names (e.g., XMPP server-to-server
connections), the same considerations and use cases can also be
applied to TLS application client certificates.

> 3.1.  CA Constraints

I would add a short intro para explaining why this use case is named "CA 
constraints".

>
>    Alice runs a website on alice.example.com and has obtained a
>    certificate from the well-known CA Charlie.  She is concerned that
>    other well-known CAs might issue certificates for alice.example.com
>    without her authorization, which clients would accept.  Alice would
>    like to provide a mechanism for visitors to her site to know that
>    they should expect alice.example.com to use a certificate issued
>    under the CA that she uses (Charlie) and not another CA.  In TLS
>    terms, Alice is letting Bob know that Charlie's certificate must
>    appear somewhere in the server Certificate message's certificate_list
>    structure.

s/structure./structure [RFC5246]./

Also noting Jim Schaad's first comment in this message..

http://www.ietf.org/mail-archive/web/dane/current/msg02566.html

..the last sentence may require further work. I.e. it may be unnecessarily 
specific w.r.t. TLS protocol handshake message contents. perhaps..

   In TLS terms,
   Alice is letting Bob know that Charlie's certificate is the "root
   certificate" [RFC5246], also known as a "trust anchor", and that her
   certificate must "chain" to Charlie's trust anchor when its evaluated for
   validity by Bob's TLS client.

>
>    When Bob connects to alice.example.com, he uses this mechanism to
>    verify that that the certificate presented by the server was issued
>    under the proper CA, Charlie.  Bob also performs the normal PKIX
>    validation procedure for this certificate, in particular verifying
>    that the certificate chains to a trust anchor.

s/a trust anchor./Charlie's trust anchor./

I would encapsulate the below paras in a subsection entitled something like 
"use case security analysis and derived requirements" because, strictly 
speaking, they aren't part of the use case...

>
>    Because these constraints do not increase the scope of PKIX-based
>    assertions about domains, there is not a strict requirement for
>    DNSSEC.  Deletion of records removes the protection provided by this
>    constraint, but the client is still protected by CA practices (as
>    now).  Injected or modified false records are not useful unless the
>    attacker can also obtain a certificate for the target domain.  In the
>    worst case, tampering with these constraints increases the risk of
>    false authentication to the level that is now standard.
>
>    Injected or modified false records can be used for denial of service,
>    even if the attacker does not have a certificate for the target
>    domain.  If an attacker can modify DNS responses that a target host
>    receives, however, there are already much simpler ways of denying
>    service, such as providing a false A or AAAA record.  In this case,
>    DNSSEC is not helpful, since an attacker could still case a denial of
>    service by blocking all DNS responses for the target domain.
>
>    Continuing to require PKIX validation also limits the degree to which
>    DNS operators (as distinct from the owners of domains) can interfere
>    with TLS authentication through this mechanism.  As above, even if a
>    DNS operator falsifies DANE records, it cannot masquerade as the
>    target server unless it can also obtain a certificate for the target
>    domain.

Is the point of attempting to justify the optionality of DNSSEC in this use 
case to illustrate that Alice can obtain (some level of) CA exclusivity (aka a 
"CA constraint") even w/o DNSSEC ?   I.E. an attacker who successfully obtains 
an otherwise valid mis-issued cert for Alice's domain would have to also 
poison/alter/spoof/block DNS for Alice's domain in order to successfully fool a 
DANE-compliant client into accepting the cert. However, as Jim Schaad and PaulW 
have pointed out, DANE w/o DNSSEC in this case is only making such an attack 
somewhat harder, but certainly not impossible. This should be noted in the 
analysis.

This also raises questions that should probably be mentioned in the security 
analysis and derived requirements:

   hard fail on DANE errors ?

   or forsee facilitating user click-throughs ?

> 3.2.  Certificate Constraints

I would add a short intro para explaining why this use case is named 
"Certificate constraints".

>
>    Alice runs a website on alice.example.com and has obtained a
>    certificate from the well-known CA Charlie.  She is concerned about
>    additional, unauthorized certificates being issued by Charlie as well
>    as by other CAs.  She would like to provide a way for visitors to her
>    site to know that they should expect alice.example.com to present the
>    specific certificate issued by Charlie.  In TLS terms, Alice is
>    letting Bob know that this specific certificate must be the first
>    certificate in the server Certificate message's certificate_list
>    structure.

s/structure./structure [RFC5246]./

>
>    When Bob connects to alice.example.com, he uses this mechanism to
>    verify that that the certificate presented by the server is the
>    correct certificate.  Bob also performs the normal PKIX validation
>
>
>
> Barnes                  Expires October 31, 2011                [Page 5]
> 
> Internet-Draft               DANE Use Cases                   April 2011
>
>
>    procedure for this certificate, in particular verifying that the
>    certificate chains to a trust anchor.

s/a trust anchor./Charlie's trust anchor, which was supplied to Bob
out-of-band of this interaction./

I would encapsulate the below paras in a subsection entitled something like 
"use case security analysis and derived requirements"...

>
>    As in Section 3.1., Alice's assertions about server certificates can
>    be used to constrain the behavior of an outsourcing provider Oscar as
>    well as the CA Charlie and other CAs.  Such a certificate constraint
>    requires Oscar to present the specified certificate to clients and
>    not another.

does the latter para really need to be here? it's essentially a hint about 
what's to come in section 3.4.  JimS also noticed this.

http://www.ietf.org/mail-archive/web/dane/current/msg02566.html

>
>    The other security considerations for this case are the same as for
>    the "CA Constraints" case above.

> 3.3.  Domain-Issued Certificates

"self issued certificate" seems to be a more commonly used term if one searches 
the net for both terms. though i think i can understand why you may want to use 
"domain issued" (arguably more technically accurate?).  might want a brief 
intro para and equate the two terms.

>
>    Alice would like to be able to use generate and use certificates for
>    her website on alice.example.com without involving an external CA at
>    all.  Alice can generate her own certificates today, making self-
>    signed certificates and possibly certificates subordinate to those
>    certificates.  When Bob receives such a certificate, however, he
>    doesn't have a way to verify that the issuer of the certificate is
>    actually Alice.

rewrite last sentence:

When Bob receives such a certificate in a TLS handshake, however, he doesn't 
automatically have a way to verify that the issuer of the certificate is 
actually Alice, because he doesn't necessarily possess Alice's corresponding 
trust anchor.

>                     This concerns him because an attacker could present
>    a different certificate and perform a man in the middle attack.  Bob
>    would like to protect against this.
>
>    Alice would thus like to have a mechanism for visitors to her site to
>    know that the certificates she issues are actually hers.

s/the certificates she issues are actually hers/the presented certificates are 
legitimately hers./

>                                                               When Bob
>    connects to alice.example.com, he uses this mechanism to verify that
>    the certificate presented by the server was issued by Alice.  Since
>    Bob can bind certificates to Alice in this way, he can use Alice's CA
>    as a trust anchor for purposes of validating certificates for
>    alice.example.com.  Alice can additionally recommend that clients
>    accept only her certificates using the CA constraints described
>    above.
>
>    This use case is functionally equivalent to the case where Alice
>    doesn't issue her own certificates, but uses a CA Trent that is not

s/a CA Trent/Trent's CA/

>    well-known.  In this case, Alice would be advising Bob that he should
>    treat Trent as a trust anchor for purposes of validating Alice's
>    certificates, rather than a CA operated by Alice herself.

this implies that Bob has to obtain Trent's trust anchor (TA) cert in some 
secure fashion.

the below says Alice advertises TA material, so it should be said explicitly above.

I would encapsulate the below paras in a subsection entitled something like 
"use case security analysis and derived requirements"...
>
>    Alice's advertising of trust anchor material in this way does not
>    guarantee that Bob will accept the advertised trust anchor.  For
>    example, Bob might have out-of-band information (such as a pre-
>    existing local policy) that indicates that the CA Trent advertised by
>    Alice is not trustworthy, which would lead him to decide not to
>    accept Trent as a TA, and thus to reject Alice's certificate if it is
>    issued under Trent.
>
>    Providing trust anchor material in this way clearly requires DNSSEC,
>    since corrupted or injected records could be used by an attacker to
>    cause clients to trust an attacker's certificate.

because here the Relying Party (RP aka client) is accepting the TA material 
from (supposed) Alice (?), and doesn't otherwise already have it ?

>                                                         Deleted records
>    will only result in connection failure and denial of service,
>    although this could result in clients re-connecting without TLS (a
>    downgrade attack), depending on the application.  Therefore, in order
>    for this use case to be safe, applications must forbid clients from
>    falling back to unsecured channels when records appear to have been
>    deleted (e.g., when a missing record has no NSEC or NSEC3 record).
>
>    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 owner
>    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 owner of the domain.
>
>    This is not a significant incremental risk, however, relative to the
>    current PKIX-based system.  In the current system, CAs need to verify
>    that an entity requesting a certificate for a domain is actually the
>    legitimate holder of that domain.  Typically this is done using
>    information published about that domain, such as WHOIS email
>    addresses or special records inserted into a domain.  By manipulating
>    these values, it is possible for DNS operators to obtain certificates
>    from some well-known certificate authorities today without
>    authorization from the true domain owner.

> 3.4.  Delegated Services
>
>    In addition to guarding against CA mis-issue, CA constraints and
>    certificate constraints can also be used to constrain the set of
>    certificates that can be used by an outsourcing provider.  Suppose
>    that Oscar operates alice.example.com on behalf of Alice.  In
>    particular, Oscar then has de facto control over what certificates to
>    present in TLS handshakes for alice.example.com.  In such cases,
>    there are few ways that DNS-based information about TLS certificates

s/few/only a few/

>    could be configured, for example:
>
>    1.  Alice has the A/AAAA records in her DNS and can sign them along
>        with the DANE record, but Oscar and Alice now need to have tight
>        coordination if the addresses and/or the certificates change.
>
>    2.  Alice refers to Oscar's DNS by delegating a sub-domain name to
>        Oscar, and has no control over the A/AAAA, DANE or any other
>        pieces under Oscar's control.

this appears to be the typical content-delivery approach for web app 
components, eg images 
<https://secure.wikimedia.org/wikipedia/en/wiki/File:Akamaiprocess.png>, but 
overlooks the case where alice's entire web app is delegated to Oscar (?)

>    3.  Alice can put DANE records into her DNS server, but delegate the
>        address records to Diane's DNS server.

Diane not in dramatis personae

should Diane be Oscar ?

>                                               This means that Alice can
>        control the usage of certificates but Diane is free to move the
>        servers around as needed.  The only coordination needed is when
>        the certificates change, and then it would depend on how the DANE
>        record is setup (i.e. a CA or an EE certificate pointer).
>
>    Which of these deployment patterns is used in a given deployment will
>    determine what sort of constraints can be made.  In cases where Alice
>    controls DANE records (1 and 3), she can use CA and certificate
>    constraints to control what certificates Oscar presents for Alice's
>    services.  For instance, Alice might require Oscar to use
>    certificates under a given set of CAs.  This control, however,
>    requires that Alice update DANE records when Oscar needs to change
>    certificates.  Cases where Oscar controls DANE records allow Oscar to
>    maintain more autonomy from Alice, but by the same token, Alice
>    cannot make any requirements on the certificates that Oscar uses.

s/cannot make/technically enforce/

see..
http://www.ietf.org/mail-archive/web/dane/current/msg02566.html

s/Oscar uses./Oscar presents in TLS handshakes./

>
> 3.5.  Opportunistic Security
>
>    Alice would like to to publish a web site so that Bob will always
>    have the benefit of the best security his client is capable of,
>    without resulting in a negative user experience when using a legacy
>    browser.  For example, suppose that Bob uses two browsers on
>    different machines, one is a legacy browser that does not support
>    DANE and cannot be updated, the other is a browser that has full
>    support for DANE.  In this case, the legacy browser should continue
>    to work as before, while the new browser should be able to discover
>    DANE support.  In general, the DANE mechanism must allow a clients to
>    determine whether DANE security is available for a site.

S3.5 reqs should all be mapped into S4, and S3.5 goes away.

see also..
http://www.ietf.org/mail-archive/web/dane/current/msg02566.html

>
> 3.6.  Web Services
>
>    A web service is an HTTP-based Internet protocol designed to support
>    direct machine-to-machine communication without the intervention of a
>    human operator or other form of supervisor.

Actually, fyi/fwiw, that definition is arguably too narrow in that there are 
various protocol specs out there denoted as "web services" wherein an explicit 
user agent speaks SOAP-over-HTTP.

>                                                  Since web services are
>    application protocols, the one aspect of Internet architecture that
>    is essential as far as a Web Service is concerned is that the DNS be
>    used as the naming system for service discovery.  Web Services
>    typically evolve over time.  A service provider must frequently
>    support legacy clients alongside new and in many cases multiple
>    versions of each protocol.  Discovering the certificates or keys to
>    be used to secure the connection to the Web service represents merely
>    one aspect of the more general problem of Web Service property
>    discovery.

This S3.6 doesn't appear to me to state a clear use case, nor necessarily have 
any import for the WG's work.  Drop it?   Andrew Sullivan also wondered about 
this need for this section.

http://www.ietf.org/mail-archive/web/dane/current/msg02565.html

> 4.  Other Requirements
>
>    In addition to supporting the above use cases, the DANE mechanism
>    must satisfy several lower-level operational and protocol
>    requirements and goals.
>
>    Multiple Ports:  DANE should be able to support multiple services
>       with different credentials on the same named host, distinguished
>       by port number.
>
>    No Downgrade:  An attacker who can tamper with DNS responses must not
>       be able to make a DANE-compliant client treat a site that has
>       deployed DANE and DNSSEC like a site that has deployed neither.
>
>    Encapsulation:  If there is a DANE information for the name
>       alice.example.com, it must only affect services hosted at
>       alice.example.com.
>
>    Predictability:  Client behavior in response to DANE information must
>       be spelled out in the DANE specification as precisely as possible,
>       especially for cases where DANE information might conflict with
>       PKIX information.
>
>    Simple Key Management:  DANE should have a mode in which the domain
>       owner only needs to maintain a single long-lived public/private
>       key pair.
>
>    Minimal Dependencies:  It should be possible for a site to deploy
>       DANE without also deploying anything else, except DNSSEC.
>
>    Minimal Options:  Ideally, DANE should have only one operating mode.
>       Practically, DANE should have as few operating modes as possible.
>
>    Wild Cards and CNAME:  The mechanism for distributing DANE
>       information should be compatible with the use of DNS wild cards
>       and CNAME records for setting default properties for domains and
>       redirecting services.

I support Andrew Sullivan's expansion on the latter item.

> 5.  Acknowledgements
>
>    Thanks to Eric Rescorla for the initial formulation of the use cases,
>    Zack Weinberg and Phillip Hallam-Baker for contributing other
>    requirements, and the whole DANE working group for helpful comments
>    on the mailing list.
>
>
>
>
>
>
> Barnes                  Expires October 31, 2011                [Page 9]
> 
> Internet-Draft               DANE Use Cases                   April 2011
>
>
> 6.  IANA Considerations
>
>    This document makes no request of IANA.
>
>
> 7.  Security Considerations
>
>    The primary focus of this document is the enhancement of TLS
>    authentication procedures using the DNS.  The general effect of such
>    mechanisms is to increase the role of DNS operators in authentication
>    processes, either in place of or in addition to traditional third-
>    party actors such as commercial certificate authorities.  The
>    specific security implications of the respective use cases are
>    discussed in their respective sections above.
>
>
> 8.  References
>
> 8.1.  Normative References
>
>    [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
>               STD 13, RFC 1034, November 1987.
>
>    [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
>               Rose, "DNS Security Introduction and Requirements",
>               RFC 4033, March 2005.
>
>    [RFC5246]  Dierks, T. and E. Rescorla, "The Transport Layer Security
>               (TLS) Protocol Version 1.2", RFC 5246, August 2008.
>
>    [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
>               Housley, R., and W. Polk, "Internet X.509 Public Key
>               Infrastructure Certificate and Certificate Revocation List
>               (CRL) Profile", RFC 5280, May 2008.
>
> 8.2.  Informative References
>
>    [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
>               RFC 2595, June 1999.
>
>    [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
>
>    [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
>               Transport Layer Security", RFC 3207, February 2002.
>
>    [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
>               A., Peterson, J., Sparks, R., Handley, M., and E.
>               Schooler, "SIP: Session Initiation Protocol", RFC 3261,
>
>
>
> Barnes                  Expires October 31, 2011               [Page 10]
> 
> Internet-Draft               DANE Use Cases                   April 2011
>
>
>               June 2002.
>
>    [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
>               Protocol (XMPP): Core", RFC 6120, March 2011.
>
>    [RFC6125]  Saint-Andre, P. and J. Hodges, "Representation and
>               Verification of Domain-Based Application Service Identity
>               within Internet Public Key Infrastructure Using X.509
>               (PKIX) Certificates in the Context of Transport Layer
>               Security (TLS)", RFC 6125, March 2011.
>
>
> Author's Address
>
>    Richard Barnes
>    BBN Technologies
>    9861 Broken Land Parkway
>    Columbia, MD  21046
>    US
>
>    Phone: +1 410 290 6169
>    Email: [email-masked]

---
end