IETF conflict review for draft-dukhovni-tls-dnssec-chain

Note: This ballot was opened for revision 00 and is now closed.

Ballot question: "Is this the correct conflict review response?"

Benjamin Kaduk Yes

Comment (2021-05-27 for -00)

There's a couple points that I want to raise for the IESG's attention as
they evaluate whether the current "no conflict" response is correct.

(1) There is a note in Section 4 that:

                                                               If a
   record in the chain has a very short TTL (eg 0 up to a few seconds),
   the server MAY decide to serve the authentication chain a few seconds
   past the minimum TTL in the chain.  [...]

This seems like what's going to happen regardless of what we say, but I
just wanted to raise its visibility in case anyone felt otherwise.

(2) Section 7 says:

   For a non-zero saved value of the ExtSupportLifetime element of the
   extension, TLS clients MUST mandate ("pin") the use of this extension
   by the corresponding TLS servers for the time period specified by the
   pinning value.  [...]

The wording here is perhaps more sensitive than it first appears.  As
written it seems to say that the client must require the server to use
the extension, but the server is only allowed to use the extension if the
client requests it first.  I note that for a recent similar case on the IETF
stream, I entered a DISCUSS ballot
I expect that the authors will be willing to change the wording (per the
COMMENT, a simple s/use of/support for/ would work), but even with the
current formulation, it's not clear that a "violates IETF procedures"
conflict-review response is appropriate.  In particular, this says that
the client has to require the server to send the extension, but not that
the server actually does have to send the extension.  So the combination
of this requirement on the client with the TLS requirement on the server
would result only in a broken exchange, but not (AFAICT) behavior that
violates the TLS specification.


Since I was reading the document anyway, I took the opportunity to
record some comments (as well as some nit-level remarks that are
unlikely to merit a response, in a separate section).  Hopefully the
authors and ISE find them useful and treat them as they would any other
review of the document.

First off, thanks for continuing with this work even after the TLS WG
was unable to come to consensus.  It's good to have this technology
written up and published, and I think you did a good job writing up the
portions that are "new" with respect to the WG draft (as well as the
security considerations thereof!).

Section 1

   In the absence of TLSA records, this extension conveys the required
   authenticated denial of existence.  Such proofs are needed to
   securely signal that specified TLSA records are not available so that
   TLS clients can safely fall back to WebPKI based authentication if
   allowed by local policy.  [...]

(While there was a lot of discussion in the TLS WG about WebPKI vs DANE,
TLS itself, even with X.509 PKI or PKIX, is not limited to just the
WebPKI as trust anchors.)

   This extension also mitigates against an unknown key share (UKS)
   attack [I-D.barnes-dane-uks] when using raw public keys, since the
   server commits to its DNS name (normally found in its certificate)
   via the content of the returned TLSA RRset.

I think the situation here may be slightly more subtle, as there is
(AFAIR) not anything that prevents the server from stuffing in random
unrelated TLSA RRs in what it sends back to the client.  That is, there
may not be a single "the returned TLSA RRset".  However, the server does
commit to its DNS name, since we assert that the semantics of using this
extension is that the server accepts the SNI name sent by the client.
(Presumably this holds regardless of whether the server also sends the
SNI extension back in SH(1.2)/EE(1.3).)  The content of the TLSA RRset
(for that name) is used in validating that the server is in fact
authenticated as that name, but committing to the DNS name is done via a
different mechanism.

Section 2.1

   The set of supported combinations of port number and SNI name may be
   configured explicitly by server administrators, or could be inferred
   from the available certificates combined with a list of supported
   ports.  It is important to note that the client's notional port
   number may be different from the actual port on which the server is
   receiving connections.

I might further make the connection that the "client's notional port
number" is the one that's in the configured list of supported ports, not
the actual port on which the server is listening.

Section 2.2

I strongly suggest reiterating that the server does not send anything if
the extension is not present in the ClientHello.

   In TLS 1.3 [RFC8446], the server adds its "dnssec_chain" extension to
   the extension block of the Certificate message containing the end
   entity certificate being validated, rather than to the extended
   ServerHello message.

This is clear and unambiguously specified, and in that sense
unobjectionable.  It's a little weird to put something that's mostly
about a CA cert in the extension block for the EE cert (for the
PKIX-TA()0) and DANE-TA(2) certificate usage values), but probably not
worth introducing more complications for.  (The pinning lifetime is not
about the CA cert, though, of course.)

   TLS servers supporting this extension that do not have a signed TLSA
   record MUST instead return a DNSSEC chain that provides authenticated
   denial of existence.  [...]

I suggest to reiterate that this is a denial of existence for the SNI
name in the ClientHello, as opposed to some arbitrary name by which the
server identifies itself.

Section 6

   Clients MAY cache the server's validated TLSA RRset to amortize the
   cost of receiving and validating the chain over multiple connections.
   The period of such caching MUST NOT exceed the TTL associated with
   those records.  [...]

How does the caching interact with the extension pin time?  (I would
expect "SHOULD NOT exceed the pin time", but don't see anything to
justify a strict requirement to do so.)

   Note that when a client and server perform TLS session resumption the
   server sends no "dnssec_chain".  This is particularly clear with TLS
   1.3, where the certificate message to which the chain might be
   attached is also not sent on resumption.

I'd suggest a reminder that "if the client is attempting resumption, it
still sends the "dnssec_chain" extension for use if resumption fails and
a full handshake is needed" (or similar; it's not required, but the
mechanism won't be available if not sent).

Section 7

   For a non-zero saved value of the ExtSupportLifetime element of the
   extension, TLS clients MUST mandate ("pin") the use of this extension
   by the corresponding TLS servers for the time period specified by the
   pinning value.  [...]

The wording here is perhaps more sensitive than it first appears.  As
written it seems to say that the client must require the server to use
the extension, but that cannot be universally true, since the TLS
specification requires the server to *not* use the extension if the
client doesn't offer it in the ClientHello.  If we talk about "support
for" rather than "use of", this concern goes away (and there are surely
other ways to finesse the language as well).  If this document was on
the IETF stream I would put a DISCUSS on it until this point is
clarified (see, e.g.,,
though I am hopeful that it can be fixed without incurring the overhead
of a "violates IETF procedures for TLS" conflict-review response.

                   If during this time, the TLS client does not have a
   valid TLSA record and connects to a TLS server using this extension
   for the associated name and port, and it does not obtain a valid
   authentication chain in this extension, it MUST either abort the

(Similarly, it's not entirely clear that "does not have a valid TLSA
record" is really relevant for the criterion here, it seems to be enough
that the client asks, regardless of what the client may also have on
hand already.)

   connection or delay communication with the server via the TLS session
   until it is able to obtain valid TLSA records (or non-existence
   proof) out of band, such as via direct DNS lookups.  If attempts to
   obtain the TLSA RRset out of band fail, the client MUST abort the TLS

We switch from "connection" to "session" here.  Both are used as terms
of art in TLS (with different meaning); is the change intentional?
(I would, perhaps naively, have assumed that "connection" is intended

Section 9

   Delivery of application services is often provided by a third party
   on behalf of the domain owner (hosting customer).  Since the domain
   owner may want to be able to move the service between providers, non-
   zero support lifetimes for this extension should only be enabled by
   mutual agreement between the provider and domain owner.

Is it true that the upper bound on the time that clients are expected to
continue to use a pin is actually the nominal (advertised) pin time plus
the relevant DNS TTL in effect at the time (since the server could
continue to serve the extension with those DNS records for that
duration)?  This might be an operational consideration worth mentioning
(that the DNS TTL as well as the advertised pin time are to be
considered in assessing the impact of switching providers without
coordinating the pin expiry).

   To avoid confusion, it is RECOMMENDED that server operators not
   publish TLSA RRs (_port._tcp. + base domain) based on the expanded
   CNAMEs used to locate their network addresses.  Instead, the server
   operator SHOULD publish TLSA RRs at an alternative DNS node (as in
   the example above), to which the hosting customer will publish a
   CNAME alias.  This results in all clients (whether they obtain TLSA
   records from DNS directly, or employ this extension) seeing the same
   TLSA records and sending the same SNI name.

I suspect I'm confused, but I'm failing to see how a client that follows
the RFC 7671 CNAME expansion would end up at the provider-published TLSA
record in this scenario (that is, at _dane443.node1.provider.example in
the example above).  Wouldn't they look for
_443._tcp.node1.provider.example and get nothing back?

Section 11

Since the extension contents sent by the server contains an unonrdered
bag of DNS records, we may want to discuss the possibility that the
server sends records unrelated to DANE authentication of itself, and
what steps the client can/should take in such scenarios in order to
remain in a safe state.

   This could be achieved by running a time synchronization protocol
   like NTP [RFC5905] or SNTP [RFC5905], which are already widely used

I note that RFC 8915 (network time security for NTP) has been published
since tls-dnssec-chain was started.  It seems like it would be a useful
reference here as well (albeit perhaps not as "already widely used").

Section 14

I don't see much reason for RFCs 7858 and 8310 to be classified as normative.
(draft-ietf-dnsop-svcb-https is also perhaps borderline, but we do place
some requirements on servers when they are the target of such records,
so it seems okay to leave as normative.)

Appendix A

I'm happy to see that a lot of thought and care went into producing the
examples.  Sadly, I'm not in a position to actually verify them in a
useful way.
(I guess I did seem to get a different certificate from than
the one listed here, but that doesn't seem worth worrying about.)



   This document describes an experimental TLS extension for in-band
   transport of the complete set of DNSSEC validated records needed to
   perform DANE authentication of a TLS server without the need to
   perform separate out-of-band DNS lookups.  [...]

The word "validate" here causes me to stumble.  While we do expect the
TLS server to have validated the records before sending, that's not a
key part of the protocol -- the TLS client independently performs DNSSEC
validation in order to get the value out of having the records.  It
would read better to me if we dropped the word entirely, or maybe
switched it to "validatable".
(Essentially the same text is in the Introduction as well.)

Section 1.1

   The mechanism described in this document, is intended to be done with
   applications on the wider internet.  One application of TLS well

No comma needed.
s/done with/used by/

   In fact, one of the authentication methods for DNS over TLS _is_ the
   mechanism described in this document, as specified in Section 8.2.2
   of [RFC8310].

If I was feeling pedantic I'd say "a precursor to" or similar, since the
mechanism is only essentially the same.

   The need for the mechanism when DANE authenticating DNS over TLS
   resolver is obvious, since DNS may not be available to perform the

s/the mechanism/this mechanism/ or s/the mechanism/such a mechanism/
Also, s/authenticating/authenticating a/

   In the TLS working group, concerns have been raised that the pinning
   technique, as described in Section 7 would complicate deployability

Either two commas around "as described in Section 7" or zero.

Section 2.1

   Otherwise, the server's extended ServerHello message MUST contain a
   serialized authentication chain using the format described below.  If
   the server does not have access to the requested DNS chain - for
   example due to a misconfiguration or expired chain - the server MUST
   omit the extension rather than send an incomplete chain.  [...]

Pedantically, the two MUSTS seem to be in conflict.  (The first one is
maybe not needed, for "ServerHello message contains".)

   HTTPS or SVCB records MUST be provisioned to process client
   extensions based on the client's logical service endpoint's SNI and
   port as it is prior to HTTPS or SVCB indirection.

Other than here, we're pretty consistent about saying "SNI name" or "SNI
hostname" when we're not talking about the extension itself.  (I suppose
we could pick one of "name" and "hostname", too, though that does not
seem to bother me as much.)

Section 2.3

   The returned RRsets MUST contain either the requested TLSA RRset, or
   else the associated denial of existence proof.  In either case, the
   chain of RRs MUST be accompanied with the full set of DNS records
   needed to authenticate the TLSA record set or its denial of existence

s/the TLSA record set/the requested TLSA record set/

   When some subtree in the chain is subject to redirection via DNAME
   records, the associated inferred CNAME records need not be included,
   they can be inferred by the DNS validation code in the client.  [...]

The second comma is a comma splice.

   In the case of a denial of existence response, the authentication
   chain MUST include all DNSSEC signed records from the trust-anchor
   zone to a proof of non-existence of either the (possibly redirected
   via aliases) TLSA records or else of an insecure delegation above or
   at the (possibly redirected) owner name of the requested TLSA RRset.

As written, this says that there is a "proof of non-existence of an
insecure delegation" in the case where an insecure delegation is
involved and a denial of existence is needed.  This does not match my
understanding (though my understanding could be flawed) -- I thought
that affirmative evidence of an insecure delegation (that is, proof of
non-existence of a *secure* delegation) was used in a denial of existence

   The following is an example of (hypothetical) insecure delegation of
   "" from the ".com" zone.  This example shows NSEC3 records
   with opt-out.

An (informative) referece to RFC 5155 for NSEC3 might be in order. NSEC3 (1 1 0 -
     onib9mgub9h0rml3cdf5bgrj59dkjhvl NS DS RRSIG)

I find it rather implausible that a "real" example would produce hashed
owner name and next hashed owner name that differ only in the last
character :)

I'm also having a bit of a hard time reproducing the hashed owner name
as onib9mgub9h0rml3cdf5bgrj59dkjhvj.  If I'm reading it right, the hash
is 1 (SHA-1), iteration count 0, and salt empty ('-'), so I should be
looking at something like:

$ printf "\x07example\x03com\x0"|sha1sum|unhex |base32|tr [A-Z] [a-z]

But I assume I'm just making a dumb error somewhere and the examples are
actually correct.

Section 8

   The trust anchor may change periodically, e.g. when the operator of

comma after "e.g." (as well as before).

Section 15

It's a bit surprising to use [HAMPERING] as the slug for what seems to
be a research paper that collected data on the availability of DNSSEC
aware and validationg resolvers to stub resolvers.

Alvaro Retana No Objection

Erik Kline No Objection

Comment (2021-05-29 for -00)
No email
send info
I support requesting the authors to consider Ben's comments.

Lars Eggert No Objection

Comment (2021-05-31 for -00)
Using lowercase "not" together with an uppercase RFC2119 keyword is not
acceptable usage. Found: "SHALL not", "MUST not"

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via, so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 2, paragraph 4, nit:
-    In the absense of TLSA records, this extension conveys the required
-                ^
+    In the absence of TLSA records, this extension conveys the required
+                ^

Section 2, paragraph 6, nit:
-    This extension also mitigates againts an unknown key share (UKS)
-                                        -
+    This extension also mitigates against an unknown key share (UKS)
+                                       +

Section 3.3, paragraph 20, nit:
-    equal to or is the closest ancestore of the requested TLSA RRset, and
-                                       -
+    equal to or is the closest ancestor of the requested TLSA RRset, and

Section 3.3, paragraph 24, nit:
-        intermediate betwen the requested name the owner of the DNAME
+        intermediate between the requested name the owner of the DNAME
+                         +

Section 6, paragraph 5, nit:
-    Clients MAY cache the server's validated TLSA RRset to ammortize the
-                                                             -
+    Clients MAY cache the server's validated TLSA RRset to amortize the

Section 7, paragraph 4, nit:
-    extension.  A non-zero extenion pin value received MUST ONLY be used
-    if the extention also contains a valid TLSA authentication chain that
-                ^
+    extension.  A non-zero extension pin value received MUST ONLY be used
+                                +
+    if the extension also contains a valid TLSA authentication chain that
+                ^

Section 7, paragraph 7, nit:
-    Upon completion of a full validated hanshake with a server that
+    Upon completion of a full validated handshake with a server that
+                                           +

Section 10, paragraph 3, nit:
-    it must properly decommission its use.  If a non-zero pin lifetim is
+    it must properly decommission its use.  If a non-zero pin lifetime is
+                                                                     +

Section 3.3, paragraph 13, nit:
> , the chain of RRsets MUST be accompanied with the full set of DNS records n
>                               ^^^^^^^^^^^^^^^^
The usual collocation for "accompany" is "by", not "with".

Section 3.3, paragraph 15, nit:
> et at the requested domain name. 2. An signed SOA record and signed NSEC or
>                                     ^^
Use "A" instead of 'An' if the following word doesn't start with a vowel sound,
e.g. 'a sentence', 'a university'.

Section 3.3, paragraph 22, nit:
> hain that disproves the existence of a a secure delegation to - or of - the T
>                                      ^^^
Maybe you need to remove one determiner so that only "a" or "a" is left.

Section 3.3, paragraph 25, nit:
> ot). This trust anchor is also preconfigured in the TLS client, but includin
>                                ^^^^^^^^^^^^^
Do not mix variants of the same word ('preconfigure' and 'pre-configure')
within a single text.

Section 6, paragraph 4, nit:
> ure against such downgrade attacks. It's value represents the number of hours
>                                     ^^^^
It seems that the possessive pronoun "its" fits better in this context.

Section 14.1, paragraph 12, nit:
> te is valid, which is in between November 28 2018 and December 2 2020, with t
>                                  ^^^^^^^^^^^
Commas set off the year in a month-day-year date: "November 28,".

Section 14.1, paragraph 12, nit:
>  in between November 28 2018 and December 2 2020, with the following root tr
>                                  ^^^^^^^^^^
Commas set off the year in a month-day-year date: "December 2,".

Obsolete reference to RFC5246, obsoleted by RFC8446 (this may be on purpose).

These URLs in the document can probably be converted to HTTPS:

Martin Duke No Objection

Murray Kucherawy No Objection

Comment (2021-06-02 for -00)
I support requesting the authors to consider Ben's comments.

Robert Wilton No Objection

Roman Danyliw No Objection

Comment (2021-06-02 for -00)
No email
send info
I support requesting the authors to consider Ben's comments.

Warren Kumari No Objection

Comment (2021-06-02 for -00)
I am balloting No Objection. What I actually *want* to ballot is "this is work which *should* have been done in the IETF, but I understand why it wasn't", but, strangely, that button doesn't exist....

It's good work, and I wish it could have been easier to get through the process; thanks authors!

Zaheduzzaman Sarker No Objection

Comment (2021-06-02 for -00)
No email
send info
coping what Erik wrote - "I support requesting the authors to consider Ben's comments."

Éric Vyncke No Objection

Comment (2021-06-01 for -00)
I suggest to add DPRIVE to the list of related WG as it is vaguely related.