Re: [TLS] TLS interim meeting material

I may have a conflict with the call, so I've gone ahead and put some
opinion inline below...

On Wed, Sep 12, 2018 at 5:40 PM Paul Wouters <paul@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.
>

Speaking as one of the attendees, I do not agree with that conclusion.

What came to light in that meeting is that the assertive cases of DANE
require that the certificate verification in question use the provided cert
/ trust anchor.  That does not imply any semantic beyond a single TLS
connection; there is no inherent need for pinning.

Please stop using the phrase "downgrade attack".  It's deceptive.  It is
not a downgrade attack in the normal sense, i.e., an attack that causes a
TLS session between a legitimate client and a legitimate server to use
lower security (since the bogus server has to terminate the session).  The
"downgrade" here is simply that the client accepts a certificate from a
trust anchor it trusts.

> Nevertheless, we included the text we believe should go into the document.
>

Thank you for the explicit text, and thanks for mostly not using the word
"downgrade".  I agree that the first four paragraphs of the "Issues with
Incremental Deployment" accurately characterize the issue here.

I do not agree that we should include the SupportLifetime element.  TBH,
I'm kind of puzzled that it's in here.  It is no different from what has
been proposed in the past.  No attempt has been made to address the issues
that were raised by EKR, me, and others.  And there is clearly no consensus
for it.

It would be more productive for the group to consider a PR without that
addition, that is focused on clarifying that clients should not cache the
information they get in this way and clarifying the relationship between
this extension and record fetching via the DNS protocol.

--Richard

> 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
>