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

[Willem Toorop <[e-mail]>]

Op 22-02-18 om 16:44 schreef Shumon Huque:
> On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters <[e-mail]
> <mailto:[e-mail]>> 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.
>