Subject: Re: [dane] Call for last comments on issue #37.

From: Matt McCutchen <[email-masked]>
Date: Wed, 01 Feb 2012 23:44:00 -0800

On Tue, 2012-01-31 at 10:21 +0100, Ondřej Surý wrote:
> it seems this thread is either unimportant or very hard to understand
> to the rest of the working group (and I must admit it's very hard for
> me to understand the underlying problem).

Let me explain once more.  If you do not understand, please tell me
where I lost you.

Suppose my TLS server has a certificate C that is signed by the root
certificate R of a private CA.  I want DANE clients to accept C, but not
other certificates signed by R.

Usages 0 and 1 do not work: since R is not in the trust anchor store of
mainstream clients, validation fails.  With usage 2 and association data
that matches R, clients will accept any certificate signed by R, which I
don't want.  The debate was about what happens if the TLSA record has
usage 2 and association data that matches C, meaning that C is
considered to be a trust anchor for the validation.  My understanding is
that validation fails because "Valid paths begin with certificates
issued by a trust anchor" (RFC 5280 section 6), and there is no
certificate issued by C at all (remember, C is issued by R, not itself),
hence there is no way to construct a valid path.

> Would you be willing to accept this partial solution, so we can move
> on with the draft?

No.  Not that I expect it to matter what I am willing to accept.

I don't understand why Martin called Paul's wording a partial solution.
As far as I can tell, it doesn't do anything to solve the problem Martin
identified.

> If not would you be willing to propose a specific
> text we can work on?

My proposal is to add certificate usage 3, as follows:

3 -- The target certificate MUST match the TLSA record

> I think we have discussed this issue long enough and haven't gotten anywhere,

On the contrary, we learned that in addition to the case of a
self-signed server cert (which is still unclear and likely to be a
problem in real implementations), the current draft definitely does not
support positive assertion of a non-self-signed server cert.  Adopting
usage 3, or alternatively Stephen's proposed amendment
(https://www.ietf.org/mail-archive/web/dane/current/msg04239.html),
would solve both problems.

> From the chair viewpoint I think it's more important to stick to existing
> standards than to cover every possible use case.  If there's one working
> way how to deploy EE-certificate without using existing CAs (trust anchors)
> I am perfectly happy even if it's not the easiest way possible.

Could you clarify what existing standard you believe we should stick to?

Paul Wouters and I had the understanding that positive assertion of an
arbitrary server certificate was within the intended scope of the use
cases even though it was not specifically mentioned in RFC 6394.  And I
think it is an important part of making DANE convenient for server
admins.  But again, not that it matters what I think.

-- 
Matt

---

From: Ondřej Surý <[email-masked]>
Date: Thu, 2 Feb 2012 08:56:56 +0100

> Let me explain once more.  If you do not understand, please tell me

Your new explanation is perfect.  Thanks for writing it (or maybe it's
combination of Stephen's email and your clearer language).

> support positive assertion of a non-self-signed server cert.  
> Adopting usage 3, or alternatively Stephen's proposed amendment

It seams reasonable, but I would like to hear more opinions from WG.

> Could you clarify what existing standard you believe we should stick to?

First two paragraphs of Stephen's email.  He said it better.

--
 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: Scott Schmit <[email-masked]>
Date: Thu, 2 Feb 2012 08:27:32 -0500

> It seams reasonable, but I would like to hear more opinions from WG.

I think client code will be cleaner if usage type 3 is distinct from
usage type 2, so I would prefer that.

Ignoring this usage will put users in the awkward place of choosing
another cert usage that doesn't meet their needs.

For example, if I want to directly assert an EE cert that is certified
by a TA that is in some, but not all, client certificate stores, my
options are:

a) Loosen the assocation by using type 2, which still reduces my risk
   compared to not using DANE at all, but not as much as if I used a TA
   all my clients already accept so that I could use usage 1 instead.

b) Generate a self-signed certificate and use type 2, breaking all
   interoperability with those clients that have my TA but don't support
   DANE--which might mean I support fewer clients than I did before.

c) Use type 1 and pick a more widely-recognized TA to issue me a cert,
   if possible.  This might not always be an option, because my clients
   could have mutually exclusive sets of TAs they trust.  Also, live
   with the fact that DANE can't help me assert that my key is
   trustworthy without breaking interoperability with my clients.

d) Lobby for a cert usage type 3 :-)

We should add cert usage type 3 (or change type 1 to be what we're
describing as type 3).

-- 
Scott Schmit

---

From: Jakob Schlyter <[email-masked]>
Date: Thu, 2 Feb 2012 18:52:06 +0100

> It seams reasonable, but I would like to hear more opinions from WG.

I'm good with adding a type 3 ("The target certificate MUST match the TLSA record").

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 2 Feb 2012 09:58:47 -0800

> I'm good with adding a type 3 ("The target certificate MUST match the TLSA record").

+1 here. It would certainly make the documentation of type 2 clearer.

--Paul Hoffman

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Feb 2012 20:14:02 +0100 (MET)

Paul Hoffman wrote:
>>Ondrej Sury wrote:
>Jakob Schlyter wrote:
>> I'm good with adding a type 3
>> ("The target certificate MUST match the TLSA record").
> 

                   11
    ++           1111
    ++         111 11
++++++++++         11
++++++++++         11
    ++             11
    ++             11
                 111111

-Martin

---

From: James Cloos <[email-masked]>
Date: Thu, 02 Feb 2012 14:30:10 -0500

>>>>> "PH" == Paul Hoffman <[email-masked]> writes:

>> I'm good with adding a type 3 ("The target certificate MUST match the TLSA record").

PH> +1 here. It would certainly make the documentation of type 2 clearer.

Also +1.  I think it covers all of the concerns I've posted.

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

---

From: Pieter Lexis <[email-masked]>
Date: Thu, 02 Feb 2012 20:47:48 +0100

Hi,

> I'm good with adding a type 3 ("The target certificate MUST match the TLSA record").

+1, and usage 2 should be better defined.

- --
Pieter

---

From: Zack Weinberg <[email-masked]>
Date: Thu, 2 Feb 2012 12:12:24 -0800

+1 from me too.

On Thu, Feb 2, 2012 at 11:47 AM, Pieter Lexis <[email-masked]> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJPKuhgAAoJELPqGO5ebd4jVvwQAI99tkqxxwjV5GEBYaFmfapp
> j+4W3Ivm2buYUYRxIH5pkQCZ0nTfx3gvK17XM/0Ypnu0ist2+HoMBpG7Gak3AbT6
> kwSZLJKgeulMPi1CETB6SHp/hvPR1T+R7xXwVeeEcGGllumUdi62JX2soU7WKibE
> 2fSE9VBizGsgNL09PZScQG4xfBEBhVY09vbZWdzG22yfMwrBVF9GPotbA/cSu55o
> aO0m6E/GEO+5FrhAMdopuCJj/pQOrXXJWHaSd4EsOAlk0jrViAPqooa70CTvwr8Q
> ZWMlWVVf7nLf4sIcfVI+PgC9Uvo/aqUqfodqWWYEvgJoaY2oEITs+5tvUjdDDZwz
> +RFT7X5YRBtTU93yVgXruRCb41l8jE4oiym8E1EJUKGz/7UbteHR/8q5OfJc3uYe
> XqQII7bhH0pOgjvpAN/+9UrDngq1yPlgXDseu00L9PenTB8+HY5j/y7ida1pFWEL
> mcsorPQZ0HSgfEf2X0t6qZysRE7OQ12R/+XRpvW3tFdVd3mL8cnLWFDqsCXaIB1/
> ZyvbP+k4VVKJlPWoUdFvld3IeVluSybfhlgSuqeYJdHokCTT1nk2mERRwB89Pe3D
> cSu3qbXliHGUFhqINxCMVQjYnprDmyC6rP3LU8pGjshTVrESXI/Lq0EyPWNBRnhx
> Te7b0UVzaqQHAiyZIvH2
> =GfpO
> -----END PGP SIGNATURE-----
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Martin Rex <[email-masked]>
Date: Thu, 2 Feb 2012 21:21:58 +0100 (MET)

> As far as I can tell, it doesn't do anything to solve the problem Martin

Paul's wording did not address (2) of the (3) scenarios I
mentioned at all.

I called it "partial solution" because with creative reading
of PKIX rfc5280 section 6.1 the text could be interpreted to cover
one of the (3) scenarios that I described.

But creatively performing PKIX validation on a self-signed certificate
which the RP does *NOT* have in posession as trust anchor will provide
no security beyond a self-consistency check.

-Martin

---

From: Ondřej Surý <[email-masked]>
Date: Fri, 3 Feb 2012 08:55:12 +0100

+1 from me too.

O.