On Thu, 22 Feb 2018, Shumon Huque wrote:
On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <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).
So it was decided to not use a full DNS packet format? And then since you
miss the structure of the Answer Section and Additional/Authority
Section, you require the "answer RR's" come first where you basically
emulate an Answer Section?
Isn't that an indication that we should really use the wireformat of an
entire DNS message here? Maybe some DNS library/tools people can chime
in here to tell us if this matters much to them (assuming they are
adding support for creating/consuming these chains of RRsets in wire
format.
I am personally a little sad we cannot have a dig +chainquery command
where we write out the entire answer packet format to a blob, to be loaded by
the TLS server. And where a TLS client cannot just hand over the blob
"as if it came in as a reply from a DNS server" to its DNS/cache
receiving code path.
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).
Do you remember why not? I'll see about checking the archives, but to me
the hint that you are losing information and require some kind of
ordering seems to suggest there is a need for using the full DNS message
reply format.
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 would prefer the residual wording to go away. Any hints at order being
important should be squashed.
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.
Jus make sure the document doesn't forbid any such data, and allow the
client to ignore these or put them in the cache as it sees fit.
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.
Again, that will only lead to bad implementations. There should be no
need to update this document once something like ANAME, ALIAS or ZNAME
is introduced to the DNS. So you should not talk about these things at
all. TLS client should use a dns library that knows these things, or if
they want to write one from scratch, these implementors should look at
the DNS RFCs and not this RFC for guidance on how the DNS protocol
works.
Paul
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
