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

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 04 Aug 2015 10:05:12 -0700

Alissa Cooper 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:
----------------------------------------------------------------------

Thanks for working on this.

I agree generally with the editorial comments others have already made
and I have a few more.

Section 4: 
s/generally RECOMMENDED./RECOMMENDED./
s/a mixture of clients; some supporting/a mixture of clients, some
supporting/

Section 4.2:
I note that this section is silent about the interaction between CT and
the PKIX-TA(0) and PKIX-EE(1) usages. I'm assuming the implication is "go
ahead and use CT if you want to in those cases," but whatever it is,
might it be worth making it explicit here?

Section 10.3:
"A service with DNSSEC-validated TLSA records implicitly promises TLS
   support.  When all the TLSA records for a service are found
   "unusable", due to unsupported parameter combinations or malformed
   associated data, DANE clients cannot authenticate the service
   certificate chain.  When authenticated TLS is mandatory, the client
   SHOULD NOT connect to the associated server."

Seems like that last requirement should be a MUST NOT.

Section 14:
"When TLS is opportunistic, the client MAY proceed to use
   the server with mandatory unauthenticated TLS."

I find the use of the word "mandatory" here confusing -- what is
mandatory in the opportunistic case? Seems like this would make more
sense without the word "mandatory."

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 4 Aug 2015 17:34:49 +0000

> s/a mixture of clients; some supporting/a mixture of clients, some

Sure.

> might it be worth making it explicit here?

Yes, full steam ahead with PKIX-TA/PKIX-EE.  I'll add something
suitably concise to that effect.

> Seems like that last requirement should be a MUST NOT.

Yes, MUST NOT will do.

> sense without the word "mandatory."

Good catch, this is unclear.  When the client is using TLS and DANE
opportunistically, and finds TLSA records all which happen to be
"unusable", to avoid downgrade attacks to cleartext, it MUST still
use TLS, but without (DANE) authentication (which is not possible).

This is already specified in the SRV and SMTP drafts.  In this
draft it is stated more generally.

Will fix.

-- 
	Viktor.