Subject: [dane] Aiming towards some specific wording

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Nov 2011 12:27:50 -0800

[[ New version, incorporating comments from this thread so far. Please let me know if the specific wording of the proposals is OK, but not whether you support them. ]]

Greetings again. The recent threads are useful, but some people change the topic mid-thread so determining what actual words people want in the draft is difficult. As document co-author, I want to nail down the words. To do that, the WG needs some choices, and that is the purpose of this message. I have tried to cast each of the choices expressed in the past few days in actual text that would appear in the document.

THIS IS NOT A CALL FOR SUPPORT FOR ANY WORDING!!! This is a call to be sure that all opinions are given for a LATER CALL. Sorry to use the ALL CAPS there, but people here tend to vote quickly and then ask for modifications later.

I propose the following preamble wording to the "interesting" parts of the wording:

========== PREAMBLE A START ==========

Determining whether a TLS certificate association can be used depends
on the DNSSEC valiation state (as defined in [RFC4033]).

o  A TLS certificate association whose DNSSEC validation state is
   secure can be used for TLS.

o  A TLS certificate association whose DNSSEC validation state is
   bogus MUST cause TLS not to be started or, if the TLS negotiation
   is already in progress, to cause the connection to be aborted.

========== PREAMBLE A END ==========

One of the following, or some other choice, needs to be added to the preamble.

========== CONTINUATION 1 START ==========

o  A TLS certificate association whose DNSSEC validation state is
   indeterminate or insecure cannot be used for TLS and must be marked
   as unusable.

========== CONTINUATION 1 END ==========

############# OR ####################

========== CONTINUATION 2 START ==========

o  A TLS certificate association whose DNSSEC validation state is
   indeterminate or insecure and whose usage is 0 or 1 MAY be used for
   TLS if application marks it as usable.

o  A TLS certificate association whose DNSSEC validation state is
   indeterminate or insecure and whose usage is 2 MUST NOT be used for
   TLS and must be marked as unusable.

o  Future definitions of new certificate usages MUST include
   specification of whether or not DNSSEC validation is required
   for that usage.

========== CONTINUATION 2 END ==========

Again, PLEASE DO NOT SAY YET WHICH OF THESE YOU SUPPORT. Instead, if you think the wording in Preamble A, Continuation 1, or Continuation 2 do not exactly match what you would want in the spec, please propose a different preamble or continuation text (not just "ideas"). That way, when we later ask for what wording people want, all proposals will already be on the table and we will not (again) have wording changes appear mid-vote. Thanks in advance for your cooperation.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 20 Nov 2011 14:37:07 -0800

>    is already in progress, to cause the connection to be aborted.

Regardless of editorial preferences elsewhere, it is essential that this
point refer to a "TLSA RRset", not a "TLS certificate association".  The
wording above, taken literally, would not cover the case in which an
attacker replaces a TLSA RRset containing a restrictive certificate
association with a bogus TLSA RRset that is empty.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Nov 2011 14:50:45 -0800

> association with a bogus TLSA RRset that is empty.

Arrrgh: very good point. Will be updated in the next rev of the wording choices to be sent to the group. And, combined with Peter Koch's earlier request, I'll move the use of "certificate association" to later in the text so that all these bullets use "RRset" consistently.

After the call for wording choices and the next draft, I suspect there will be more word juggling...

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 20 Nov 2011 18:58:49 -0800

>    TLS and must be marked as unusable.

We need to be more careful here.  Since restriction is enforced whenever
there is at least one usable association, allowing the client to mark
some associations usable and others unusable will result in connection
failures when the server uses a certificate corresponding to one of the
associations marked unusable.  I propose the following replacement text
for Continuation 2:

o If the TLSA RRset has DNSSEC validation state "insecure" or
"indeterminate", the client MUST do one of the following:

  (1) Proceed as if each association of usage 2 instead had usage 0.

  (2) Proceed as if the TLSA RRset were empty.

o Future definitions of new certificate usages MUST amend (1) above to
specify the changes, if any, to be made to associations of that usage.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Nov 2011 19:34:41 -0800

On Nov 20, 2011, at 6:58 PM, Matt McCutchen wrote:
> I propose the following replacement text
> for Continuation 2:
> 

I will add that as another option.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 20 Nov 2011 20:19:18 -0800

> I will add that as another option.

Is that really necessary?  It seems clear to me that the original
formulation of Continuation 2 is simply broken (no offense to you) and
cannot possibly be what the proponents of DNSSEC-less restriction would
have intended.  But if it is too difficult to establish that at this
point, we can just vote on the three options.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 20 Nov 2011 22:32:26 -0800

On Nov 20, 2011, at 8:19 PM, Matt McCutchen wrote:

> Is that really necessary?  

Yes.

> It seems clear to me that the original
> have intended.  

Fine. If absolutely everyone agrees with you, and doesn't want the Continuation 1, then we've only wasted a few electrons. If someone disagrees with what is clear to you, then there is value to keeping all three.

> But if it is too difficult to establish that at this

Glad we agree here.

--Paul Hoffman

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 21 Nov 2011 09:56:26 -0500

> specify the changes, if any, to be made to associations of that usage.

I would propose that (2) is the only useful option here.  If validation state != secure || bogus, then behave as if the RRset were empty.  In text form:

o If the TLSA RRset has DNSSEC validation state "insecure" or
"indeterminate", then the client MUST proceed as if the TLSA
RRset were empty.

--Richard

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 21 Nov 2011 16:50:14 +0100

On 20. 11. 2011, at 21:27, Paul Hoffman wrote:

> on the DNSSEC validation state (as defined in [RFC4033]).
> 

Since we are not requiring the DANE-aware application to include
validating resolver, you cannot really use RFC4033 states here.

Any application using trusted validating resolver will only see
DNS flags (+AD), RCODE and DNS RRSets and it will have to ask
with +DNSSEC OK flag.

So we will have to define our own state table, I propose to base
the work on Richard's updated flowchart/state table.

Our states (from trusted validating resolver):
SECURE - +ADFlag && (RCODE=NOERROR || RCODE=NXDOMAIN)
BOGUS = !(RCODE=NOERROR || RCODE=NXDOMAIN)
INSECURE = -ADFlag

Then the wording would be:

o A DNS response for TLSA RRset query whose state is SECURE
  can be used for further DANE processing.  If the TLSA RRset
  is non-empty it can be used for TLS.

o A DNS response for TLSA RRset query whose state is BOGUS
  cause TLS not to be started or, if the TLS negotiation is
  already in progress, to cause the connection to be aborted.

o A DNS response for TLSA RRset query whose state is INSECURE
  cannot be used for TLS and must be marked as unusable.

O.

> ========== CONTINUATION 2 END ==========

As Warren pointed out the CONTINUATION 2 is out of the charter.

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

--
 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: Peter Koch <[email-masked]>
Date: Mon, 21 Nov 2011 16:53:07 +0100

> "indeterminate", then the client MUST proceed as if the TLSA

while mathematically comprehensible, I'd recommend against this particular
language just because in the DNS we do not talk about "empty RRSets".
So s/RRset were empty/RRSet would not exist/ would do it.

-Peter

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 21 Nov 2011 11:21:55 -0500

Fine with me.

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 21 Nov 2011 09:09:31 -0800

> validating resolver, you cannot really use RFC4033 states here.

Yes we can; we just leave how it gets at them unspecified.

I do not think we should mention RCODEs or the DNSSEC enable bits _at
all_.  Please see my other message.

zw

---

From: Ondřej Surý <[email-masked]>
Date: Mon, 21 Nov 2011 19:22:57 +0100

I have re-read the RFC403[345] again and I take back my email.

The validating resolver has a way how to communicate the secure and bogus states:

   This specification only defines how security-aware name servers can
   signal non-validating stub resolvers that data was found to be bogus
   (using RCODE=2, "Server Failure"; see [RFC4035]).

   There is a mechanism for security-aware name servers to signal
   security-aware stub resolvers that data was found to be secure (using
   the AD bit; see [RFC4035]).

(Note: And this can be updated by further RFCs, so we should not really
divert from this.)

So what about this wording:

-- cut here --
Determining whether a TLS certificate association can be used depends
on the DNSSEC validation state (as defined in [RFC4033] Section 5).

DANE-aware application MUST implement at least security-aware stub
resolver (as defined in [RFC4033] Section 2).

o A DNS response for TLSA RRset query whose state is Secure
  can be used for further DANE processing.  If the TLSA RRset
  exists it can be used for TLS.

o A DNS response for TLSA RRset query whose state is Bogus
  cause TLS not to be started or, if the TLS negotiation is
  already in progress, to cause the connection to be aborted.

o A DNS response for TLSA RRset query whose state is not Secure
  or Bogus cannot be used for TLS and must be marked as unusable.
-- cut here --

(Note: I am avoiding the Insecure or Indeterminate to create catch-all
rule which will match also all other RCODEs which can be returned
by the (validating) resolver.)

O.