[TLS] TLS interim meeting material

[Paul Wouters <[e-mail]>]

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)