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
