Subject: [dane] (Belated) Resolutions from Taipei.

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Dec 2011 13:12:44 -0500

What with one things and another, we get distracted and didn't do what we promised...

During the Taipei meeting we discussed the open issues, and resolutions were discussed and proposed (to be approved by the list). Some of these needed text (#8, #10, #36; incorporated into -13), but for some of them there was no action needed.

So, unless I hear very strong objections, we are closing issues were it was felt no action needed:
Issue #23
          Idea: Use DANE to assert that no TLS services exist at specified host
          and port
          Proposal: Defer to a separate document, don't address in the base
          specification
 	  Text for issue tracker: "This is being deferred to a separate document. We are making the issue as closed, will tag it with a keyword ("revisit") so we can find it easily again if we want additional work in the future :-P"

Issue # 38
          Idea: Enable support for DANE within EAP-FAST
          Proposal: Do nothing in the protocol specification.
          ***
          No objects to this proposal
          ***
          CONCLUSION: Do nothing in the protocol document
          Text for issue tracker: "This issue is being closed, marked as "wontfix""

For issues number #8, #10 and #36, the authors were asked to incorporate text -- the text for #36 has already been discussed onlist and consensus reached.
The WG is requested to please confirm (silence will be considered consent!) that they accept the text incorporated to address issues #8 and #10, so that we can close these issues too.
Once this is done we will (as threatened) open #37...

W

---

From: Zack Weinberg <[email-masked]>
Date: Tue, 20 Dec 2011 10:31:57 -0800

>          Text for issue tracker: "This is being deferred to a separate document. We are making the issue as closed, will tag it with a keyword ("revisit") so we can find it easily again if we want…

I'm fine with this resolution, but I suggest that in this document,
opcode 0 should be reserved (in all three code bytes) for a
hypothetical future "no TLS services at this extended name" record,
sliding the existing codes down one.

zw

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 20 Dec 2011 10:59:36 -0800

> sliding the existing codes down one.

That proposal is the opposite of "defer", and also makes "0" special. When the issue comes up in a separate document, the codes can be assigned there. Application developers will understand "4 means no TLS" as well as they would "0 means no TLS".

I support the decision in Taipei to actually defer this.

--Paul Hoffman

---

From: Warren Kumari <[email-masked]>
Date: Tue, 20 Dec 2011 17:10:38 -0500

> The WG is requested to please confirm (silence will be considered consent!) that they accept the text incorporated to address issues #8 and #10, so that we can close these issues too.

Just to clarify (and to stop folk having to run the diffs themselves):

Text added to satisfy  #8:

 	   Clients that validate the DNSSEC signatures themselves SHOULD use	
 	   standard DNSSEC validation procedures.  Clients that do not validate	
 	   the DNSSEC signatures themselves MUST use a secure transport (e.g.,	
 	   TSIG [RFC2845], SIG(0) [RFC2931], or IPsec [RFC6071]) between	
 	   themselves and the entity performing the signature validation.

Text added to satisfy  #10:
           If a server's certificate is revoked, or if an intermediate CA in a	
 	   chain between the end entity and a trust anchor has its certificate	
 	   revoked, a TLSA record with a certificate type of 2 that matches the	
 	   revoked certificate would in essence override the revocation because	
 	   the client would treat that revoked certificate as a trust anchor and	
 	   thus not check its revocation status.  Because of this, domain	
 	   administrators need to be responsible for being sure that the key or	
 	   certificate used in TLSA records with a certificate type of 2 are in	
 	   fact able to be used as reliable trust anchors.

Text added for #36 is in the issue tracker, consensus was called last week.

> Once this is done we will (as threatened) open #37...

As many folk have vacations and other distractions at this time of year, the opening of #37 will not happen till early / mid January...

W

---

From: Jakob Schlyter <[email-masked]>
Date: Wed, 21 Dec 2011 07:45:16 +0100

> That proposal is the opposite of "defer", and also makes "0" special. When the issue comes up in a separate document, the codes can be assigned there. Application developers will understand "4 mean…

FWIW, and although I agree with Paul H that zero is not special, I do like the esthetics if reserving zero.

	jakob

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Dec 2011 07:32:42 -0800

> FWIW, and although I agree with Paul H that zero is not special, I do like the esthetics if reserving zero.

Sure, but Zack wasn't proposing "reserving", he was proposing "reserve for this future use, at which point it would be allocated". Short-lived aesthetics are not so interesting.

--Paul Hoffman