Subject: [dane] Opening issues #25, #26, #27 as a group.

From: Warren Kumari <[email-masked]>
Date: Wed, 14 Sep 2011 17:38:42 -0400

Hi all.

These are all related issues:
#25: http://trac.tools.ietf.org/wg/dane/trac/ticket/25 - Independent additive and restrictive assertions
#26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restrictive assertions a conformance requirement, additive ones not?
#27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunction of restrictions

It would be great if we could discuss them as a group, and come to some sort of consensus by next Friday (September 23rd).
If commenting on a particular issue number, it would be awesome if you could clearly state which :-P

W

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 14 Sep 2011 14:45:56 -0700

> #27: http://trac.tools.ietf.org/wg/dane/trac/ticket/27 - Conjunction of restrictions

As a general observation, I think leaving anything to "client policy"
is a recipe for interoperability disaster.  There should be no wiggle
room for two different clients to behave differently in response to a
given set of TLSA records plus TLS handshake.

zw

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 14 Sep 2011 17:51:59 -0400

I very strongly believe that the additive and restrictive aspects need to be
separated.

Separating the issues is necessary because the distribution concerns are not
the same for additive and restrictive. DNSSEC access is not 100% and we can
expect that it will be 0% in Internet connections sanctioned by the
government of Iran. Thus a bypass mechanism is required and additive and
restrictive trust require different approaches.

If the record is only providing additive trust then it is only essential to
get the record through to a client that is going to rely on the additive
data. This can be achieved if necessary by stuffing the DNS data into Certs
or OCSP tokens distributed by the cert subject (a la Langley/Kaminsky).

If the record is providing restrictive trust the Cert or OCSP stuffing
approach fails because it can be suppressed. Nor does DNSSEC provide any
real leverage for an end client unless it has a means to bypass a MITM
attack and gain a connection to DNSSEC ground truth. The approach here is
likely to require some clients that use access to DNSSEC ground truth to
alert response parties to the fact of an attack coupled with some out of
band mechanism for pushing out policy in the case of an attack.

These are two separate problems and should be addressed independently.

On Wed, Sep 14, 2011 at 5:38 PM, Warren Kumari <[email-masked]> wrote:

> #26: http://trac.tools.ietf.org/wg/dane/trac/ticket/26 - Restrictive
> assertions a conformance requirement, additive ones not?
> It would be great if we could discuss them as a group, and come to some
> sort of consensus by next Friday (September 23rd).
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

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

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 15 Sep 2011 20:50:15 -0700

I believe that #27 is a duplicate of #32.

While I believe that this should be addressed, the current group consensus
is that it will not be addressed.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Warren Kumari
> Sent: Wednesday, September 14, 2011 2:39 PM
> To: DANE WG
> Subject: [dane] Opening issues #25, #26, #27 as a group.
> 
> Hi all.
> 
assertions
> a conformance requirement, additive ones not?
sort
> of consensus by next Friday (September 23rd).

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Sep 2011 12:07:10 -0400

It appears to the chairs that issues #25, #26, #27 are all variations on a theme and are all predicated on DANE doing  [ conjunctive / disjunctive / grouping / sets ] -- see issue #32, Matt's proposed schema ( https://www.ietf.org/mail-archive/web/dane/current/msg02637.html ), etc.

We believe that this was viewed by the WG as cool and sexy, but adding too much additional complexity to the protocol (see the thread around: http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ).

Unless we hear that the WG would like to reconsider this, we are planning on calling these issues closed.

W

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 21 Sep 2011 19:26:47 -0700

On Wed, 2011-09-21 at 12:07 -0400, Warren Kumari wrote:
> It appears to the chairs that issues #25, #26, #27 are all variations
> on a theme and are all predicated on DANE doing  [ conjunctive /
> disjunctive / grouping / sets ] -- see issue #32, Matt's proposed
> schema
> ( https://www.ietf.org/mail-archive/web/dane/current/msg02637.html ),
> etc.

No... that is only true of #27.

- #25 can alternatively be done with flags in the RRset.

- #26 is purely a policy question, orthogonal to conjunction support.

We have at least Phill's and my +1 to address #25.

> We believe that this was viewed by the WG as cool and sexy, but adding
> too much additional complexity to the protocol (see the thread around:
> http://www.ietf.org/mail-archive/web/dane/current/msg03351.html ).
> 

Does this determination stand (for #27) given my new proposal and
remarks in
http://www.ietf.org/mail-archive/web/dane/current/msg03418.html ?

-- 
Matt

---

From: Warren Kumari <[email-masked]>
Date: Thu, 22 Sep 2011 17:40:15 -0400

> http://www.ietf.org/mail-archive/web/dane/current/msg03418.html ?

"Unless we hear that the WG would like to reconsider...."

So, working group, would you like to reconsider this, given Matt's new proposal and referenced remarks?
Please *clearly* indicate a preference.

W

---

From: bert hubert <[email-masked]>
Date: Thu, 22 Sep 2011 23:46:03 +0200

> Please *clearly* indicate a preference.

I'm with Jakob & Phillip here. I also urge the WG to keep DANE as simple as
possible. 

So keep it closed please.

-- 
PowerDNS Website: http://www.powerdns.com/
PowerDNS Community Website: http://wiki.powerdns.com/

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 22 Sep 2011 19:31:45 -0700

> Please *clearly* indicate a preference.

To clarify, this call is for #27, right?  Because #25 and #26 are not,
as you claimed, predicated on DANE doing conjunctions.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 22 Sep 2011 23:51:07 -0700

> given set of TLSA records plus TLS handshake.

Let's be realistic: the major browsers will implement whatever they
judge is best for their users, regardless of what the spec says.  (And
so will I in my nss-dane, for what that's worth.)  IETF cannot coerce
anybody.  I think we can most usefully view our role as defining a
"model" or "ideal" DANE client behavior, from which the deviations of
any implementation can be stated and their desirability evaluated.  And
indeed, there should be no wiggle room in the "model" behavior.  I'm not
sure whether this position constitutes agreement or disagreement with
you.

Separately, I would like to see us make explicit the semantics of the
TLSA RRset as an assertion from which any party, not just a
DANE-compliant TLS client, can draw conclusions about the TLS service.

-- 
Matt