Subject: [dane] Feedback please: (WGLC for draft-ietf-dane-ops-07)

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 4 May 2015 05:37:29 +0000

On Mon, Apr 27, 2015 at 06:01:22PM +0000, Viktor Dukhovni wrote:

> This draft is normative for both the SRV and SMTP drafts which have
> progressed to the IESG and IETF LC respectively.  So it is important
> to get this reviewed and moving along the process.
> 
> Please read this draft carefully, and provide feedback as soon as
> you can.  I'm not available for editing from mid May through early
> June, so I'd like to see the WG LC complete before then, and be
> back in action to make any changes that come out of IETF LC in June
> (IETF LC last week of May, first week of June would work fine).

Really, nobody has any comments?  Surely the document is not that
perfect. :-)  If at all possible, please provide feedback soon!

-- 
	Viktor.

---

From: Warren Kumari <[email-masked]>
Date: Mon, 4 May 2015 13:11:28 -0400

> perfect. :-)  If at all possible, please provide feedback soon!

Yes please!

We need some more feedback from the WG to be able to call consensus.
This document has had some discussion earlier in it's life, but we'd
like the WG to express continued support for it...

W

>
> --
>         Viktor.
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 4 May 2015 18:01:07 -0700

On Apr 27, 2015, at 9:14 AM, Warren Kumari <[email-masked]> wrote:
> 
> Dear DANE WG,
> 
> The authors of draft-ietf-dane-ops have indicated that they believe
> that the document is ready, and have asked for Working Group Last Call
> (actually, they requested this a while back, we'd delayed while doing
> toe other docs...)
> 
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-dane-ops/
> 
> Please review this draft to see if you think it is ready for
> publication and send comments to the list, clearly stating your view.
> 
> This WGLC ends Mon 11-May-2015.

Sorry for the late review. This document is large, but it is also quite important for DANE deployment. In fact, it is probably as important for DANE deployment as the original TLSA document was. I found only two substantial issues in the document (I am sending editorial nits to the authors).

In Section 12, there is the question of whether or not the section is really useful. Yes, it is. For a long document such as this, an operator will want a checklist of changes from RFC 6698.

In Section 13, there is no justification for why TLSA records for HTTP servers should have a TTL an order of magnitude shorter than those for SMTP servers, and I can't think of one. Proposal: suggest all TLSA records have a TTL of an hour.

--Paul Hoffman

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 5 May 2015 05:38:32 +0000

On Mon, May 04, 2015 at 06:01:07PM -0700, Paul Hoffman wrote:

> In Section 13, there is no justification for why TLSA records for HTTP
> servers should have a TTL an order of magnitude shorter than those for
> SMTP servers, and I can't think of one. Proposal: suggest all TLSA records
> have a TTL of an hour.

Without necessarily disagreeing, the rationale was:

    * MTA to MTA SMTP is non-interactive store and forward, and
      moderately high latency (mail queueing until the problem is
      fixed) is tolerable, if sufficiently rare.

    * HTTP servers provide generally interactive services, where
      users might be less forgiving of a 1 hour outage.

Perhaps the right answer is to not suggest any particular TTL, but
just note the issue, leaving the choice of TTL to the reader...

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 5 May 2015 07:30:53 -0700

> just note the issue, leaving the choice of TTL to the reader...

That works for me as well, and is not onerous on the reader.

--Paul Hoffman

---

From: Brian Dickson <[email-masked]>
Date: Wed, 6 May 2015 12:57:32 -0700

I have reviewed the document, and believe it is ready for publication.
I do not have a strong opinion regarding including/excluding section
9, but if it makes the document cleaner, maybe it could go into its
own document? (I will go along with group concensus on this and this
is just a very weak suggestion.)

Brian Dickson

On Mon, Apr 27, 2015 at 9:14 AM, Warren Kumari <[email-masked]> wrote:
> In addition, to satisfy RFC 6702 ("Promoting Compliance with
> Intellectual Property Rights (IPR)"):
> Are you personally aware of any IPR that applies to
> draft-ietf-dane-ops?  If so, has this IPR been disclosed in compliance
> with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378 for more
> details.)
>
> Thanks,
> Warren Kumari
> (as DANE WG co-chair)
>
> --

---

From: nudge <[email-masked]>
Date: Thu, 07 May 2015 15:12:36 +0200

> perfect. :-)  If at all possible, please provide feedback soon!

Hi,

Perhaps it's just me, but doesn't this section have a rather obvious error in it ?

2.1.  Example TLSA record

   In the example TLSA record below:

   _25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
                              E8B54E0B4BAA815B06D3462D65FBC7C0
                              CF556ECCF9F5303EBFBB77D022F834C0 )

   The TLSA Certificate Usage is DANE-TA(2), the selector is Cert(0) and
   the matching type is SHA2-256(1).  The last field is the Certificate
   Association Data Field, which in this case contains the SHA2-256
   digest of the server certificate.

---- Ian Maddison

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 7 May 2015 14:52:25 +0000

>    digest of the server certificate.

Thanks, a typo.  Likely introduced when the numbers were made
symbolic.  Are there yet (or expected to be) any DNS zone file
parsers that consume the symbolic TLSA paramter names?  Similarly
any wire DNS record decoders that present the human-readable output
with TLSA parameters in symbolic form?

That is, should the examples use the symbolic names in the record
syntax, and not just in the text?

-- 
	Viktor.

Patch below:

--- a/draft-ietf-dane-ops
+++ b/draft-ietf-dane-ops
@@ -306,7 +306,7 @@
 
     <figure>
     <artwork>
-_25._tcp.mail.example.com. IN TLSA PKIX-TA Cert SHA2-256 (
+_25._tcp.mail.example.com. IN TLSA DANE-TA Cert SHA2-256 (
                            E8B54E0B4BAA815B06D3462D65FBC7C0
                            CF556ECCF9F5303EBFBB77D022F834C0 )
     </artwork>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 May 2015 11:08:00 +1000

>                               CF556ECCF9F5303EBFBB77D022F834C0 )

Which is a invalid TLSA record. "PKIX-TA", "Cert" and "SHA2-256"
should all be numbers. 

RFC6698 2.2.  TLSA RR Presentation Format

   The presentation format of the RDATA portion (as defined in
   [RFC1035]) is as follows:

   o  The certificate usage field MUST be represented as an 8-bit
      unsigned integer.

   o  The selector field MUST be represented as an 8-bit unsigned
      integer.

   o  The matching type field MUST be represented as an 8-bit unsigned
      integer.

   o  The certificate association data field MUST be represented as a
      string of hexadecimal characters.  Whitespace is allowed within
      the string of hexadecimal characters, as described in [RFC1035].

This is how named parses TLSA records.  Note there is *no* handling of
non numbers.  There is *no* intention to change this. 

        /*
         * Certificate Usage.
         */
        RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
                                      ISC_FALSE));
        if (token.value.as_ulong > 0xffU)
                RETTOK(ISC_R_RANGE);
        RETERR(uint8_tobuffer(token.value.as_ulong, target));

        /*
         * Selector.
         */
        RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
                                      ISC_FALSE));
        if (token.value.as_ulong > 0xffU)
                RETTOK(ISC_R_RANGE);
        RETERR(uint8_tobuffer(token.value.as_ulong, target));

        /*
         * Matching type.
         */
        RETERR(isc_lex_getmastertoken(lexer, &token, isc_tokentype_number,
                                      ISC_FALSE));
        if (token.value.as_ulong > 0xffU)
                RETTOK(ISC_R_RANGE);
        RETERR(uint8_tobuffer(token.value.as_ulong, target));

Now if you want to have descriptions then do something like this:

    _25._tcp.mail.example.com. IN TLSA (
			       0 ; PKIX-TA
			       0 ; Cert
			       1 ; SHA2-256 
                               E8B54E0B4BAA815B06D3462D65FBC7C0
                               CF556ECCF9F5303EBFBB77D022F834C0 )

Don't have unparsable records.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 8 May 2015 03:49:00 +0000

> Which is a invalid TLSA record. "PKIX-TA", "Cert" and "SHA2-256"

I have no problem with that.  What do we make of the text in RFC
7218:

    https://tools.ietf.org/html/rfc7218#section-1

       It is expected that DANE parsers in applications and DNS
       software can adopt parsing the acronyms for each field.

> non numbers.  There is *no* intention to change this. 

Should 7218 have an erratum filed to clarify that the acronyms are
not intended to be used in zone files?

Given that DNS software does not support non-numbers today, I am
fine with numbers in the document, so I'm just curious about the
apparent conflict with 7218.

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 08 May 2015 16:30:22 +1000

In message <[email-masked]>, Viktor Dukhovni writ
> not intended to be used in zone files?
 
Acronyms are not portable at the record level.  Additionally almost
no one constructs TLSA records by hand.  They all use tools.  Emitting
acronyms just means the records are not maximally readable.

---

From: Warren Kumari <[email-masked]>
Date: Tue, 12 May 2015 09:35:15 +0200

> This WGLC ends Mon 11-May-2015.

... and this WGLC ended yesterday. Olafur and I are at RIPE this week,
and will meet to discuss / call consensus....

W

---

From: Warren Kumari <[email-masked]>
Date: Thu, 14 May 2015 12:34:01 +0200

Dear DANE WG,

Olafur are at RIPE and had a chance to chat about this.

This WGLC has concluded.

We think that we have enough review, and see consensus for publishing
(after Viktor has had a chance to address the comments). We would have
liked to get even more comments, but the document has had significant
discussion over its lifecycle.

Thank you for your feedback.
W