One other bit of context here: DANE itself doesn't prevent these "downgrade" attacks in its native form, to say nothing of TLS.
Recall that caching is optional for DNS clients, and the usage of DNSSEC validation results is up to the application. Suppose you had an application with the following logic when connecting to a server: - Attempt to fetch validated DANE records for the server - If that succeeds, apply the DANE records on the connection. Do not cache them. - If resolution fails, either because of a DNS failure or a validation failure, fall back to the normal PKI Such a client has the same security profile as a client using the current DANE-TLS mechanism. And AFAICT, there is nothing in the current DANE spec set that forbids this behavior. The fault, dear Brutus, is not in the TLS transport, but in DANE itself. Servers simply cannot expect that clients will persist DANE information. Now, you could argue that we should do better in the TLS transport. But now you're in the realm of feature requests, not security vulnerabilities, and feature gaps should not be blocking on a document that already had WG consensus. --Richard On Wed, Sep 12, 2018 at 4:40 PM Paul Wouters <p...@nohats.ca> wrote: > > Hi, > > We have made available what we believe is a good starting point for > further discussion regarding tls-dnssec-chain draft. > > While I thought we had reached some additional consensus in a side > meeting at IETF 102 that every use case was per definition restrictive, > and that thus downgrade protection was mandatory for this document, > not everyone then present still seems to agree with that. > > Nevertheless, we included the text we believe should go into the document. > > We can further discuss the preventing of downgrade attacks at the > meeting if people have better ideas or _specific_ concerns about our > current approach. > > Paul, Viktor and Nico > > > Repository > https://github.com/vdukhovni/dnssec-chain-extension/tree/for-interim > > Diff Commits: > > https://github.com/tlswg/dnssec-chain-extension/compare/0664d5a608bc2cd82967370160fd4b837dba8fab...vdukhovni:for-interim > > The following changes were drafted > > * Mandatory Denial of Existence (DoE) or TLSA data (no empty extension > data) > This prevents a downgrade attack and gives a method to "clear pinning") > > * Add two byte SupportLifetime to the extension and define the behaviour > of TLS client and TLS server with respect to this extension. This > prevents downgrade attacks. > > * Explain that receiving validated DoE data implies setting > SupportLifetime to 0 > (AKA it "clears the pin") > > * Describe how to phase out using the TLS extension without causing > problems > > * Mandate use of SNI > > * Added port information to the extension_data to support TLS servers > behind NAPT that cannot determine the original port of the origin > based on the received packet. > > * Do not mandate DNS record ordering, it is complicated with CNAME/DNAME > (the reverse order would actually make more sense for implementors) > > * Describe behaviour when a TLS server receives an SNI it does not expect > (and has no extension data for) > > * Describe that TLS clients can obtain TLSA data directly from DNS or > via this extension and that TLS clients can omit the extension > completely if they have a non-expired cached TLSA RRset already. > > * Clarify TLS servers don't need to do DNS queries themselves, but can > depend on an external process to get fresh DNS data for populating > the extension. > > Still to do: > > * Describe the interaction of TLSA records with CNAME and DNAME as a > TLSA record can have a CNAME/DNAME at the beginning of the chain or > at the end. (RFC7671 CNAME chasing does not work well) > > * Provisioning TLSA chains with virtual hosting and cname constraints > (eg domain owner points to Hoster's webfarm via CNAME) > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
