Re: [TLS] [dane] draft-shore-tls-dnssec-chain-extension-00

[Shumon Huque <[e-mail]>]

On Tue, Jun 30, 2015 at 2:25 AM, Viktor Dukhovni <[e-mail]>
wrote:

Thanks Victor. I'll add a few to Melinda's earlier comments ..

On Mon, Jun 29, 2015 at 09:13:21PM -0800, Melinda Shore wrote:
>
> > Please have a look at it and get comments or suggestions
> > to us.  We're planning on getting one more revision out
> > prior to the Prague meeting, and on having a test
> > implementation available in Prague.
> > The draft is available at:
> > https://tools.ietf.org/html/draft-shore-tls-dnssec-chain-extension-00
>
>

> 3.  I'm not sure what purpose the last paragraph of section 3 is
> intended to serve:
>
>    Obviously, an authentication chain will be most compact and easiest
>    to verify if each RRset has a single record, i.e., if there is a
>    single DNSKEY RR and a single DS RR at each step.  In addition, as
>    suggested above, keeping zone cuts to a minimum also reduces the
>    length of the authentication chain.
>
> The TLS server has no choice but to return the complete RRset for
> each owner name class and RRtype, since RRSIGs cover RRsets, not
> individual RRs.  So "compacting" is possible.  The server returns
> the RRsets exactly as published by the relevant DNS(SEC) servers.
>

Yeah, section 3 needs a bit of work. Also, the order of record (sets) in
the given example doesn't match the dnssec_chain structure definition -
that should be fixed in the next rev. The structure will likely undergo
some additional changes too, e.g. names that involve CNAME/DNAMEs might
need an authentication tree rather than a single authentication chain, or a
sequence of authentication chains.


> Speaking of RRsets, are the RRs in each RRset returned by the server
> required to be sorted in canonical order?
>

It would be nice to do so, but not essential - as long as the validator
sorts them canonically before signature verification.


> 4.  I think the Section 4 SNI interaction would be a lot cleaner,
> if SNI is mandatory for clients that use the proposed extension.
> In which case the server can only respond with a leaf TLSA RRset
> (and chain of RRSIG/DNSKEY/DS/... records) whose "base domain" (
> see section 3 of RFC6698 and soon definition of TLSA base domain
> in draft-ietf-dane-ops-13 (later this week)).  Using some random
> name for the server's IP address is not a good idea IMHO.  PTR
> records are too often poorly correlated with the client's notion
> of the target server name.
>

I agree with this.


> 5.  In Section 5, the server MUST not violate DNS TTLs.  The last
> senetence:
>
>     Alternatively, it could be configured to rebuild the chain at some
>     predefined periodic intervals.
>
> is I fear too much rope.  Sure the server can periodically flush
> its cache (using shorter than possible TTLs), but this does not
> free it of the obligation to not extend TTLs by relying exclusively
> on a cache lifetime of its own choosing.
>

I agree that is a bit of rope. The first part of the section does tell the
validator to do the right thing. The alternative (which would be simpler to
implement) was provided for cases where the server operator might know the
TTLs and signature validity periods of the chain above it (assuming they
are stable), and be able to select a suitable regeneration interval below
them. But yes, it provides more opportunity for doing the wrong thing by
selecting the wrong interval. Note that the original draft suggested
something similar (regenerating the stapled chain into an X.509 cert at
some predefined interval).


> 11.  Finally, Shumon Huque (mostly) and I (helping out) are writing
> a draft to specify DANE TLSA for client authentication.  If and
> when that progresses (WG adoption, ...), there may need to be a
> similar extension, allowing a client to forward its DNSSEC-validated
> TLSA RRset.  This is not an immediate priority and can be re-evaluated
> later.
>

I posted a link to the draft separately on the dane list. But for TLS folks:

    https://tools.ietf.org/html/draft-huque-dane-client-cert-00

-- 
Shumon Huque