Subject: [dane] Barry Leiba's No Objection on draft-ietf-dane-ops-14: (with COMMENT)

From: "Barry Leiba" <[email-masked]>
Date: Wed, 29 Jul 2015 08:17:28 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-dane-ops-14: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dane-ops/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Editorial comments only -- most very minor, but one for Section 4 and its
subsections is more substantive.

-- Section 1 --

   DNSSEC validated DANE TLSA
   records can be used to augment or replace the use of trusted public

Too many cascading modifiers can make a sentence confusing (even if you
were to hyphenate "DNSSEC-validated", as it should be).  I suggest
untangling that slightly, this way:

NEW
   DANE TLSA records validated by
   DNSSEC can be used to augment or replace the use of trusted public
END

   [RFC6698] defines three TLSA record fields with respectively 4, 2 and
   3 currently specified values.

There's nothing to correspond with "respectively" here (compare that with
the correct use in the first paragrah of the Introduction).  Try this:

NEW
   [RFC6698] defines three TLSA record fields, the first with 4 possible
   values, the second with 2, and the third with 3.
END

-- Section 3 --
A bit of awkward wording here, and an overly long sentence, both easily
fixed:

OLD
   When a servers does
   support SNI, but is not configured with a certificate chain that
   exactly matches the client's SNI extension, SHOULD respond with some
   other (default or closest match) certificate chain, since clients may
   support more than one server name, but can only put a single name in
   the SNI extension.
NEW
   When a server supports SNI but is not configured with a certificate
   chain that exactly matches the client's SNI extension, the server
   SHOULD respond with another certificate chain (a default or closest
   match).  This is because clients might support more than one server
   name, but can only put a single name in the SNI extension.
END

-- Section 4 --

   Protocol designers need to carefully consider which set of DANE
   certificate usages to support.

I'm not sure why this (and the next sentence) is referring to "protocol
designers".  Is this not aimed at implementation/deployment choices?  If
that's not correct, who are the targets for this advice?

I also find this section to be rather hard to follow -- I can't clearly
figure out what the advice really is.  Can you do a little reorganization
here, separating the advice out from the explanation of why?  I don't
care whether you put the explanation first or the advice first, but it
would help to have one paragraph that says, clearly and without fuss,
what the recommendation is.  This applies to the subsections as well.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 29 Jul 2015 17:05:05 +0000

>    DNSSEC can be used to augment or replace the use of trusted public

Thanks, done.

>    values, the second with 2, and the third with 3.

Thanks, done.

>    name, but can only put a single name in the SNI extension.

Thanks, done.

> that's not correct, who are the targets for this advice?

This should likely say "application protocol designers".  The point
being that the use of DANE TLSA RRs in a particular application
(as with e.g. SMTP) can be defined (more specifically than in
RFC6698 and this draft) by an application-specific standard.

> what the recommendation is.  This applies to the subsections as well.

Will try to clarify, this will take more time.  Should the two
smaller changes above be pushed as -15, while section 4 is polished?

-- 
	Viktor.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 30 Jul 2015 09:17:54 +0200

Hi, Viktor; thanks for the quick response, and thanks for making the changes.

> RFC6698 and this draft) by an application-specific standard.

Ahhhh, of course; I get it now.  Thanks for the explanation.  Yes,
maybe you can say "designers of DANE profiles", or "designers of DANE
applications", or some such.  Please pick the correct wording.

> Will try to clarify, this will take more time.

Of course, and many thanks for considering it.

> Should the two

I would say yes (revisions are cheap), but you should check with your
responsible AD.

Barry