Subject: [dane] no security benefit from insecure or indeterminate domains

From: Christian Becker <[email-masked]>
Date: Fri, 09 Nov 2012 20:18:45 +0100

Hi,

I am confused by the last paragraph of 4.1 in RFC6698. To my
understanding in the case of a "domain is insecure or indeterminate"
there is no security benefit compared to TLS processed in the normal
fashion. Thus, also in this case the application "SHOULD NOT make any
internal or external indication that TLSA was applied."

Referred paragraph:
"Thus, in order to achieve
any security benefit from certificate usage 0 or 1, an application
that sends a request for TLSA records needs to get either a valid
signed response containing TLSA records or verification that the
domain is insecure or indeterminate. If a request for a TLSA record
does not meet one of those two criteria but the application continues
with the TLS handshake anyway, the application has gotten no benefit
from TLSA and SHOULD NOT make any internal or external indication
that TLSA was applied."

Christian

---

From: Paul Wouters <[email-masked]>
Date: Fri, 9 Nov 2012 19:11:12 -0500 (EST)

On Fri, 9 Nov 2012, Christian Becker wrote:

> Date: Fri, 9 Nov 2012 14:18:45
> From: Christian Becker <[email-masked]>
> To: [email-masked]
> Subject: [dane] no security benefit from insecure or indeterminate domains
> 
> Hi,
>

Well, for "indeterminate", you know that the DNS was very broken, or
possibly tampered with, and prevented receiving positive or negative
prove from DNS/TLSA.

To me, the actions to perform for "insecure" versus "indeterminate" are
quite different.

Paul

---

From: Christian Becker <[email-masked]>
Date: Sat, 10 Nov 2012 09:04:03 +0100

> To me, the actions to perform for "insecure" versus "indeterminate" are

I agree, this should be a difference, but

1.) as stated above, the RFC6698 handles these two cases together

probably for the reason that

2.) also RFC4033 says in paragraph 5 that "The current signaling
mechanism does not distinguish between indeterminate and insecure states."

That is why to my understanding it is one case "insecure or
indeterminate" and should be handled as the worst case, namely the data
could have been tampered and therefor the application "SHOULD NOT make
any internal or external indication that TLSA was applied."

Christian

---

From: Paul Wouters <[email-masked]>
Date: Sat, 10 Nov 2012 13:18:39 -0500 (EST)

> any internal or external indication that TLSA was applied."

If you are under attack (possible when in indeterminate) I would hope
the user gets to see more then the lack of a security identifier.

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Nov 2012 14:01:04 +0000

> possibly tampered with, and prevented receiving positive or negative

No, indeterminate just means you have no trust anchors. Broken/tampered is
bogus.

> To me, the actions to perform for "insecure" versus "indeterminate" are

To me they are equivalent from an app's point of view.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: Paul Wouters <[email-masked]>
Date: Wed, 14 Nov 2012 11:23:46 -0500 (EST)

> No, indeterminate just means you have no trust anchors. Broken/tampered is

If you ask with DO bit, and get no answer packet whatsoever, that is
indeterminate, but not bogus.

> To me they are equivalent from an app's point of view.

proven insecure is a lot different from "could be under attack"

Paul

---

From: Tony Finch <[email-masked]>
Date: Wed, 14 Nov 2012 16:38:44 +0000

> indeterminate, but not bogus.

Oh this is the 4033 / 4035 inconsistency again.

I think the "indeterminate" status is useless. It's operationally
equivalent to either insecure or to bogus.

Tony.