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

From: Ondřej Surý <[email-masked]>
Date: Fri, 6 Apr 2012 09:53:20 +0200

+1 to what Jim said.

On 21. 3. 2012, at 9:18, Jim Schaad wrote:

> 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
>> 
>> 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
>> 
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
> 
> _______________________________________________
> 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: John Gilmore <[email-masked]>
Date: Tue, 10 Apr 2012 17:00:31 -0700

>> which is being said in this document.

Both DANE and the status-quo CA model are PKIs.  Nobody is saying that
PKI is untrustworthy.  (And I've helped to revise the text you objected
to, to be less inflammatory.)

At the same time we should not be suggesting that keys which are ONLY
certified by DANE, and not by a CA, are somehow untrustworthy, should
not be trusted by software, or that clients should configure their
software to refuse to honor them.

I still believe that this paragraph should be removed from the draft.

	John

---

From: "Jim Schaad" <[email-masked]>
Date: Wed, 11 Apr 2012 12:00:07 -0700

John,

In my opinion this paragraph is no different than the one we no longer (hopefully) need to put into documents which says choose you trust anchors for PKI with care.  If you don't have one that the entity on the other end trusts then you will be unsuccessful.

In this case we are establishing a new way to convey what the trust anchor would be.  We need to tell people that not everybody is going to believe them.

Jim

> From: John Gilmore [mailto:[email-masked]]
> Sent: Tuesday, April 10, 2012 5:01 PM
> To: Ondrej Surý
> Cc: Jim Schaad; 'John Gilmore'; 'dane list'
> Subject: Re: [dane] Security consideration "local policy" distrusting usages 2
> and 3
> 
> >> 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.
> 
> Both DANE and the status-quo CA model are PKIs.  Nobody is saying that PKI
> is untrustworthy.  (And I've helped to revise the text you objected to, to be
> less inflammatory.)
> 
> certified by DANE, and not by a CA, are somehow untrustworthy, should not
> be trusted by software, or that clients should configure their software to
> refuse to honor them.
>