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
1. There's a more compelling reason than stated why the extension is
not well suited to MTA to MTA SMTP. With MTA to MTA SMTP DANE is
opportunistic, (START)TLS is optional unless a requirement for
authenticated signalled via TLSA records.
Such signalled cannot be postponed to the TLS handshake, because
that handshake may not even take place unless the SMTP client MTA
knows that TLS is required. Even if TLS were to be used, authentication
is generally not required in MTA to MTA traffic, so the extension
would be vulnerable to MITM attacks.
Similar considerations apply to server-to-server XMPP traffic.
Thus the extension in question is only relevant with protocols
where TLS (with authenticaiton) is mandatory, and DANE is a
potentially attractive alternative PKI. With opportunistic DANE
TLS, the extension is inevitably too late.
2. That said, the extension is a potentially good fit for MUA to
MSA submission, and XMPP user-agent (client) to first-hop XMPP
server, where the user agent statically enforces TLS, and generally
connects to a single fixed server it can reasonably authenticate.
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.
Speaking of RRsets, are the RRs in each RRset returned by the server
required to be sorted in canonical order?
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.
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.
6. Note that the soon up for IESG review draft-ietf-dane-ops
considerably revises the DANE verification logic for TLSA certificate
usage DANE-EE(3). Section 6 should refer to draft-ietf-dane-ops-12
(soon -13 which responds to AD and GEN-ART comments) as well as
RFC6698.
7. The draft often says "TLSA record" when it needs to say "TLSA
RRset". It will be quite common for multiple TLSA RRs to be present
in the RRset, as this is required to correctly effect key rotation.
Therefore, in Section 6 (and elsewhere), text such as the below:
If the record is correctly authenticated, the client then performs
DANE authentication according to the DANE TLS protocol [RFC6698].
is sub-optimal, it should refer to a TLSA RRset, which MUST contain
at least one TLSA record that matches the server's certificate
chain, but will often contain additional records that do not.
8. Great care must be taken (with Certificate usages other than
DANE-EE(3)) to ensure that the TLSA record matches a certificate
that is actually part of the server's chain and not just some random
unrelated certificate that happens to be present in the server
certificate message. Many implementors fail to check this.
9. This draft should reiterate the requirement that with certificate
usage DANE-TA(2), the server MUST include the trust-anchor certificate
in its certificate message even if that trust-anchor is self-signed
(root CAs are NOT optional with DANE-TA(2)).
10. Validation of RRSIGs is a subtle art, the client will definitely
need to check not only the signatures but also the validity intervals
of all RRSIGs (the client must trust its own clock or have access
to a trusted time source). Since the server forwards wire-format
RRsets, these include TTLs, and clients might plausibly cache these,
provided the TTLs are consistent with the RRSIG validity intervals.
The draft might provide guidance on any client-side caching (clients
might e.g. not even send the extension when they have unexpired
cached TLSA data from a previous interaction with the server).
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.
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
