Subject: [dane] Security consideration "local policy" distrusting usages 2 and 3

From: John Gilmore <[email-masked]>
Date: Tue, 20 Mar 2012 17:35:14 -0800

In the last paragraph of Section 8 of -18, we have this new text:

   The client's full trust of a certificate retrieved from a TLSA record
   with a certificate usage type of 2 or 3 may be a matter of local
   policy.  While such trust is limited to the specific domain nane for
   which the TLSA query was made, local policy may deny the trust or
   further restrict the conditions under which that trust is permitted.

Text similar to this was proposed by Jim Schaad on March 4th.  Ondrej
responded LGTM ("Looks Good To Me").  I missed this proposed change at
that time.

I don't see why usage types 2 and 3 are specifically called out here
as untrustworthy.

It seems to me that local policy can override anything we say in an
RFC, anytime, anywhere.  Local policy may break interoperability, of
course, but that's usually intentional (e.g. the locals don't trust
some particular domain name or key, so don't WANT to interoperate with
it).  We specify this in Section 4:

   o  A TLSA RRset whose DNSSEC validation state is secure MUST be used
      as a certificate association for TLS unless a local policy would
      prohibit the use of the specific certificate association in the
      secure TLSA RRset.

But this new graf in Section 8 isn't about local policy about specific
names or keys.  It seems like a back-handed attempt to discredit the
security of keys that are certified only by TLSA records (rather than
by a certification chain headed by one of the existing CA businesses'
trust anchors).  The suggestion is that it would be a good idea for
software that implements TLSA to be configurable to "deny the trust"
of any certificate that arrives with usage types 2 or 3.  If that is
the intent, this text doesn't belong in the very document that
specifies that we think we HAVE defined a protocol that communicates
such keys securely.

If we wouldn't include similar text about usage types 0 or 1, why do
we now have such a statement exclusively about types 2 and 3?  If
we recommend making software configurable to turn off specific usage
types in specific clients, this will make interoperability fail.

We currently have text in Section 6 that mandates that clients MUST
implement all four usage types.  This permits server operators to
choose any usage type that fits their circumstances, relying on the
fact that any standards-conforming TLSA client can interoperate with
their server.  I don't see how the new suggestion to distrust types 2
and 3 is compatible with this MUST.

My proposal is to remove the paragraph.  (If there is some reason
to keep and modify it, please explain why.)

	John

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 21 Mar 2012 01:18:21 -0700

John,

The issue is one of explicitly known when a trust decision is being made.
While many people argue that one does not know for Windows when this
decision is made as it gets farmed out to Microsoft, this is not true for
all configurations and for all other operating systems.  

The statement does not say that you cannot trust it just because it is in
the DNS records, it says that some people may not do so or may do so only
under some circumstances.

This is not an issue for type 0 or 1 records as the trust decision is made
elsewhere.

I guess it is no more of a back hand way of saying that some people will not
trust it than DANE is a back handed way of saying that PKI is untrustworthy
which is being said in this document.

Jim

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> John Gilmore
> Sent: Tuesday, March 20, 2012 6:35 PM
> To: dane list; [email-masked]
> Subject: [dane] Security consideration "local policy" distrusting usages 2
and 3
> I don't see why usage types 2 and 3 are specifically called out here as
> untrustworthy.
> 
> It seems to me that local policy can override anything we say in an RFC,
> anytime, anywhere.  Local policy may break interoperability, of course,
but
> that's usually intentional (e.g. the locals don't trust some particular
domain
> name or key, so don't WANT to interoperate with it).  We specify this in
> Section 4:
> 
names or
> keys.  It seems like a back-handed attempt to discredit the security of
keys
> that are certified only by TLSA records (rather than by a certification
chain
> headed by one of the existing CA businesses'
software
> that implements TLSA to be configurable to "deny the trust"
> of any certificate that arrives with usage types 2 or 3.  If that is the
intent, this
> text doesn't belong in the very document that specifies that we think we
> HAVE defined a protocol that communicates such keys securely.
> 
> If we wouldn't include similar text about usage types 0 or 1, why do we
now
> have such a statement exclusively about types 2 and 3?  If we recommend
> making software configurable to turn off specific usage types in specific
> clients, this will make interoperability fail.
> 
> implement all four usage types.  This permits server operators to choose
any
> usage type that fits their circumstances, relying on the fact that any
> standards-conforming TLSA client can interoperate with their server.  I
don't
> see how the new suggestion to distrust types 2 and 3 is compatible with
this
> MUST.
> 
> My proposal is to remove the paragraph.  (If there is some reason to keep
> and modify it, please explain why.)
> 
> 	John
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane