Subject: Re: [dane] New Version Notification for draft-ietf-dane-use-cases-03.txt

From: =JeffH <[email-masked]>
Date: Wed, 15 Jun 2011 19:53:36 -0700

wrt my comments in..

[dane] comments on draft-ietf-dane-use-cases-02
http://www.ietf.org/mail-archive/web/dane/current/msg02582.html

..although the Introduction section in -03 is now more clear, you didn't 
include the portions describing MITM attacks and certificate mis-issuance. Thus 
the comments I and others had WRT the sudden appearance of the phrase "guarding 
against CA mis-issue" in the opening paragraph of "3.4. Delegated Services" are 
un-addressed.

without material along the lines of..

                                                   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.

..in the doc, then it lacks some important context with respect to the use 
cases and their security considerations. Other folks had noted on the list that 
having "CA mis-issue" used at the beginning of S 3.4 without definition or 
context confuses readers.

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

..Jim Schaad said amongst other things..

 > 3.  I find the statement referring to security consideration of section 3.1
 > from 3.2 difficult as they are not clearly defined as such.   Given that I
 > cannot easily find the security considerations - they are not in section 7
 > and are not labeled then it does not make sense.  Implications might be a
 > better word here.  Also I think that if you really consider them to be
 > considerations they should be referenced from section 7.

I agree with Jim.

I'd also noted similar things in my detailed review (see link at beginning of 
this msg) with respect the nominal "security considerations" ( I termed them 
"use case security analysis and derived requirements", to some degree because 
they are use-case-specfic considerations, and then one could have an actual Sec 
Cons section with global stuff in it and refer back to these cleanly).

  wrt S 3.1...

 > 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.
 >

And for S 3.3...

 > 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.
 >>
 >>    <snippage/>
 >>
 >>    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.

Jim Schaad in the same msg also said...

 > 1.  I cannot say that I like the title of section 3.3.  To me a
 > Domain-Issued Certificate is not the same as making a trust anchor assertion
 > which is what I think the section is really about.  To me a Domain-Issued
 > Certificate would still be a true statement if Alice got a sub-CA to Charlie
 > and issued here own certificates.  I would prefer that this used more PKIX
 > style terminology as what this section is addressing is publishing trust
 > anchors.

I also think the title of section 3.3 can be improved and had suggested..

 >> 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.

Editorial comments are below, some of which i see others have also noticed.

I may make some further comments in the list thread.

thanks,

=JeffH

EDITORIAL
---------

In S 3.1:

s/does not guaranteed/does not guarantee/

s/represents provides/represents/  or  s/represents provides/provides/

In S 3.3:

s/since because/since/   or   s/since because/because/

 >    Opportunistic Security The DANE mechanism must allow a clients to

s/a clients/a client/  or  s/a clients/clients/    ?

 >                                     Clients that do not support DANE	
 >    should continue to work as if DANE information were not present

perhaps..

   Clients that do not support DANE should continue to work as specified,
   regardless of whether DANE information is present or not.

---
end

---

From: =JeffH <[email-masked]>
Date: Wed, 15 Jun 2011 20:07:55 -0700

Jim Schaad said..
 >
 > 2.  Along the same lines I would like to change the title of section 3.2 -
 > even a CA constraint is a constraint on a certificate.  This might be better
 > stated as Service Certificate Constraint

I'm nominally ok with the current section title, but if one used Jim's 
suggested title I'd use "Application Service Certificate Constraints"

I also had suggested adding a short intro paragraph before the existing first 
paragraph briefly explaining the use case context and what is meant by "CA 
constraints".

In http://www.ietf.org/mail-archive/web/dane/current/msg02582.html I said:

 >> 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
 >>  ............

Jim Schaad also said:
 >
 > 4.  In section 3.2  the following text exists: " 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."  But there is nothing inherit
 > here that says it was issued by Charlie.  I would suggest s/the specific
 > certificate issued by Charlie./a specific certificate./

I tend to agree with this suggestion.

thanks,

=JeffH