Subject: [dane] Call for consensus on level of DNSSEC support (Security-aware Stub Resolver in DANE-aware application)

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 17:59:43 +0100

Hi all,

I would like to set the working group into the motion again.
I will use the RFC4033 language (Section 2 and Section 5),
so please read that before you comment.

Let's assume that the DANE-aware application is using trusted
Validating Security-Aware Recursive Name Server.

How is that achieved is out-of-the-scope for this email (and
for the DANE protocol draft).

It seems to me that from the 'Aiming towards...' thread,
we still have a misunderstanding what should DANE-aware
application do or not do.

In particular, the call for consensus is that DANE-aware
application has to implement (at least) Non-validating
Security-aware Stub Resolver.  As we (Warren) said earlier
there were some concerns in the IESG and we have the DNSSEC
in the charter, so we have to use only Secure TLSA possitive
answers.  Also we cannot ignore the Bogus state, because
then the restrictive option (Usage type 0/1) would be vulnerable
to stripping in-path attack.

Implications:
- DANE-aware client distinguishes three DNSSEC states of the data on the input:
 + TLSA Resource Record Exists and is Secure (RFC4033 Section 5)
   (AD bit set)
 + DNS Response is Bogus
   (RCODE=SERVFAIL)
 + Everything else (catch-all rule)
- When processing it becomes:
 + TLSA Resource Record Exists
  + TLSA Resource Record Matches       => OK
  + TLSA Resource Record Doesn't Match => FAIL
 + DNS Response is Bogus               => FAIL
 + Everything else (catch-all rule)    => NO-INFO (Fallback to PKIX)
- It's harder to implement, because there is not common API for that yet.

I think we already had a quite intensive discussion on this topic,
so please only express your opinion (+1 vs. -1)

Thank you,
--
 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: Zack Weinberg <[email-masked]>
Date: Wed, 30 Nov 2011 09:04:03 -0800

>  + TLSA Resource Record Exists and is Secure (RFC4033 Section 5)

-1 on mentioning AD or RCODE, +1 on everything else.  Just delete the
parentheticals.

>  + Everything else (catch-all rule)    => NO-INFO (Fallback to PKIX)

+1

zw

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Nov 2011 09:07:22 -0800

With all due respect, your choices below do not reflect all the choices that people asked to be able to choose between. Worse, you do not propose specific wording that will help your humble document authors.

Instead of the current poll you started, would you instead accept one that is based on the choices that people asked for on the earlier thread?

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 19:15:36 +0100

On 30. 11. 2011, at 18:04, Zack Weinberg wrote:

> -1 on mentioning AD or RCODE

This merely reflects RFC4033 - but note taken.  It could be removed without any harm.

> , +1 on everything else.  Just delete the
> parentheticals.
>

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Nov 2011 13:36:16 -0500

So, that's a "-1"?

On Nov 30, 2011, at 12:07 PM, Paul Hoffman wrote:

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

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Nov 2011 13:36:50 -0500

+1 to what Zack said.
--Richard

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 20:56:14 +0100

To clarify our intention here...

We reflect what was said in earlier threads and that there were more
choices how to interpret DNSSEC states and how to react.  We (the chairs)
have noted that there was also strong support to not complicate things
and keep the issue codenamed as "DNSSEC-optional" out of the protocol
document.  We have also noted that there was some differences on how
to handle the Bogus response, but we also feel that there was stronger
support for handling it as hard failure.

So if any of you feel that you don't like the one choice I have presented
and asked for support, please do vote "-1" and we can continue to vote for
more complicated scenarios or split up this one scenario into more atomic
choices.

But I would really like to:
a) keep things moving
b) not start running in circles again
c) go to a)

We also talked with Paul off-list and we are working on finishing the specific
wording into the draft which will reflect my Call for Consensus.  If you would
feel more comfortable by waiting for the exact wording, please wait before you
vote, I hope to have the exact wording finished before end of Friday.

Ondrej

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Nov 2011 15:01:55 -0500

>  + Everything else (catch-all rule)    => NO-INFO (Fallback to PKIX)

I don't think I understand the question.  Under the "When processing",
does "Matches" means "has AD bit set?" (and conversely, doesn't
match/SERVFAIL)?

There are three possible answer-states to a stub: answer with AD=1,
answer without AD=1 (i.e. AD is clear), and SERVFAIL.  The first of
these corresponds to the first "+" above, the last to the second "+",
and I can't tell whether the "When processing" is processing the +
Everything Else or a description of how to consume and process an
answer generally.

Thanks,

A

-- 
Andrew Sullivan
[email-masked]

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Nov 2011 15:34:56 -0500

> does "Matches" means "has AD bit set?" (and conversely, doesn't

No, "match" is a match between the TLSA record and the certificate.  E.g., does the certificate chain to a trust anchor in a type 2 certificate?  It's an orthogonal, second-level check.

> Everything Else or a description of how to consume and process an

I think the map is as follows:
AD=1 => Record exists and is secure
SERVFAIL => DNS response is bogus
AD=0 => [Falls into everything else]

As I understood it, Ondrej was expressing four rules:
Record exists and is secure && TLSA match => OK
Record exists and is secure && not TLSA match => FAIL
DNS Response is Bogus => FAIL
Otherwise => NO-INFO

--Richard

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Nov 2011 15:51:30 -0500

> DNS Response is Bogus => FAIL

This is infinitely clearer.

With the proviso that "bogus" is not strictly speaking something a
non-validating resolver can strictly know (that is, SERVFAIL tells you
"validation failed or else something else went wrong"), but that it's
close enough, I'm ok with the above.  In other words, subject to
confirmation that's what's meant (and BTW, it's not how I interpreted
it, but I'm dim), +1.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Eric Osterweil <[email-masked]>
Date: Wed, 30 Nov 2011 15:51:16 -0500

> + TLSA Resource Record Exists and is Secure (RFC4033 Section 5)

+1 to the above

>  + TLSA Resource Record Doesn't Match => FAIL

So, is this under the catch-all case where the response is _not_ DNSSEC verified?  If this is correct, then we are verifying a cert based on non-verified DNS data, and my vote is:
-1

THough, I share (at least some of) Andrew's confusion, so I admit I might be responding based on a misinterpretation...

> - It's harder to implement, because there is not common API for that yet.

-1 because I believe (based on something someone said in the previous thread) this can be used in a downgrade attack using a cert from a compromised CA.

Eric

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 22:03:26 +0100

On 30. 11. 2011, at 21:51, Eric Osterweil wrote:

> So, is this under the catch-all case where the response is _not_ DNSSEC verified?

Nope.  It has lost the formatting somewhere along the way...

I'll send the I-D text in a second.

>  If this is correct, then we are verifying a cert based on non-verified DNS data, and my vote is:
> -1
>

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 22:07:32 +0100

In a hope to clear at least some of the confusion, here's the
text which replaces last paragraph in 4.4, which is NOW:

--old text from -12--
   An application that complies with this document first requests TLSA
   records in order to make certificate associations.  If that
   application receives zero usable certificate associations, it
   processes TLS in the normal fashion; otherwise, that application
   attempts to match each certificate association with the TLS server's
   end entity certificate.  If such a match is found, that application
   continues the TLS handshake and ignores any remaining certificate
   associations; otherwise, that application MUST abort the TLS
   handshake with an "access_denied" error.
--old text from -12--

which becomes:

--new text--
   An application that complies with this document first requests TLSA
   records in order to make certificate associations.

   Determining whether a TLSA RRset can be used depends
   on the DNSSEC validation state (as defined in [RFC4033]).

   o A TLSA RRset whose DNSSEC validation state is secure MAY be used
     as a certificate association for TLS.

   o If the DNSSEC validation state on the response to the request
     for the TLSA RRset is bogus, this MUST cause TLS not to be started
     or, if the TLS negotiation is already in progress, to cause
     the connection to be aborted.

   o A TLSA RRset whose DNSSEC validation state is indeterminate or
     insecure cannot be used for TLS and MUST be marked as unusable.
--new text--

Note: Please read whole text and not just bullets.  E.g. in all other
possible (undefined here) cases the TLSA RRset cannot be used.

O.

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Nov 2011 22:11:06 +0100 (MET)

> DNS Response is Bogus => FAIL

I having a serious problem with the 3rd, the others are OK.

For usage types 0/1 (PKIX-validating cert), it really ought to be 

DNS Response is Bogus => NO-INFO

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Nov 2011 16:17:26 -0500

> DNS Response is Bogus => NO-INFO

Can you say more about why you think this?  

ISTM that treating different usages differently makes implementation and extensibility difficult.  Also, as Ondrej noted, making Bogus=>NO-INFO implies that suppressing usage 0/1 controls is trivial.

--Richard

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Nov 2011 13:21:04 -0800

> possible (undefined here) cases the TLSA RRset cannot be used.

+1 to this proposed wording.

--Paul Hoffman

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 30 Nov 2011 16:21:01 -0500

> possible (undefined here) cases the TLSA RRset cannot be used.

I read this text, I understand it, and it's fine with me.

A

-- 
Andrew Sullivan
[email-masked]

---

From: Martin Rex <[email-masked]>
Date: Wed, 30 Nov 2011 22:23:39 +0100 (MET)

> Can you say more about why you think this?  

I believe there is no reliable difference between Bogus and Indeterminate,
the distinction has at best some minor relevance for admins while doing
troubleshooting. 

http://tools.ietf.org/html/rfc4035#page-21

How would you check compliance of any particular implementation in
reliably distinguishing bogus from inteterminate based on that definition?

> 
> ISTM that treating different usages differently makes implementation
> and extensibility difficult.  Also, as Ondrej noted, making
> Bogus=>NO-INFO implies that suppressing usage 0/1 controls is trivial.

Yes, suppressing these controls is trivial.

DNS does *not* provide a reliable transport between end entities.

Means to work around lack of reliability in DNS is to do local caching
of previously received and still valid (with respect to RSIG, not TTL)
DNS records and conveying the relevant DNS records inline through
a TLS extension.

-Martin

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Nov 2011 16:36:53 -0500

+1

--Richard

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Wed, 30 Nov 2011 22:41:46 +0100

> DNS Response is Bogus => FAIL

In that case: +1

But I would be interested in the exact wording of the document.
Especially for the 'is secure' part.

I am by no means an expert in resolver-libraries, so apologies if I get
it all wrong, but is the AD-bit at all visible to the application that
issues an 'res_mkquery()' or something similar? And if it isn't, than
how is a browser supposed to 'declare a record secure'? Does DANE imply
that new resolvers libraries will have to be defined, that will pass on
the AD-bit? Does it imply validation on the client-side perhaps?

--
Marco

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 Nov 2011 16:46:38 -0500

> +1 to this proposed wording.

<no hats>
   I am ok with the proposed wording.

    Nit:
    s/TLS negotiation is already in progress, to cause/TLS negotiation is already in progress, cause/  # Superfluous 'to'?

</no hats>

W

---

From: Peter Koch <[email-masked]>
Date: Wed, 30 Nov 2011 22:51:17 +0100

> possible (undefined here) cases the TLSA RRset cannot be used.

I have read the whole text and think it is well done! => "+1"

For the final document, it should try even less to be aesthetic prose, so
"cannot be used for TLS and MUST be marked as unusable" would become
"MUST NOT be used for TLS".  Also, an additional explanation for the second
bullet's complicated wording would state that there might not be a TLSA RRSet
available (RCODE=SERVFAIL).  Finally, the Security Considerations section
should advise that the 'restrictive' use case cannot be relied upon; that's
only a slight drawback because it doesn't help with all the DANE-unaware
implementations to start with.

-Peter

---

From: Warren Kumari <[email-masked]>
Date: Wed, 30 Nov 2011 16:55:03 -0500

On Nov 30, 2011, at 4:41 PM, Marco Davids (SIDN) wrote:

> it all wrong,

[No hats]

Me neither, so apologies in advance if I get things horribly wrong!

> but is the AD-bit at all visible to the application that
> the AD-bit?
> Does it imply validation on the client-side perhaps?

Kinda.

There are currently a number of products / resolver libraries that expose this information (libunbound, SPARTA's libval as examples), but there is currently no standard standard interface to get this information. There is currently ongoing efforts to create a standard API for getting this (and additional info) from the resolvers. 
Apps can also simply* do the DNSSEC themselves... 

W
*: Notice the hand-waving there? Good, wasn't it?!

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 30 Nov 2011 14:01:47 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Ondrej Surý
> Sent: Wednesday, November 30, 2011 1:08 PM
> To: IETF DANE WG list
> Subject: Re: [dane] Call for consensus on level of DNSSEC support (Security-
> aware Stub Resolver in DANE-aware application)
> 
> In a hope to clear at least some of the confusion, here's the text which
> replaces last paragraph in 4.4, which is NOW:
> 
> --old text from -12--

Can you elaborate on why you put a MAY here?

Jim

> Note: Please read whole text and not just bullets.  E.g. in all other possible
> (undefined here) cases the TLSA RRset cannot be used.
> 
> O.
> 
> On 30. 11. 2011, at 17:59, Ondrej Sur  wrote:
> 
> > Hi all,
> >
> > I will use the RFC4033 language (Section 2 and Section 5), so please
> > read that before you comment.
> >
> > How is that achieved is out-of-the-scope for this email (and for the
> > DANE protocol draft).
> >
> > It seems to me that from the 'Aiming towards...' thread, we still have
> > a misunderstanding what should DANE-aware application do or not do.
> >
> > In particular, the call for consensus is that DANE-aware application
> > has to implement (at least) Non-validating Security-aware Stub
> > Resolver.  As we (Warren) said earlier there were some concerns in the
> > IESG and we have the DNSSEC in the charter, so we have to use only
> > Secure TLSA possitive answers.  Also we cannot ignore the Bogus state,
> > because then the restrictive option (Usage type 0/1) would be
> > vulnerable to stripping in-path attack.
> >
> > Implications:
> > I think we already had a quite intensive discussion on this topic, so
> > please only express your opinion (+1 vs. -1)
> >
> > Thank you,
> > --
> > Ondrej Sur
> > vedouc  v zkumu/Head of R&D department
> > CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC
>  Ondrej Sur
>  vedouc  v zkumu/Head of R&D department
>  CZ.NIC, z.s.p.o.    --    Laboratore CZ.NIC

---

From: Yoav Nir <[email-masked]>
Date: Thu, 1 Dec 2011 00:07:45 +0200

+1

Except, why is that a MAY on the first bullet?  If you're not going to act on a DNSSEC-validated TLSA record, what's the point of implementing this specification?

---

From: Yoav Nir <[email-masked]>
Date: Thu, 1 Dec 2011 00:08:19 +0200

> Can you elaborate on why you put a MAY here?

Oops, beat me to it.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 30 Nov 2011 14:19:45 -0800

> Except, why is that a MAY on the first bullet?  If you're not going to act on a DNSSEC-validated TLSA record, what's the point of implementing this specification?

There may be other policy that would cause you to not use the certificate association. For example, assume that you *only* trust certs from YourOwnCA when communicating with any.domain.under.yourowncompany.com. You go to misconfigured.yourowncompany.com and get a TLSA record type 0 that is issued by SomeOtherCA. Your local policy should be able to trump the TLSA record.

--Paul Hoffman

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 23:26:55 +0100

> Especially for the 'is secure' part.

See my later email.

> the AD-bit? Does it imply validation on the client-side perhaps?

See RFC 4033 Section 5:

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

That's why I have wrote that DANE-aware application must implement
(at least) non-validating security-aware stub resolver.

O.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 23:30:42 +0100

> http://tools.ietf.org/html/rfc4035#page-21

That discrepancy must be fixed in DNSEXT.  We are using RFC 4033 definitions
of DNSSEC validation states.

> so please read that before you comment.
[...]
> + TLSA Resource Record Exists and is Secure (RFC4033 Section 5)
[...]

O.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 30 Nov 2011 23:35:37 +0100

I see that as an equivalent to:

>>   o A TLSA RRset whose DNSSEC validation state is secure can be used

O.

---

From: Tony Finch <[email-masked]>
Date: Wed, 30 Nov 2011 22:47:10 +0000

> DNS Response is Bogus => NO-INFO

No, a bogus DNSSEC response implies you are under attack and that any TLS certificate is likely to have been issued by an untrustworthy CA.

I think Ondřej's proposed text is fine.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: Martin Rex <[email-masked]>
Date: Thu, 1 Dec 2011 00:12:05 +2500 (MET)

>> http://tools.ietf.org/html/rfc4035#page-21

   Bogus: An RRset for which the resolver believes that it ought to be
      able to establish a chain of trust but for which it is unable to
      do so, either due to signatures that for some reason fail to
      validate or due to missing data that the relevant DNSSEC RRs
      indicate should be present.  This case may indicate an attack but
      may also indicate a configuration error or some form of data
      corruption.

   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.

> of DNSSEC validation states.

I fail to notice a difference.

http://tools.ietf.org/html/rfc4033#page-10

   Bogus: The validating resolver has a trust anchor and a secure
      delegation indicating that subsidiary data is signed, but the
      response fails to validate for some reason: missing signatures,
      expired signatures, signatures with unsupported algorithms, data
      missing that the relevant NSEC RR says should be present, and so
      forth.

   Indeterminate: There is no trust anchor that would indicate that a
      specific portion of the tree is secure.  This is the default
      operation mode.

If you have a roaming device with a secure resolver (i.e. the root
zone key locally configured) and you are either a static host and
behind a middle box that impairs DNS lookups but lets DS records pass,
or a mobile host that is caching DNS records (including DS records
for a zone) and you roam to an area where a middlebox prevents you
from further receiving some of the zones records for whatever reason
so that you can not perform a signature verification,
then both 4033 and 4035 say that all lookups for that zone
are to be flagged as "bogus".

I believe DANE should avoid creating new interop problems.

-Martin

---

From: James Cloos <[email-masked]>
Date: Wed, 30 Nov 2011 20:10:55 -0500

OS> I think we already had a quite intensive discussion on this topic,
OS> so please only express your opinion (+1 vs. -1)

+1

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Nov 2011 20:49:26 -0500 (EST)

>>>     as a certificate association for TLS.

Not entirely. If I get a DNSSEC  validated TLSA RRset, and I don't find a
matching hash, the "MAY" suggests I'm fine not using it and trusting just
other local policies like PKIX, thereby removing the TLSA protection.

Perhaps these items need to contain both "whose DNSSE validation state is secure"
and "contains a valid TLSA record matching the received TLS information"?

Or perhaps it should be "MUST" whereupon missing a matching TLSA in a validating
set leads to aborting?

Paul
(in general +1 for what is meant, but will monitor exact text)

---

From: Scott Schmit <[email-masked]>
Date: Wed, 30 Nov 2011 22:30:41 -0500

+1

-- 
Scott Schmit

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Nov 2011 22:46:56 -0500

> (in general +1 for what is meant, but will monitor exact text)

This logic seems kind of sensible.  If you're doing this specification, you MUST interpret whatever TLSA records you find.  If you're going to ignore secure records, you're just not doing DANE.  

Consider the reverse: What if someone does follows the bogus and "other" cases (the MUSTs), but *not* the secure case (the MAY)?  In that case, all they're getting is FAIL or NO-INFO; basically they're testing to see if DNSSEC works on TLSA records.  This doesn't seem tremendously valuable, so I'm comfortable ruling it out.

--Richard

---

From: Zack Weinberg <[email-masked]>
Date: Wed, 30 Nov 2011 19:55:22 -0800

On Wed, Nov 30, 2011 at 7:46 PM, Richard L. Barnes <[email-masked]> wrote:
> This logic seems kind of sensible.  If you're doing this specification, you MUST
> interpret whatever TLSA records you find.  If you're going to ignore secure records,
> you're just not doing DANE.

I don't think DANE should override a local determination that some
certificate is never to be trusted (explicit blacklist, that is, not
just default-untrusted).  Can we make sure we allow local policy to do
that?

zw

---

From: "Richard L. Barnes" <[email-masked]>
Date: Wed, 30 Nov 2011 23:03:53 -0500

> just default-untrusted).  Can we make sure we allow local policy to do

Do we really need to say anything about this?  ISTM that local policy can always override.  Keep in mind that DANE validation is a part of the overall certificate acceptance process.  There are already other checks (e.g., name checks) that get applied by the application layer; checking blacklists could be part of that.  

Besides, if you see the cert and it's on your black-list, why would you go to the trouble of invoking DANE?    

--Richard

---

From: Paul Wouters <[email-masked]>
Date: Wed, 30 Nov 2011 23:08:56 -0500 (EST)

> Besides, if you see the cert and it's on your black-list, why would you go to the trouble of invoking DANE?

I just wanted to make clear that IF an application implements DANE, and it gets a TLSA RRset
that does validate to a trust anchor AND there is no matching TLSA record for the TLS connection
that it MUST abort.

I think the "MAY" in the proposed text could be misread to mean if no matching TLSA is found in
the obtained validated RRset, go try something else to validate the key.

Paul

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 1 Dec 2011 05:11:59 +0100

+1

	jakob

---

From: Matt McCutchen <[email-masked]>
Date: Wed, 30 Nov 2011 20:56:40 -0800

On Wed, 2011-11-30 at 14:19 -0800, Paul Hoffman wrote:
> > Except, why is that a MAY on the first bullet?  If you're not going
> to act on a DNSSEC-validated TLSA record, what's the point of
> implementing this specification?
> 
> There may be other policy that would cause you to not use the
> certificate association. For example, assume that you *only* trust
> certs from YourOwnCA when communicating with
> any.domain.under.yourowncompany.com. You go to
> misconfigured.yourowncompany.com and get a TLSA record type 0 that is
> issued by SomeOtherCA. Your local policy should be able to trump the
> TLSA record.

Does local policy override the restrictive part of TLSA or only the
additive part?  I.e., is a client that accepts a cert from YourOwnCA for
misconfigured.yourowncompany.com regardless of the TLSA RRset
conformant?  From the "MAY", I am not sure.

-- 
Matt

---

From: Yoav Nir <[email-masked]>
Date: Thu, 1 Dec 2011 09:26:08 +0200

>>>    as a certificate association for TLS.

I think the second version is better. As Paul W said, the normative language is confusing here.

But +1 either way.