Subject: Re: [dane] #6: Downgrade attacks : What to do if DANE fails

From: "dane issue tracker" <[email-masked]>
Date: Tue, 08 Nov 2011 10:38:24 -0000

#6: Downgrade attacks : What to do if DANE fails

Changes (by warren@…):

 * status:  reopened => closed
 * resolution:   => worksforme

Comment:

 Please see email: http://www.ietf.org/mail-
 archive/web/dane/current/msg03711.html

 This is addressed in draft-ietf-dane-protocol-12 in Sections 1.2 Section
 4.4, para. 4, 5 and Appendix B.

-- 
--------------------------------+-------------------------
 Reporter:  mlepinsk@…          |       Owner:
     Type:  defect              |      Status:  closed
 Priority:  major               |   Milestone:
Component:  protocol            |     Version:
 Severity:  Active WG Document  |  Resolution:  worksforme
 Keywords:                      |
--------------------------------+-------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/6#comment:3>
dane <http://tools.ietf.org/dane/>

---

From: "dane issue tracker" <[email-masked]>
Date: Wed, 09 Nov 2011 04:58:49 -0000

Changes (by matt@…):

 * status:  closed => reopened
 * resolution:  worksforme =>

Comment:

 I hate to reopen this again (and I apologize for missing the deadline of
 Friday), but the essential issue that I mentioned in comment:2 is not
 addressed in Section 4.4 or Appendix B, and only obliquely if at all in
 Section 1.2.  Do we state that a client MUST fail the TLS handshake if it
 cannot get a secure or verified insecure response to the TLSA query?  If
 we do not make this requirement, clients could leave themselves open to a
 trivial TLSA stripping attack that defeats any restrictive semantics DANE
 might provide.  I understand we may want to leave room for local policy,
 but I'd argue that this requirement should have the same strength as the
 last MUST in section 4.4, because it is the conjunction of the two
 requirements that provides secure restriction.

-- 
--------------------------------+-----------------------
 Reporter:  mlepinsk@…          |       Owner:
     Type:  defect              |      Status:  reopened
 Priority:  major               |   Milestone:
Component:  protocol            |     Version:
 Severity:  Active WG Document  |  Resolution:
 Keywords:                      |
--------------------------------+-----------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/6#comment:4>
dane <http://tools.ietf.org/dane/>

---

From: Warren Kumari <[email-masked]>
Date: Sun, 13 Nov 2011 18:46:33 +0800

<chair hat>
We would like to get the working groups feedback on if they feel that this is unclear (and proposed text changes if so…)
</chair hat>

On Nov 9, 2011, at 12:58 PM, dane issue tracker wrote:

> might provide.

<no hat>
DNSSEC provides protection against stripping of resource records (like TLSA) - this is fundamental to the security of DNSSEC.

The parent says that a subdomain is signed, and then all of the records within that domain are signed (or you have explicit information that something isn't signed / doesn't exist).
</no hat>

W
>  I understand we may want to leave room for local policy,