A DANE Record and DNSSEC Authentication Chain Extension for TLS
draft-ietf-tls-dnssec-chain-extension-07

[Ballot comment]
Now that TLS 1.3 is approved for publication, I think adding a Normative Reference to TLS 1.3 is no brainer. I am clearing my DISCUSS on the assumption that this would be fixed before publication of the RFC.

1) TLS 1.3 needs to be a normative reference, but it is not even listed in References.

2) The first mention of NSEC3 need a normative reference.

[Ballot comment]
I am happy to see this published, but have a few minor comments:

- I agree with Alexey's comments.

-3.4: "If the TLSA record set was synthesized by a DNS wildcard, the chain
  must include the signed NSEC or NSEC3 records that prove that there
  was no explicit match of the TLSA record name and no closer wildcard
  match."

Should that "must" be a "MUST"?

- Nit in Authors List: Unless I've missed something, Richard's affiliation is no longer current. (I only point it out in case it's an oversight; I have no objection if it's that way on purpose.)

[Ballot comment]
I was one of the very early DANE people / WG chair / etc.

Y'all have come along, commandeered our protocol..... and made it much better (and deployable)... . 
Seriously, thank you -- I was saving this document to be able to do a very thorough review, but unfortunately have run out of time, so only have one comment to offer: 

Section 3.1.  Protocol, TLS 1.2
"Therefore, a server MUST NOT construct chains for domain names other than its own." -- what is a servers' "domain name"? E.g: My webserver has certs with many SANs, and SNI, etc Perhaps this should be more along the lines of "MUST NOT construct chains for domain names which it is not responsible? (Obviously, this will also require some wordsmithing, I don't really know what it means to be "responsible" for a domain; perhaps "domains it doesn't have certificates for"? something...)

[Ballot discuss]
I think this is a useful document and I will ballot Yes once my small issues are resolved:

1) In 3.4:

  The first RRset in the chain MUST contain the TLSA record set being
  presented.  However, if the owner name of the TLSA record set is an
  alias (CNAME or DNAME), then it MUST be preceded by the chain of
  alias records needed to resolve it.  DNAME chains should omit

SHOULD? What are the implications if this is not followed?

  unsigned CNAME records that may have been synthesized in the response
  from a DNS resolver.

2) TLS 1.3 needs to be a normative reference, but it is not even listed in References.

[Ballot discuss]



This draft seems generally sound, but I believe there are pieces that
are still underspecified. These should be easy to fix.

the Signer's Name field in canonical form and the signature field
  excluded.
 
IMPORTANT: I'm not sure that this is actually sufficient to allow an
independent implementation without referring to the other documents. I
mean, I think I pretty clearly can't validate this chain from the
above. Similarly, although I think this is enough to break apart the
RRSETs into RRs, it doesn't tell me how to separate the RRSETs from
each other. I think you need to either make this a lot more complete
or alternately stop saying it's sufficient.



  abort the connection, the server uses the domain name associated with
  the server IP address to which the connection has been established.
IMPORTANT: "the domain name" is not unambiguous. Hosts can have multiple names for the same IP.


  DNSSEC authentication chain extension from a server, SHOULD use this
  information to perform DANE authentication of the server.  In order
  to do this, it uses the mechanism specified by the DNSSEC protocol

IMPORTANT: What happens if the DANE validates but the cert is revoked
or alternately the cert validates but DANE does not?


[RFC4035] [RFC5155].  This mechanism is sometimes implemented in a
  DNSSEC validation engine or library.
IMPORTANT: shouldn't it be a requirement to perform this validation?

[Ballot comment]


typically not be used for general DNSSEC validation of TLS endpoint
  names.
Can you rephrase this. I *think* it means "it's not used to validate the A/AAAA lookup"...?



  validation of endpoint names, but is more appropriate for validation
  of DANE TLSA records.
Same comment as abive



  This mechanism is useful for TLS applications that need to address
  the problems described above, typically web browsers or VoIP and XMPP
  applications.  It may not be relevant for many other applications.
Nit; cites to SIP/XMPP appropriate here,



  ClientHello message that the DNS authentication chain be returned in
  the (extended) ServerHello message.  If the server is configured for
  DANE authentication, then it performs the appropriate DNS queries,
This is not correct for TLS 1.3.



3.1.  Protocol, TLS 1.2
You should probably provide some guidance about whether the server should still provide the whole X.509 chain to the client. I believe with these semantics, the server cannot tell which DANE mode the client wants and therefore has to provide the entire chain.



  Servers receiving a "dnssec_chain" extension in the ClientHello, and
  which are capable of being authenticated via DANE, MAY return a
  serialized authentication chain in the extended ServerHello message,
Nit: I believe you want to remove the commas here, as they indicate a nonrestrictive clause.



  arbitrary domain names using this mechanism.  Therefore, a server
  MUST NOT construct chains for domain names other than its own.
"its own" is a bit fraught, as servers may not actually know all their domain names, at least at the TLS layer.. Can you be more specific about what the server algorithm is.



  Servers receiving a "dnssec_chain" extension in the ClientHello, and
  which are capable of being authenticated via DANE, SHOULD return a
  serialized authentication chain in the extension block of the
Why is this a SHOULD where the corresponding reqt for TLS 1.2 and below is a MAY?



  to a DNSSEC trust root.  This has the added benefit of mitigating an
  unknown key share attack, as described in [I-D.barnes-dane-uks],
  since it effectively augments the raw public key with the server's
"unknown key share (UKS)"



  handshake, to a domain name which has been validated as belonging to
  the owner name.
The key point here is that the commitment is bound to the EE key. Also, this only really works for TLS 1.3 and modes with EMS because otherwise there are other UKS attacks

I think you probably want to cite SIGMA and triple handhshake here.



            opaque AuthenticationChain<0..2^16-1>
Is 0 actually appropriate here as a lower bound? Presumably at least one such instance must be present?



            RR(i) = owner | type | class | TTL | RDATA length | RDATA
I assume the notation here is "i is the ith RR"?

Is there a reason not to describe this in TLS language?



            . DNSKEY
            RRSIG(. DNSKEY)
How does this differ from the algorithm that you would use in response to the TLSA query?


  the draft is adopted by the WG, the authors expect to make an early
  allocation request as specified in [RFC7120].
Do you want this to be marked RECOMMENDED?

[Ballot comment]
Two minor, mostly editorial comments:

1) Intro (sec 2): " It also provides the
  ability to avoid potential problems with TLS clients being unable to
  look up DANE records because of an interfering or broken middlebox on
  the path between the client and a DNS server."
Is that actually a well-known problem (can you provide a reference?) or would it be enough to say something like this:
" It also provides the
  ability to avoid potential problems with TLS clients being unable to
  look up DANE records when DNS server is not reachable."

2) IANA Considerations should probably be updated.

[Ballot comment]
I like this mechanism and look forward to its deployment. I have one point of
clarification and a small handful of editorial comments.

First, the point of clarification:

§4:

>  if the server does not recognize the
>  provided name and wishes to proceed with the handshake rather than to
>  abort the connection, the server uses the domain name associated with
>  the server IP address to which the connection has been established.

Unless I missed something important, this scenario doesn't seem to make much
sense: if the client provides name A and the server replies with name B, the
client either (1) isn't performing server name validation (in which case it is
nonsense for the client to ask for a dnssec_chain), or (2) is going to error
out the connection. Do I have that right? If there's some situation in which
the server acting as described above provides some benefit, I would love to
see it described in here. If it's just a matter of having completely described
behavior for corner cases, it may be worthwhile indicating that the client
will reject the connection if the server decides to complete the handshake
like this.

---------------------------------------------------------------------------

> Intended status: Standards Track                              R. Barnes
> Expires: July 27, 2018                                          Mozilla

s/Mozilla/Cisco/

---------------------------------------------------------------------------

§1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

This document has significant usage of these terms in lowercase. Please consider
using the boilerplate from RFC 8174 instead.

---------------------------------------------------------------------------

§3.3:

>  the case in DANE in which a client either ignores the name in
>  certificate (as specified in [RFC7671] or there is no attestation of

Nit: "...in the certificate..."

Nit: Add closing paren after [RFC7671]

---------------------------------------------------------------------------

§4:

>  specific processing needed for aliases and wildcards.  If DNS
>  responses messages contain any domain names utilizing name

Nit: "response"

[Ballot comment]
I like this mechanism and look forward to its deployment. I have one question
and a small handful of editorial comments.

First, the question:

§4:

>  if the server does not recognize the
>  provided name and wishes to proceed with the handshake rather than to
>  abort the connection, the server uses the domain name associated with
>  the server IP address to which the connection has been established.

Unless I missed something important, this scenario doesn't seem to make much
sense: if the client provides name A and the server replies with name B, the
client either (1) isn't performing server name validation (in which case it is
nonsense for the client to ask for a dnssec_chain), or (2) is going to error
out the connection. Do I have that right? If there's some situation in which
the server acting as described above provides some benefit, I would love to
see it described in here. If it's just a matter of having completely described
behavior for corner cases, it may be worthwhile indicating that the client
will reject the connection if the server decides to complete the handshake
like this.

---------------------------------------------------------------------------

> Intended status: Standards Track                              R. Barnes
> Expires: July 27, 2018                                          Mozilla

s/Mozilla/Cisco/

---------------------------------------------------------------------------

§1:

>  The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>  "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
>  document are to be interpreted as described in [RFC2119].

This document has significant usage of these terms in lowercase. Please consider
using the boilerplate from RFC 8174 instead.

---------------------------------------------------------------------------

§3.3:

>  the case in DANE in which a client either ignores the name in
>  certificate (as specified in [RFC7671] or there is no attestation of

Nit: "...in the certificate..."

Nit: Add closing paren after [RFC7671]

---------------------------------------------------------------------------

§4:

>  specific processing needed for aliases and wildcards.  If DNS
>  responses messages contain any domain names utilizing name

Nit: "response"

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Services Operator has completed its review of draft-ietf-tls-dnssec-chain-extension-06. If any part of this review is inaccurate, please let us know.

The IANA Services Operator understands that, upon approval of this document, there is a single action which we must complete.

In the ExtensionType Values registry on the Transport Layer Security (TLS) Extensions registry page located at:

https://www.iana.org/assignments/tls-extensiontype-values/

a single new value will be registered as follows:

Value: [ TBD-at-Registration ]
Description: dnssec_chain
Reference: [ RFC-to-be ]

We note that the authors have requested that the value 53 be used for this registration.

The IANA Services Operator understands that this is the only action required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm the list of actions that will be performed.


Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2018-02-07):

From: The IESG
To: IETF-Announce
CC: draft-ietf-tls-dnssec-chain-extension@ietf.org, Kathleen.Moriarty.ietf@gmail.com, Joseph Salowey , tls-chairs@ietf.org, shuque@gmail.com, joe@salowey.net, tls@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (A DANE Record and DNSSEC Authentication Chain Extension for TLS) to Proposed Standard


The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'A DANE Record and DNSSEC Authentication
Chain Extension for TLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This draft describes a new TLS extension for transport of a DNS
  record set serialized with the DNSSEC signatures needed to
  authenticate that record set.  The intent of this proposal is to
  allow TLS clients to perform DANE authentication of a TLS server
  without needing to perform additional DNS record lookups.  It will
  typically not be used for general DNSSEC validation of TLS endpoint
  names.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ballot/


No IPR declarations have been submitted directly on this I-D.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

As standards track RFC is requested as specified in the header of the draft.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This draft describes a new TLS extension for transport of a DNS
  record set serialized with the DNSSEC signatures needed to
  authenticate that record set.  The intent of this proposal is to
  allow TLS clients to perform DANE authentication of a TLS server
  without needing to perform additional DNS record lookups.  It will
  typically not be used for general DNSSEC validation of TLS endpoint
  names.

Working Group Summary

While the document does not share the same broad interest that TLS 1.3,
it does have good support from a segment of the working group.  It has
been reviewed by working group participants and DNS knowledgeable
folks outside the working group.  We do not know of any remainging
controversial issues.

Document Quality

The document has some initial prototype implementations
that are available for testing.  The getdns project is
planning on implementing against this draft.    The document
has good consensus within the working group


Personnel

The document shepherd is Joseph Salowey and the
responsible AD is Kathleen Moriarty.

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

The document has been reviewed by the document shepherd and is
ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

No

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

The document has been reviewed by members of the DNS community.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

No specific issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

Yes

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

No

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

The document has good consensus from the segment of the working
group that is interested in ti. 

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

No

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

No Nits.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

NA

(13) Have all references within this document been identified as
either normative or informative?

Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

No

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

No

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

No new registries are created and the updates are clear.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

No New registries

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

NA