Subject: [dane] Aiming towards some specific wording

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Nov 2011 08:10:08 +0800

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 cannot be used for TLS and must be marked as unusable.

========== 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 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 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 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: Zack Weinberg <[email-masked]>
Date: Fri, 18 Nov 2011 17:08:03 -0800

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

I think the terminology that is currently being used for this stuff 
("association", "mark as (un)usable", "can(not) use for TLS" is 
confusing and needs to be replaced wholesale.  However, that is an 
editorial issue that can be addressed separately from this wording change.

Now, my understanding of the debate is that everyone agrees that the 
"bogus" DNSSEC state needs to cause a TLS connection abort, but the 
"indeterminate" and "insecure" DNSSEC states _at worst_ need to cause 
TLSA records to be ignored.  The argument, as I understand it, is just 
over whether _all_ TLSA records need to be ignored when DNSSEC comes 
back "indeterminate" or "insecure".

Therefore,

>     secure can be used for TLS.

this is fine (except for the terminology caveat above), but

 >     indeterminate cannot be used for TLS and must be marked as

at least one of these sentences is wrong; as written, either both 
validation states cause a connection abort, or neither do.  If it is the 
second sentence that is wrong, both Continuation 1 and 2 need to change.

Also, the new text needs to explicitly cover DNSSEC validation state 
"insecure", which is presently not mentioned.  I don't know any reason 
to treat it differently from "indeterminate"; it just needs to be 
mentioned as a possibility.

Other than that, the proposed alternatives cover all of the sides of the 
debate as far as I can tell.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 19 Nov 2011 18:46:22 +0800

On Nov 19, 2011, at 9:08 AM, Zack Weinberg wrote:

> Now, my understanding of the debate is that everyone agrees that the "bogus" DNSSEC state needs to cause a TLS connection abort,

That was not my understanding from the earlier thread, but you could be right. Why would a DNS lookup for the TLSA record cause a TLS connection abort? First, it is unrelated to TLS it self if the data from TLSA is not used. Second, there may be other valid records returned, so aborting instead of just throwing away the bad data will lead to lack of secure connections when secure connections were possible. Third, that rule seem nonsensical in light of the fact that there is no parallel rule for a bogus response on the A record lookup.

Can someone who supports "bogus response on TLSA lookup" explain why it should be more than "throw away the data from that record", particularly in light of the last point?

> but the "indeterminate" and "insecure" DNSSEC states _at worst_ need to cause TLSA records to be ignored.  The argument, as I understand it, is just over whether _all_ TLSA records need to be ignored when DNSSEC comes back "indeterminate" or "insecure".

That was my impression.

> at least one of these sentences is wrong; as written, either both validation states cause a connection abort, or neither do.  If it is the second sentence that is wrong, both Continuation 1 and 2 need to change.

There is nothing about "abort" in either of those two sentences, so "neither do" is correct. There is no assumption that a connection has been started. There is an assumption that there might be additional TLSA records that can be used even if the bogus record is unusable.

> Also, the new text needs to explicitly cover DNSSEC validation state "insecure", which is presently not mentioned.  I don't know any reason to treat it differently from "indeterminate"; it just needs to be mentioned as a possibility.

I purposely elft out insecure because the DNS root is now signed, but since this morning, I have thought of cases where one might get "insecure" due to local policy. I will change "indeterminate" to "indeterminate or insecure" everywhere.

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2011 12:58:08 +0200

> Can someone who supports "bogus response on TLSA lookup" explain why it should be more than "throw away the data from that record", particularly in light of the last point?

I am not in that camp, but since we are requiring TLSA to be secure, but not requiring this (for now) for A records, it makes no sense for an attacker to forge a signature on the A record: you will accept it unsigned anyway. A successfully forged TLSA record is the difference between getting a warning screen for your invalid certificate, and not getting such a warning screen.

If there is not difference in behavior between a missing TLSA record and a bogus TLSA record, there is no deterrent for the attacker to try to send it.  OTOH, if the attacker cannot modify A records but can inject TLSA records, this would be a convenient way to DoS the server - just inject a bogus record, and that is why I am *not* in that camp.

Yoav

---

From: Jakob Schlyter <[email-masked]>
Date: Sat, 19 Nov 2011 19:10:50 +0100

On 19 nov 2011, at 11:58, Yoav Nir wrote:

> I am not in that camp, but since we are requiring TLSA to be secure, but not requiring this (for now) for A records, it makes no sense for an attacker to forge a signature on the A record: you will accept it unsigned anyway.

One should remember that most (if not, all) DNSSEC resolver will never return bogus answers. If one tries to forge or strip a signature from a record that is supposed to be signed, resolving will fail and nothing is returned.

	jakob

---

From: Yoav Nir <[email-masked]>
Date: Sat, 19 Nov 2011 20:27:21 +0200

> One should remember that most (if not, all) DNSSEC resolver will never return bogus answers. If one tries to forge or strip a signature from a record that is supposed to be signed, resolving will f…

All the more reason to +1 what Warren said.

Validated DNSSEC or if didn't happen.

---

From: Zack Weinberg <[email-masked]>
Date: Sat, 19 Nov 2011 10:38:56 -0800

On 2011-11-19 10:10 AM, Jakob Schlyter wrote:
> One should remember that most (if not, all) DNSSEC resolver will
> never return bogus answers. If one tries to forge or strip a
> signature from a record that is supposed to be signed, resolving will
> fail and nothing is returned.

Because of the attack I described in my message to Paul just now, I 
think it is not possible to securely process TLSA information if you 
cannot distinguish validation state "bogus" from state "indeterminate" 
or from a server failure.  In other words, such resolvers are inadequate 
to the needs of a DANE client.  (I have long thought that it would be 
necessary for a DANE client to do its own DNSSEC processing; this does 
not seem like a major problem to me.)

zw

---

From: Mark Andrews <[email-masked]>
Date: Sun, 20 Nov 2011 11:04:19 +1100

In message <[email-masked]>, Jakob Schlyter writ
es:
> > I am not in that camp, but since we are requiring TLSA to be secure, but no
> t requiring this (for now) for A records, it makes no sense for an attacker t
> o forge a signature on the A record: you will accept it unsigned anyway.
> 
> One should remember that most (if not, all) DNSSEC resolver will never return
>  bogus answers. If one tries to forge or strip a signature from a record that
>  is supposed to be signed, resolving will fail and nothing is returned.
> 
> 	jakob

But once the application starts doing DNSSEC for itself it will be asking
with CD=1 at some point.

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Matt McCutchen <[email-masked]>
Date: Sat, 19 Nov 2011 21:49:08 -0800

On Sat, 2011-11-19 at 18:46 +0800, Paul Hoffman wrote:
> "bogus" DNSSEC state needs to cause a TLS connection abort,
> 
> That was not my understanding from the earlier thread, but you could
> be right. Why would [a bogus state on] a DNS lookup for the TLSA
> record cause a TLS connection abort?

Because that's the only way for restrictive TLSA data to be effective.
If the client proceeds without using DANE in this case, then an MITM
attacker who has fraudulently obtained a PKIX-acceptable certificate for
the target server name can trivially deceive the client by replacing the
TLSA response with a bogus response.

-- 
Matt

---

From: Jakob Schlyter <[email-masked]>
Date: Sun, 20 Nov 2011 09:40:20 +0100

> TLSA response with a bogus response.

Spot on - bogus must result in connection termination, while insecure and indeterminate may safely be ignored. 

   Jakob

---

From: Warren Kumari <[email-masked]>
Date: Sun, 20 Nov 2011 09:17:10 -0500

> Spot on - bogus must result in connection termination, while insecure and indeterminate may safely be ignored. 

<no hat>
+1
</no hat>

---

From: Zack Weinberg <[email-masked]>
Date: Sun, 20 Nov 2011 08:22:11 -0800

(I sent this from the wrong address so it may not have gotten through.
 Sorry if you get two copies.)

On 2011-11-19 2:46 AM, Paul Hoffman wrote:
>> Now, my understanding of the debate is that everyone agrees that
>> the "bogus" DNSSEC state needs to cause a TLS connection abort,
>
> be right. Why would a DNS lookup for the TLSA record cause a TLS
> connection abort?

If you get a "bogus" DNSSEC validation you *know* you are under attack.
 It seems absurd to me to proceed with a connection when you know that.

Here is an attack that can only be thwarted by this rule: Suppose the
standard man-in-the-middle attacker on TLS, in possession of an
illegitimate certificate for the site being MITMed, that would
nonetheless be accepted by the client in the absence of DANE
information.  Suppose further that this attacker is able to block entire
DNS queries but not tamper with their contents.  They allow the A record
query to go through and come back unmolested (they don't need to change
the apparent address of the server to intercept traffic) but they block
the TLSA query.  This absence of response is DNSSEC-"bogus", because you
didn't get an NSEC(3) to prove that there is no such record.  If you
abort the connection, the attacker loses.  If you fall back to non-DANE
behavior, the attacker wins.

(If the attacker can rewrite DNS responses, they can downgrade you to an
absence of DNSSEC all the way to the root, which may or may not be
distinguishable from an innocuous availability failure -- I'd *like* to
be able to say fail connections in that case, now that the root is
signed, but it seems unlikely to fly..)

> First, it is unrelated to TLS it self if the data from TLSA is not
> used.

I do not understand this sentence.

> Second, there may be other valid records returned, so aborting
> instead of just throwing away the bad data will lead to lack of
> secure connections when secure connections were possible.

I cannot think of any scenario where this would be both true and
distinguishable from the attack scenario above.  Can you?

> Third, that rule seem nonsensical in light of the fact that there is
> no parallel rule for a bogus response on the A record lookup.

Actually, I think there *should* be a parallel rule for a bogus response
on the A(AAA) record lookup.  It may not belong in DANE, but it seems
like it belongs in a "how to make use of DNSSEC in a network client"
best-practices document, at least.

> There is no assumption that a connection
> has been started.

If you're processing TLSA records and it's *not* because you need to
decide whether a TLS connection is properly authenticated, that seems
out of scope for the document we're trying to write right now.

> There is an assumption that there might be
> additional TLSA records that can be used even if the bogus record is
> unusable.

Hm, I had not thought of this possibility.  It seems like a silly
thing for an attacker to do (any attacker who can inject a TLSA record
can also remove all the legitimate ones, and why wouldn't they?) and I
would argue that *any* bogosity coming back from DNSSEC is evidence
that there is an attacker doing *something* and it is not safe to
proceed.

> I purposely elft out insecure because the DNS root is now signed,
> but since this morning, I have thought of cases where one might get
> "insecure" due to local policy. I will change "indeterminate" to
> "indeterminate or insecure" everywhere.

Ok.  It is probably worth describing those scenarios in the security
considerations section, and mentioning that localities whose policies
do *not* interfere may want to treat "insecure" the same as "bogus".

zw

---

From: Peter Koch <[email-masked]>
Date: Sun, 20 Nov 2011 17:35:57 +0100

>    secure can be used for TLS.

I believe that s/TLS certificate association/TLSA RRSet/ would be
more to the point and more precise protocol specification language.
"can be used" remains ambiguous, though.

-Peter

---

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

> more to the point and more precise protocol specification language.

The term "certificate association" is defined and used in this document.

> "can be used" remains ambiguous, though.

An implementation is not forced to use good DANE information even if it comes validated. For example, there might be a local policy that says "even if you get DANE information about somebigbank.com, ignore it and use this hard-coded information instead".

--Paul Hoffman

---

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

> But once the application starts doing DNSSEC for itself it will be asking

The DANE spec does not assume that the application does DNSSEC itself, so we should cover both that case and the case of the application asking a trusted validator for information.

--Paul Hoffman

---

From: Danny McPherson <[email-masked]>
Date: Sun, 20 Nov 2011 17:21:10 -0500

>> Spot on - bogus must result in connection termination, while insecure and indeterminate may safely be ignored. 

I have some concerns about this..  

We'e seen instances with _already deployed DNSSEC root and TLD 
zones where signatures could not be updated because nodes were 
partitioned from the systems which update them -- this can happen because
of intentional or benign reasons.   If there were RPs that were performing 
validation expired data would result in validation state "bogus".  

IMO, this begs the question -- if we're even remotely considering supporting
DANE-esque functions for any state other than valid (Secure), to include  
non-DNSSEC support, then why not address this issue as well, rather than 
letting practical realities potentially result in non-determinsitic behaviors?

-danny

---

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

> validation expired data would result in validation state "bogus".  

In that case ("bogus means poorly maintained zone"), the A/AAAA record would come back bogus. An application that is rejecting bogus responses would already stop on that error because it would have no place to go.

> letting practical realities potentially result in non-determinsitic behaviors?

If you actually believe that an application that requests both A/AAAA and TLSA records from a poorly maintained zone might get the first marked valid but the second marked bogus, I will add two options for the wording of the preamble, and the WG can decide between the two of them. However, if you don't think this is at all likely, I think the new wording ("bogus leads to no connection attempt or abort") is sufficient.

--Paul Hoffman

---

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

> One should remember that most (if not, all) DNSSEC resolver will never return bogus answers. If one tries to forge or strip a signature from a record that is supposed to be signed, resolving will f…

Jakob,

you can look at the RCODE in the DNS response and if you see SERVFAIL you can abort the TLS connection.

And my view is that the DANE aware client should look at the RCODE and "throw away" only if the RCODE is NOERROR or NXDOMAIN.

O.
--
 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: Olafur Gudmundsson <[email-masked]>
Date: Mon, 21 Nov 2011 10:51:47 -0500

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

I think better wording is: (based on Warrens message from his flight, 
and my reading of the feelings on the mailing list and conversations 
with participants).

------
A TLS certificate association can only be used if DNSSEC validation 
state is secure.
------

or
-----
Only when DNSSEC validation returns a validated answer[RFC4033] can a 
TLSA RRset be used by a DANE client.
-----

What that means is that bogus, proof-ably insecure, undetermined etc. 
are all outside the scope of this document.

If "DNSSEC validated only" is the scope of the document then none of the 
proposed texts below below are needed.

	Olafur

---

From: Peter Koch <[email-masked]>
Date: Mon, 21 Nov 2011 16:35:28 +0100

> The term "certificate association" is defined and used in this document.

my suggestion was made in full recognition of section 1.1 of the document.

> An implementation is not forced to use good DANE information even if it comes validated. For example, there might be a local policy that says "even if you get DANE information about somebigbank.com…

Local policy almost always trumps the protocol spec. So, "can" is unclear
as it could be simply descriptive or half way into a "MAY" or even "SHOULD".
What's the intent here?  Same for "use": is that "usage" as per section 2.1.1?

-Peter

---

From: Zack Weinberg <[email-masked]>
Date: Mon, 21 Nov 2011 08:57:40 -0800

On Mon, Nov 21, 2011 at 7:51 AM, Olafur Gudmundsson <[email-masked]> wrote:
> What that means is that bogus, proof-ably insecure, undetermined etc. are
> all outside the scope of this document.

This is not acceptable to me.  Most importantly, the behavior for
"bogus" _must_ be specified in the initial protocol document, or we
will be leaving security holes in a security mechanism.  And I do not
think there is any good reason to avoid specifying behavior for all
four DNSSEC validation states.

The appropriate thing to put out of scope is the case where the client
is _incapable_ of accessing DNSSEC validation states - not because of
its network conditions, but because it hasn't got the code.

zw

---

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

> And my view is that the DANE aware client should look at the RCODE and "throw away" only if the RCODE is NOERROR or NXDOMAIN.

I think it would be better to specify client consumption of DNSSEC in
terms of RFC 4033 validation states than RCODEs.  The validation
states have precise meanings and it is easy to reason about their
security consequences.  The RCODEs have broad and fuzzily specified
meanings, and are partially tied to specific implementation behavior.
It is not obvious to me, for instance, that a connection abort is
appropriate for _all_ possible circumstances that lead to SERVFAIL,
whereas IMO it _is_ for RFC4033 "bogus" state.

IMO we should say that the client MUST be able to determine the DNSSEC
validation state for each RRset, but leave _how_ it does that
unspecified.  If a client can reliably infer validation state from the
RCODEs produced by its local trusted resolver, that's fine.

zw

---

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

> What's the intent here?  Same for "use": is that "usage" as per section 2.1.1?

I'm going to stick in another plea here that we address the confusing
"can be used" / "mark as usable" / "association" terminology
_throughout the document_ and in a separate conversation.  This
conversation is already messy enough.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Nov 2011 09:40:16 -0800

> And my view is that the DANE aware client should look at the RCODE and "throw away" only if the RCODE is NOERROR or NXDOMAIN.

This requires an API that returns an RCODE. Different APIs so far have returned different things.

On Nov 21, 2011, at 7:50 AM, Ondřej Surý wrote:

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

An API to a validating DNSSEC resolver *can* return the RFC 4033 state; some of them already do, so saying that "you cannot really use" them is wrong. You may have a preference for giving the logic based on RCODEs, but others seem to prefer that we use RFC 4033 language.

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

That's not true: it can also see RFC 4033 state. It is up to this WG to say what we require from the DNSSEC API.

> 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

To be blunt, I don't see anywhere in our charter that says that this WG is supposed to do the RCODE-to-4033-state mapping and thus update RFC 4033 and 4035. One would expect that such a mapping would have come from the DNSEXT WG, yes?

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

That proposed wording is a valid alternative, but only if we know what the mappings are. I suggest that we do not, and that we are going down a rat hole by assuming that this WG is supposed to update RFCs 4033 and 4035.

--Paul Hoffman

---

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

> This requires an API that returns an RCODE. Different APIs so far have returned different things.

We will need such API anyway if you are going to implement security-aware (stub) resolver.

> An API to a validating DNSSEC resolver *can* return the RFC 4033 state; some of them already do, so saying that "you cannot really use" them is wrong.

Right, I was wrong.

> You may have a preference for giving the logic based on RCODEs, but others seem to prefer that we use RFC 4033 language.

The "validating resolver" => "security-aware stub resolver" API uses RCODE=2 (Bogus) and +AD flag (Secure).

> That's not true: it can also see RFC 4033 state. It is up to this WG to say what we require from the DNSSEC API.

We need at least security-aware stub resolver.  We can ask for:

1. non-validating security-aware stub resolver (+DO)
2. validating security-aware stub resolver (+DO +CD)

> To be blunt, I don't see anywhere in our charter that says that this WG is supposed to do the RCODE-to-4033-state mapping and thus update RFC 4033 and 4035. One would expect that such a mapping wou…

True, disregard what I wrote there.

O.

---

From: Mark Andrews <[email-masked]>
Date: Tue, 22 Nov 2011 08:13:12 +1100

The only difference between "insecure" and "indeterminate" is that
there was a TA configured somewhere above the name and there is a
insecure delegation between that TA and data.   We don't actually
prove that something is insecure.  We prove that there is not a
secure path to the data. 

If you don't have a TA you do not have a secure path to the data.
If you have a TA but a insecure delegation you do not have a secure
path to the data.  In both case the data could be signed or unsigned.

"insecure" and "indeterminate" zones are logically the same.  Dane
should just treat them as !secure.

Dnsext should fix the DNSSEC RFC's to get rid of one or other of them
as having two terms for the same thing is pointless.

Reply-to set to [email-masked]

Mark

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 21 Nov 2011 13:28:57 -0800

> should just treat them as !secure.

I can't tell if you are just commenting or are about to suggest different wording for the proposal. I believe the current wording treats them the same, and the current wording treats them as not secure.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 21 Nov 2011 20:10:16 -0800

On Mon, 2011-11-21 at 16:28 -0500, Edward Lewis wrote:
> Answering only to DNSEXT...
> 
> > At 8:13 +1100 11/22/11, Mark Andrews wrote:
> No, they are not the same.
> 
> Insecure means I get records indicating there's no possible trust
> chain that can be constructed from the data to anything I have.
> 
> Indeterminate means when I try to get records for part of the chain I
> "time-out".  ("No servers could be reached.")
> 
> There's a significant semantic difference between the two.  Apart from
> the fact that you won't succeed in constructing a chain, "insecure"
> means it is definitively impossible and "indeterminate" means "not
> with the data at hand, at this time."  The former would be data that
> is not protected, the latter could be declared a service failure.
> 
> Here's the definition in RFC 4035 I'm pointing to:
> 
> 4.3.  Determining Security Status of Data
> ...
>    Indeterminate: An RRset for which the resolver is not able to
>       determine whether the RRset should be signed, as the resolver is
>       not able to obtain the necessary DNSSEC RRs.  This can occur
> when
>       the security-aware resolver is not able to contact
> security-aware
>       name servers for the relevant zones.

That's great, RFC 4035 has a totally different definition of
"indeterminate" than RFC 4033.

RFC 4033 "indeterminate" is equivalent to "insecure" for DANE's purpose
and likely other purposes as well.  RFC 4035 "indeterminate" is not a
separate group of cases; those cases are better described as "SERVFAIL",
or possibly "bogus" if the resolver successfully retrieves the target
RRset (but not the DNSSEC RRs).

Ultimately, DANE needs three cases:

1. Secure: Process the RRset.
2. Insecure or RFC 4033 indeterminate: Fall back to pre-DANE behavior,
or (maybe -- under discussion) process the restrictive part of the
assertion without the additive part.
3. Bogus or query failed (RCODE other than NOERROR or NXDOMAIN, no
response from DNS servers, etc.): Fail closed.

-- 
Matt

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Nov 2011 09:46:46 -0500

> will be leaving security holes in a security mechanism.  And I do not

What is the hole in what Olafur proposed?  "MUST be DNSSEC
validatable" entails "MUST NOT use the record when it cannot be
validated".  There are only two relevant states under that
formulation: validatable and everything else.  "Bogus" is in the
"everything else" category.  Under this suggestion, it's exactly as
unusable as TLSA that is not secured.  I don't see where the hole.

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 22 Nov 2011 10:14:47 -0500

> unusable as TLSA that is not secured.  I don't see where the hole.

I think people want to use both positive and negative DNSSEC state (secure and bogus).  If secure, then you get additional assurance.  If bogus, then something's gone wrong and you need to fail.  

Your/Olafur's suggestion covers the secure case, but lumps bogus in with  insecure/indeterminate.  Do you think that there's a reason to ignore the negative/bogus case?

--Ricahrd

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Nov 2011 08:10:05 -0800

> Your/Olafur's suggestion covers the secure case, but lumps bogus in with  insecure/indeterminate.  Do you think that there's a reason to ignore the negative/bogus case?

Which part of the "please don't voice an opinion yet" are you forgetting? :-)

I am hearing a desire that we split out the processing of "bogus". Some folks want it to cause TLS termination, others want it just to not count as anything. I have added this to the list of choices.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Nov 2011 15:35:21 -0500

> I think people want to use both positive and negative DNSSEC state (secure and bogus).  If secure, then you get additional assurance.  If bogus, then something's gone wrong and you need to fail.  

And then what do you do if indeterminate &c?  I don't understand how
that isn't "still fail", which is I think what Olafur was saying.

> Your/Olafur's suggestion covers the secure case, but lumps bogus in with  insecure/indeterminate.  Do you think that there's a reason to ignore the negative/bogus case?

I don't know.  I don't know what _else_ you're going to do except not
proceed when you can't validate the answer.  (Note that this is different from the general DNS case: we're explicitly trying to use this to bootstrap TLS, so if you're not able to validate that the TLSA RR you got is legit, it seems to me to be a bad idea to keep going.)

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Tue, 22 Nov 2011 19:55:44 -0500

> that isn't "still fail", which is I think what Olafur was saying.

Going back to Olafur's original email:
"The consumer application falls back to the processing it is currently doing"

So the three behaviors would be:
1. Certificate passes validation (secure && match) 
   => Proceed with connection, any other certificate checks
2. Certificate fails validation (bogus || (secure && !match))
   => Fail connection
3. Validation provides no information
   => Decide based on other processing (as you would if DANE didn't exist)

> proceed when you can't validate the answer.  (Note that this is different from the general DNS case: we're explicitly trying to use this to bootstrap TLS, so if you're not able to validate that the…

I think that that's probably too strong, and would cause problems with incremental deployment.  But I may still be under the influence of jet lag from TPE.

--Richard

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Nov 2011 22:02:27 -0500

>    => Decide based on other processing (as you would if DANE didn't exist)

I think I get it.  The idea is that the bigus state (or the validated
non-matching state) is positive evidence _not_ to proceed, but "no
information" doesn't do that.

I think I can construct an argument why that isn't wrong, although the
slightly dodgy part is going to be explaining why (2) doesn't also
lead to "fallback" (I believe I can construct such an argument, it
just seems the weakest part to me).  So I can see why this option is
still on the table.

Thanks!

A

-- 
Andrew Sullivan
[email-masked]

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 22 Nov 2011 19:36:43 -0800

> just seems the weakest part to me).  So I can see why this option is

There are concrete attacks that would be possible if (2) led to
fallback rather than a connection abort.

For instance, quoting my earlier message to Paul H: Suppose the
standard man-in-the-middle attacker on TLS, in possession of an
illegitimate certificate for the site being MITMed, that would
nonetheless be accepted by the client in the absence of DANE
information.  Suppose further that this attacker is able to block
entire DNS queries but not tamper with their contents.  They allow the
A record query to go through and come back unmolested (they don't need
to change the apparent address of the server to intercept traffic) but
they block the TLSA query.  This absence of response is
DNSSEC-"bogus", because you didn't get an NSEC(3) to prove that there
are no TLSA records.  If you abort the connection, the attacker loses.
 If you fall back to non-DANE behavior, the attacker wins.

zw

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 22 Nov 2011 23:07:53 -0500

On Sun, Nov 20, 2011 at 08:22:11AM -0800, Zack Weinberg wrote:

> absence of DNSSEC all the way to the root

No, they can't.  You will fail the . validation at the last step, and
everything is bogus.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 22 Nov 2011 20:18:39 -0800

> No, they can't.  You will fail the . validation at the last step, and

I guess I'm assuming that a DNSSEC-validating client that sees a
complete absence of DNSSEC records in the responses it gets with +AD
is going to assume a "harmless" failure of some middlebox to pass the
records, and fall back to non-validating behavior, rather than treat
everything as bogus.

Behaving like that does open a large avenue for exploits that I hope
can be closed as soon as possible, but I suspect "as soon as possible"
is not for at least a few years...

zw

---

From: Martin Rex <[email-masked]>
Date: Wed, 23 Nov 2011 05:34:13 +0100 (MET)

Zack Weinberg wrote:
> > I think I get it. Â The idea is that the bigus state (or the validated
> > just seems the weakest part to me). Â So I can see why this option is
> > still on the table.
> 

I think we're running in circles again.

I believe it is wrong to focus on some specific attack scenarios.

We are adding a new optional feature to an installed base, and
there will be trade-offs where the additional security can not
be reliably provided.  That does not mean that there is a new
vulnerability, just that there is _no_new_protection_.

In the ultimate final scenario, the server will be conveying
fresh stapled OCSP responses and the entire set of DNS(SEC) records
inline in the TLS handshake through a TLS extension, the client
*knows* that it will receive such data from the real server and
will abort if it does not get it.

For the time of the migration, much can be gained by
cert pinning -- a concept that has been proven as successful
through millions of years of revolution: keeping memories of
previous encounters to better recognize imposters on future
encounters.

I don't think it is useful to define DANE validation in a fashion
that it could be easily abused for "casting doubt".  That could
enable an attacker to spoof one single TLSA record into an ISPs
recursive DNS resolver for a zone that does not use DNSSEC
and make the access to that business fail for *ALL* customers
of that ISP for several hours.

Personally, I believe one should restrict the ability to
make a PKIX-validating certificate look "fishy" to the server&DNS admin.
If they put wrong info into DNS, the resulting "loss of business"
is their responsibility, they should be able to see and repro the
problem and be able to fix it.

Connectivity problems newly created by unforgiving DANE clients
that are caused by non-malicious middle boxes (or ocassionally attackers)
is hard to impossible to see and repro for the server&DNS admin,
and usually quite impossible to fix for them.

-Martin

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 23 Nov 2011 11:24:21 -0500

On 22/11/2011 23:18, Zack Weinberg wrote:
> On Tue, Nov 22, 2011 at 8:07 PM, Andrew Sullivan<[email-masked]>  wrote:

Zack
Sorry this is hard to parse.

Middle box not letting DNSSEC records though is not a "harmless" failure 
in my book, it is a total failure to use DANE.

What do you mean by "DNSSEC-validating client"?
	an application that is doing its own validation
or	an application that trusts a certain validator
or 	an application that blindly trust any resolver.

In the first case it will ignore the AD bit and fail due to lack of 
DNSSEC RRSIG records
In the second case it would not use the DNSSEC RRSIG's thus their 
absence is immaterial.
The third case is not a recommended practice see RFC3655, in
particular section 4.

On my laptop I use local validating resolver that does uses local 
resolvers when it can, but still validates all answers. [1]

> is not for at least a few years...

See above, what possible exploits remain in case 2 above with secure 
channel to the validating resolver?
DNS is vulnerable to DoS attacks see RFC3833,
	DNSSEC protects you from accepting bogus information
	DNSSEC does not guarantee that you get the good information.

hope this helps

	Olafur

PS: Sorry to be pedantic but if we are not talking the same language we 
will talk past each other.

[1] DNSSEC Trigger  http://www.nlnetlabs.nl/projects/dnssec-trigger/ 
will also try to work around broken middle boxes by using alternate ways 
to talk to remote "trusted resolvers".

---

From: Eric Osterweil <[email-masked]>
Date: Mon, 28 Nov 2011 12:14:28 -0500

> Zack Weinberg wrote:

<snip>

> vulnerability, just that there is _no_new_protection_.

Adding a new security approach should require us to describe the attack surface one has when using it, no?  Using specific attack scenarios to illustrate a weakness is actually important because it evolves a concern from speculation to a demonstrable weakness.

> will abort if it does not get it.

Whoa... I strongly disagree with this.  I wonder who exactly considers this the "ultimate final scenario?"  I think this approach is very dangerous from an architectural perspective (as I mentioned on the list before and during ietf 81).  Among other things, it opens a new attack vector based on _operational_ inevitabilities.

> previous encounters to better recognize imposters on future

Sooo... When a creature vets something that it thinks is pedestrian, but turns out to be a camouflaged predator, how did those memories help?  I think this is a very strained analogy. 

> of that ISP for several hours.

Here I agree.  I think we need to be more careful if we go down this path.

> problem and be able to fix it.

I would mostly agree with this.  My thought would be that if we are going to start codifying an evidence-based security approach here, we should try to capture a more quantifiable notion of how RPs make judgements.  A simple spoofed DNS packet that causes an RP to fail sounds a little dangerous, but perhaps there's more that I'm missing, or more that could be done?

Eric