Subject: Re: [dane] Publication request for draft-ietf-dane-use-cases

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Jul 2011 18:54:02 +0100

Thanks Ondřej,

Good job all.

My AD review below. Pretty much nits that are ok to
process along with any IETF LC comments you get. I'm
also ok if you ignore these if they trip over some
WG controversy that I've forgotten:-)

I've kicked off the IETF LC process for this. It'll
go on an IESG agenda soon after Quebec I expect.

Cheers,
S.

(1) Abstract: "PKIX trust hierarchies" is a bit odd. PKIX does
not force use of a hierarchy, but implementations have chosen to
take that approach. I think s/trust hierarchies,// would be fine.
I'd also s/Traditionally,/Typically,/ in that same sentence - its
not tradition, its according to the TLS spec and how browsers
have implemented that.

(2) DANE is really only addressing TLS server auth, except for
less common cases like xmpp server-to-server where both sides
would have a DNS name and could publish DANE records. I think
making this clear in the abstract would be good, and could be
most easily done by adding a bit to the end, e.g. "...that
support the TLS authentication process for TLS endpoints that
have associated DNS names." or equivalent.

(3) section 1, 2nd para - the term "source" domain may be
confusing and I think you could just omit the word "source" and
it'd be fine.

(4) Same para, suggest s/to a trust anchor/to a local trust
anchor/

(5) section 3, s/initial goal for DANE/initial goals for DANE/ ?

(6) section 3, last para, s/can applied/can be applied/ but I
wonder if "can" is right, so maybe s/can applied/may be
applicable/ is better.

(7) section 3.7, useful to expand EE on 1st use

(8) section 3.7, s/constraints can be made/constraints can be
expressed/ maybe.

(9) section 4, "Combination" bullet - "must allow multiple" may
lead to complexity - can you qualify or weaken that a bit to say
that simplicity is still important? Maybe just say that the DANE
mechanism MUST NOT be limited to a single statement per domain
name and leave the level of complexity to be handled during the
protocol work?

(10) Why are there normative references? If there's a reason then
I don't get why 2818 is informative - I think making them all
informative would be fine. (Other IESG members may disagree later
though, but moving them about is easy:-)

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 4 Jul 2011 16:17:25 -0400

Hey Stephen,

Thanks for the comments.  Couple of comments inline below.

--Richard

> not tradition, its according to the TLS spec and how browsers

Done:
s/trust hierarchies, rooted in/certificate chains rooted in/
s/Traditionally,/Typically,/

> have associated DNS names." or equivalent.

I would propose that "support the TLS authentication process" covers both server auth and client auth, especially given that we do specifically mention clients Section 2 and Section 3.  But if you feel strongly that we need to call this out in the Abstract, I can come up with some text.

> confusing and I think you could just omit the word "source" and

The term "source domain" is defined in RFC 6125:
"
source domain:  The fully qualified DNS domain name that a client
      expects an application service to present in the certificate
      (e.g., "www.example.com"), typically input by a human user ...
"
There's already a reference to RFC 6125 later in the paragraph, but we can push it up if you feel that would be clearer.

> (4) Same para, suggest s/to a trust anchor/to a local trust

Done:
s/to a trust anchor/to one of the client's trust anchors/

> (5) section 3, s/initial goal for DANE/initial goals for DANE/ ?

Done.

> wonder if "can" is right, so maybe s/can applied/may be

Done:
s/can applied to/are applicable to/

> (7) section 3.7, useful to expand EE on 1st use

Done (in section 3.4)

> (8) section 3.7, s/constraints can be made/constraints can be

Done:
s/constraints can be made/constraints can be expressed by which actors/

> name and leave the level of complexity to be handled during the

Done; added:
"
The precise types of combination allowed will be defined by the DANE protocol.
"

> though, but moving them about is easy:-)

Good point.  For now, I've reorganized to better align with the definition in RFC 3967, that normative references are ones that "must be read to fully understand or implement the subject matter in the new RFC".  In light of that:
Normative: 4033, 5246, 5280, 6125
Informative: 2595, 2818, 3207, 3261, 6120
In particular, RFC 2818 is informative because it's a specific application that uses TLS authentication (and thus possibly DANE).  Glad to reconfigure if other people feel differently

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 04 Jul 2011 23:14:23 +0100

Hi Richard,

I deleted all the "ok" bits.

> I would propose that "support the TLS authentication process" covers both server auth and client auth, especially given that we do specifically mention clients Section 2 and Section 3.  But if you…

I agree that you're correct. However, I'd like to head off
the possibility that someone thinks that DANE is going to
give every person a DNS naame and associated public key. (Or,
worse, require them to have a DNS name and key.) I realise
the WG don't need this clarification - it might however be
useful for folks that aren't familiar with DANE. (Remember
the abstract goes to the IETF announce list, which is a lot
of non-DANE folks.) But I don't feel so strongly as to insist.

> The term "source domain" is defined in RFC 6125:

Fair enough. Didn't spot that myself. Making it clearer
might be no harm if you like.

> The precise types of combination allowed will be defined by the DANE protocol.

Ok, but if the WG come back with a protocol that includes a
fully general language for expressing all possible policy
constraints including the ability to say that a public key is
only to be used on Irish national holidays, then I'll be
thinking of sending that back. I don't expect that to happen,
but the "must" (even if its not a "MUST") could be used to
argue for more complexity in the protocol, which seems like
a bad plan to me. Given we all get a shot at that debate
later, I'm not going to insist now.

> In particular, RFC 2818 is informative because it's a specific application that uses TLS authentication (and thus possibly DANE).  Glad to reconfigure if other people feel differently

Just a nit. Ignore at will.

Thanks,
S.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Mon, 4 Jul 2011 18:29:06 -0400

Couple of resolutions below...

> of non-DANE folks.) But I don't feel so strongly as to insist.

Added the following:
"
The main focus of this document is TLS server authentication, but it also covers TLS client authentication for applications where TLS clients are identified by domain names.
"

> might be no harm if you like.

Added reference to 6125.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 4 Jul 2011 18:59:34 -0400 (EDT)

On Mon, 4 Jul 2011, Stephen Farrell wrote:

> worse, require them to have a DNS name and key.)

But now you are doing the reverse, implying to those who see a bright
future for dane possibilities that it may never be used to authenticate
both client and server.

If you look at the TLS extension draft we just submited, all you need
to do client and server auth is to create a clientname extension equivalent
to servername.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Jul 2011 00:17:14 +0100

Lovely jubbly.
Thanks,
S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 05 Jul 2011 00:31:51 +0100

On 04/07/11 23:59, Paul Wouters wrote:
>>> I would propose that "support the TLS authentication process" covers
>>> both server auth and client auth, especially given that we do
>>> specifically mention clients Section 2 and Section 3.  But if you
>>> feel strongly that we need to call this out in the Abstract, I can
>>> come up with some text.
>>

Nope.

> to do client and server auth is to create a clientname extension equivalent

That may, or may not, be all that's needed. We don't need
to figure that out today.

My understanding is that the WG consensus is reflected by
Richard's additional phrase, and all I asked for is that the
abstract reflect that. I'm sure if Richard's suggestion (at
my prompting) goes against the WG consensus a bunch of
people will comment on that and it'll get fixed.

If more stuff gets done later, that's fine if its useful etc. but
I'm sure you're not suggesting your new I-D get reflected in the
abstract of the use-cases document right now.

S.