Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-17.txt

From: "Jim Schaad" <[email-masked]>
Date: Sun, 4 Mar 2012 15:20:03 -0800

Here are some comments on this draft and some comments on the -16 version
that I could never get the mailing list to accept.

1.  In section 1.1. paragraph 3:  "TLS uses certificates to protect keys."
TLS uses certificates to bind names to keys, it does nothing about
protecting the secret portion of the key discussed in the previous
paragraph.   I suggest chaining the text to state "TLS uses certificates to
bind keys and names." Or possibly just remove the sentence entirely.

2. In section 2.1.1 - item usage 2 -- nit - s/must be used as a trust
anchor/must be used as the trust anchor/ The certificate is not added to the
set of trust anchors, it is the set of trust anchors.  This means that a
specific rather than a general indicator should be used.

3. In section 2.1.1 - I do not find the details for usage #3 to be clear.  I
believe from what I saw on the mailing this that what is being said is that
the certificate must match the end entity certificate and that certificate
is the trust anchor certificate and is therefore implicitly trusted.  The
current text does not make that clear to me.  I find it difficult to
understand the difference between usage 1 and usage 3 based strictly on the
text given. Additionally I have a problem with implying that this usage is
the "domain-issued certificate", I thought that the same term was used in
case 2 where the CA is strictly inside of the domain and the CA issued
certificates.  I have just re-read the text in RFC 6394 and don't see any
way from it to distinguish between the trust-anchor and domain-issued
certificate cases.  There is definitely nothing that states that
domain-issued certificates would be a self-signed certificate rather than
one that is placed in a hierarchy.

4.  In section 4 - the text is
	If a host is using TLSA usage type 2 for its certifcate, the
   	corresponding TLS server SHOULD send the certificate that is
   	referenced just like it currently sends intermediate certificates.

I find this text slightly confusing.  From the previous mailing list
traffic, I thought in this case there was an effective one certificate path
and therefore no intermediate certificates would exist.  I believe you mean
to say that it should be sent just like the EE certificate is.
	s/certifcate/certificate/

5.  In section 5 - "No Downgrade" - The last clause in the paragraph does
not agree with the text in section 4 -  I would request that the last clause
be changed to  "TLS  will not successfully connect." or "TLS will fail the
connection."  The text implies no attempt, rather than being aborted after
the attempt has started.   - I will agree that this is kind of a nit.

6. - Very weak suggestion - you might consider using RFC 6234 as the SHA2
reference rather than the NIST document.

7.  In section 7.1 - I find the text in paragraph #2 to be a non-sequitur.
I think that this text is general and applies to all of the following
sections.  As such it more properly belongs in section 7 rather than in
section 7.1.  If I were to skip reading section 7.1 because I know the
RRtype I would miss the RFC required requirement.  Potentially the text
could be removed as the policy is listed individually for each section; this
is just a rationalization text that makes no sense where it is located.

8.  In section  8 -  The following text is included

	Client treatment of any information included in the certificate
trust
   	anchor is a matter of local policy.  This specification does not
   	mandate that such information be inspected or validated by the
domain
  	 name administrator.

	Which domain name administrator are we talking about here?  The
client's or the server's administrator? 

9.  In section 8 - I believe that the following text is missing:
	
	The client acceptance of an arbitrary certificate retrieved from a
TLSA record with a usage type of 2 or 3 as fully trusted may be a matter of
local policy.  While such trust is limited to the specific domain for which
the TLSA query has been made, local policy may deny the trust or further
restrict the conditions under which that trust is permitted.

10.  In section A.1 - does the last paragraph still apply given that we have
added usage 3?   Are we still suggesting that usage 2 be used for a single
certificate chain or that people should use usage 3?

11.   Section A.1.2 - Suggested replacement text
 In this section, a "false-negative failure" means that a client cannot
build a certificate chain that validates with the TLSA data provided by the
DNS administrator when a legal chain does exist.  A "false-positive failure"
means that the client successfully builds a certificate chain that validates
with the TLSA data provided and for which the DNS  administrator intended
that the validation fails.

As the text currently stands, I believe that a false-negative not be true if
a chain was built that did not use the certificate in the TLSA data.  I also
wonder if the false-negative case is supposed to apply for the cases that a
TLSA data record is marked as unusable for any reason and would thus include
the case of DNSSEC indeterminate?

12.  Section A.1.3-I suggest adding the following new bullet

o The administrator should understand that any CA could, in the future,
issue a certificate that contains the same SubjectPublicKeyInfo and
therefore new chains can crop up in the future without any warning.

---

From: Ondřej Surý <[email-masked]>
Date: Wed, 7 Mar 2012 13:53:58 +0100

Jim,

thanks for extensive review.

On 5. 3. 2012, at 0:20, Jim Schaad wrote:

> paragraph.   I suggest changing the text to state "TLS uses certificates to

LGTM (both options)

> specific rather than a general indicator should be used.

+1

> one that is placed in a hierarchy.

The main difference between 1 and 3 is:
#1: The target certificate MUST pass PKIX certification path validation and MUST match the TLSA record.
#3: The target certificate MUST match the TLSA record.

I agree that "domain-issued certificate" may be confusing, but I have no ideas on a better name.

> and therefore no intermediate certificates would exist.  

Nope.  The validation path in case 2 could contain more certificates.

> I believe you mean

LGTM

> reference rather than the NIST document.

I don't care.  FIPS is OK for me.

> RRtype I would miss the RFC required requirement.

+1

> Potentially the text

I would suggest to keep it, because I am sure somebody will ask about why we have chosen RFC Required in IETF LC, then in reviews and lastly in IESG.

> client's or the server's administrator? 

I think the server's administrator.  We should make this clear in the document.

> restrict the conditions under which that trust is permitted.

LGTM

> certificate chain or that people should use usage 3?

True.  Needs to be fixed.  See my reply to Ondrej Mikle.

> that the validation fails.

LGTM, but how does that apply to Usage 3 which have no chain and must match the cert/SPKI?

But could somebody else please also check the new text?

> therefore new chains can crop up in the future without any warning.

LGTM

--
 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: Paul Hoffman <[email-masked]>
Date: Thu, 8 Mar 2012 19:45:38 -0800

[[ Commenting only on the Appendix A stuff ]]

> But could somebody else please also check the new text?

Appendix A only applies to things that do PKIX validation, and usage type 3 doesn't. I don't think that changes need to be made to handle type 3, or maybe we could add at the beginning "This appendix applies to certificate usage types 0, 1, and 2 only. Using certificate usage type 3 avoids the operational considerations described in this appendix."

--Paul Hoffman

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 8 Mar 2012 21:10:32 -0800

Sorry for the delay,  I have finally found where a pile of e-mail messages was wandering off to.

> -----Original Message-----
> From: Ondrej Surý [mailto:[email-masked]]
> Sent: Wednesday, March 07, 2012 4:54 AM
> To: Jim Schaad
> Cc: [email-masked]; Paul Hoffman
> Subject: Re: [dane] I-D Action: draft-ietf-dane-protocol-17.txt
> 
> Jim,
> 
> > 3. In section 2.1.1 - I do not find the details for usage #3 to be
> > clear.  I believe from what I saw on the mailing this that what is
> > being said is that the certificate must match the end entity
> > certificate and that certificate is the trust anchor certificate and
> > is therefore implicitly trusted.  The current text does not make that
> > clear to me.  I find it difficult to understand the difference between
> > usage 1 and usage 3 based strictly on the text given. Additionally I
> > have a problem with implying that this usage is the "domain-issued
> > certificate", I thought that the same term was used in case 2 where
> > the CA is strictly inside of the domain and the CA issued
> > certificates.  I have just re-read the text in RFC 6394 and don't see
> > any way from it to distinguish between the trust-anchor and
> > domain-issued certificate cases.  There is definitely nothing that
> > states that domain-issued certificates would be a self-signed certificate
> rather than one that is placed in a hierarchy.
> 

That still does not make it clear that the difference is that #3 says you must match and it is absolutely trusted iff it matches.

> > traffic, I thought in this case there was an effective one certificate
> > path and therefore no intermediate certificates would exist.
> 

My confusion - I read this as usage type 3 not usage type 2.

> > 	Client treatment of any information included in the certificate trust

> > build a certificate chain that validates with the TLSA data provided
> > by the DNS administrator when a legal chain does exist.  A "false-positive
> failure"
> > means that the client successfully builds a certificate chain that
> > validates with the TLSA data provided and for which the DNS
> > administrator intended that the validation fails.
> 

Since you do not build a chain in this case - there is no possible false-positive or false-negative failure from chain building.

> > As the text currently stands, I believe that a false-negative not be
> > true if a chain was built that did not use the certificate in the TLSA
> > data.  I also wonder if the false-negative case is supposed to apply
> > for the cases that a TLSA data record is marked as unusable for any
> > reason and would thus include the case of DNSSEC indeterminate?
> >
> > o The administrator should understand that any CA could, in the
> > future, issue a certificate that contains the same
> > SubjectPublicKeyInfo and therefore new chains can crop up in the future
> without any warning.

Oops - this should have been section A.1.2.2 - sorry