Subject: [dane] Publication request plan of the draft-ietf-dane-use-cases

From: Ondřej Surý <[email-masked]>
Date: Wed, 29 Jun 2011 18:17:09 +0200

Hi all,

I would like to thanks all for their valuable comments on use cases.
Richard is going to publish new version which will address rest of the
comments which were raised in the list.

The one last issue where we don't have *full* consensus is "DNSSEC
optional" and the chairs have decided that the document has enough
support to go forward with "DNSSEC optional" in the document (with
a change in the wording).

We are going to request publication request on the -04 once it hits the
tracker.

Ondrej
-- 
 Ondřej Surý
 vedoucí výzkumu/Head of R&D department
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Martin Rex <[email-masked]>
Date: Wed, 29 Jun 2011 19:12:11 +0200 (MEST)

> a change in the wording).

I'm confused.

The highest positive value of DANE without DNSSEC is sufficient
close to zero that it is not worth bothering with it.

The potential negative value (delusion,threat,vulnerbility) of
DANE without DNSSEC is so huge and serious, that a proper security
considerations to guard against this will have to be so long
and complex that it can not possibly be comprehensible to the
average reader -- so we should not even try.

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jun 2011 13:33:30 -0400

This is a use cases document.

Dnssec is an implementation technology. It is totally inapproprate even to mention it in use cases and requirements.

There might be an architectural requirement to have a secure DNS channel, but that is it.

Mandating technology in requirements is bad.

Sent from my angry birds device.

On Jun 29, 2011, at 13:12, Martin Rex <[email-masked]> wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 29 Jun 2011 13:25:49 -0400

> average reader -- so we should not even try.

I couldn't say it better myself.

-- 
Andrew Sullivan
[email-masked]

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 29 Jun 2011 19:27:02 +0200

Martin,

my view is that we are speaking about the use cases document and it has a place in the *use case* document.

I am prepared to have the discussion whether we will have this option in the dane protocol or not. We may tighten some places or loosen some in the protocol for exactly same reasons you wrote down below.

So please bear in mind that we are only talking about use cases and it *is* valid use case and from what I have seen in the preview of -04 the new wording is very careful when it comes to this issue.

Ondřej Surý

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 29 Jun 2011 13:58:00 -0400

Yep.  The possibility of using DANE without DNSSEC had been raised as a possibility by some participants, so it seemed fair to describe what the implications would be of allowing this case.  To whit, in the new version:
"
In principle, DANE information expressing CA constraints can be presented with or without DNSSEC protection.  Presenting DANE information without DNSSEC protection does not introduce any new vulnerabilities, but neither does it add much assurance.
"

It is still fully possible that the ultimate DANE protocol will require DANE clients to reject non-DNSSEC-protected DANE records.  (Of course, you can always provision them in your name server.)

--Richard

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 29 Jun 2011 15:38:36 -0400

This also has bearing on whether DANE ends up conflating security policy and
key distribution.

While it is very clear that DANE offers little value as a key distribution
mechanism without some form of assurance as to the authenticity and
integrity of the DNS records,also clear that:

1) The authenticity and integrity assurances can be delivered through means
other than DNSSEC (e.g. DNS over IPSEC to trusted resolver, DPLS to a
trusted resolver, etc.)

2) Security policy information may have some value even if there are no
authenticity or integrity controls on the DNS records (e.g. site says 'SSL
upgrade is always available').

-- 
Website: http://hallambaker.com/