Op 22-02-18 om 16:44 schreef Shumon Huque: > On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <p...@nohats.ca > <mailto:p...@nohats.ca>> wrote: > > On Wed, 21 Feb 2018, Shumon Huque wrote: > > Okay, got it. For people that have already implemented this, I think > there has been an implicit understanding that the format of the > chain > data is a sequence of concatenated wire format RRs exactly as > they appear > in a DNS message section > > > Note, I would not call it "sequence of concatenated wire format RRs", as > it is simply the wireformat of a DNS message. > > The fact that some parts > are concatenated RR's is just part of the wireformat of the DNS reply > message. That is, this isn't introducing some new form of concatenated > content - it is _just_ a regular DNS wire format message, and the > document should not go deeper into its explanation. > > > It would _not_ be correct to say that this is a "DNS wire format > message" - that > would mean there is a DNS header section with flags and response codes, > and other sections. The chain data structure as currently specified > really is > concatenated wire-format RRs (as they appear _within_ a DNS message > _section_). Let me know if that is unclear in the draft (or my proposed > edits). > > I recall at one point way back there was a discussion about whether the > chain > data should just be a fully formed DNS message, but I don't believe that > idea > had much support in the working group (personally I would have been fine > with > that choice too, if it did have support).
A DNS message is a 12 octet header followed by a question, followed by a list of RRs. The header does not contain any relevant information with respect to the chain query. The question is unnecessary, because only a TLSA record for the name and port of the service (or a secure path from the name of the service, via CNAME or DNAME to the name of the TLSA RRset), is acceptable for a client, so a client would have to disregard the question in a DNS message anyway. The list of RRs remains and is sufficient for the DNSSEC chain extension. A response of a rfc7901 EDNS chain query can be used almost directly as the content for the extension. You just have to strip/skip the irrelevant data from the front of the message (i.e. the 12 byte header, the query name and 8 octets type/class/ttl). > I noticed some discussion about the ordering of this content. I am not > sure why that should be done. DNS doesn't care about the order, and > neither should producers or consumers of this extension. DNS has no > ordering inside its message. > > > Yes, that is in fact where we ended up, roughly. > > The draft does currently say that the answer record(s) appear first. And > then > the authentication chain records follow and that TLS client should be > prepared > to receive the authentication chain records in any order. > > Requiring the answer records first seems logical to me - it is what > existing > libraries do, and also what the EDNS chain query spec does (answer records > appear first in the ANSWER section, and DNSSEC authentication chain records > appear in the AUTHORITY section in any order). > > There is some residual wording in the draft about ordering of CNAMEs etc in > the answer records part. Assuming the WG agrees, I am fine with relaxing > that requirement - that ended up in there because although there is no > defined > ordering of RRs within a DNS message section, as a practical matter CNAMEs > are almost always ordered since there are some DNS queriers that get > confused > otherwise. This is a new protocol though, so we can be more faithful to > the DNS > spec. > > I don't think getting unrelated DNSSEC records would be an issue. TLS > has its maximum sizes for the handshake. In fact, it could allow the > extension to have some useful data in the case of MX or SRV. (and could > be a feature to build a nice resolver over TLS using 1 tor circuit). > > > The draft currently doesn't address the MX or SRV use case. I suggest > that we tackle that in a future version. > > I'm also not sure about the talking of unsigned CNAME records from > DNAME. The above pseudo code (extended with special cases) should be > in some DNS library, and that library will know what records to expect > unsigned which are proven by the DNAME (or wildcard) synthesis and knows > when/if to add it to the validated cache. I don't think that should be > explained in this RFC at all. The DNS implementation does not need > to be specified in this document and it should just focus on saying > that "the DNS message response is validated and upon validation the > content can be considered DANE validated". > > > Where we ended up, is that WG participants asked for some level of DNSSEC > detail to be included in this doc. > > Shumon. > _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
