Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Paul Wouters <[e-mail]>]

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.

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. In pseudo code, they should simply:

while(not stuck and not empty(RRlist)):
 	stuck = True
 	for each RR in RRlist:
 		if validated_with_cache(RR):
 			add_to_cache(RR)
 			remove_from_RRlist(RR)
 			stuck = False

And then the order of RRs doesn't matter.


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)

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".

Paul