Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

[Willem Toorop <[e-mail]>]

I support separation of concerns: publish as is, and start new work to
extend existing Strict Transport Security mechanisms to include DANE
authenticated TLS.

Currently the draft is describing only a single mechanism: Letting
owners of a (DNSSEC signed) domain vouch for their own TLS services.
Not needing a third party for this is IMHO already valuable.

HTTP Strict Transport Security (HSTS) [RFC6797] is extensible with
directives.  A new document could provide a useDANE directive for HSTS.
That document could furthermore make more explicit, that when the chain
extension delivers a denial of existence proof or a proof of insecurity,
that a fallback to non-DANE PKIX has to be done.

The chain extension already contains verification of Denial Of Existence
proofs, because that is needed for verifying wildcard expansions.  It
does not explicitly mention the fallback to non-PKIX with a Denial of
Existence proof or insecurity proof for the TLSA record, because it is
(currently) irrelevant when the extension could simply be left out too.
However, it does implicitly by referring to the DANE RFCs in paragraph 2
of section 6. Verification:

>   If the authentication chain is correctly verified, the client then
>   performs DANE authentication of the server according to the DANE TLS
>   protocol [RFC6698] [RFC7671].

Because the current draft is describing only the embedding of DANE
records to authenticate the TLS service, it is quite short and to the
point.  I am afraid that built-in STS would bloat it with a lot of
concerns that are not specific for the simple mechanism of embedding DANE.

The extension as currently is does not add security like DANE over DNS
protocol would have. This is pointed out in in the draft in Section 8,
in which a mechanism like STS is also already suggested.

I have a few questions too.

Currently the extension contains only DNSSEC data, which can be verified
to be authentic and correct.  Is this also true for an additional TTL
value?  Is it safe to do STS at TLS ClientHello time?  Why is there not
a STS specification at TLS level already (which would also cover imaps,
pops etc.), but only for protocols one layer above TLS?


-- Willem

Op 04-04-18 om 19:50 schreef Joseph Salowey:
> Hi Folks,
> 
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the
> working group is either to publish the document as is or to bring the
> document back into the working group to address the following issues:
> 
> - Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> - Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> 
> This is a consensus call on how to progress this document.  Please
> answer the following questions:
> 
> 1) Do you support publication of the document as is, leaving these two
> issues to potentially be addressed in follow-up work?
> 
> If the answer to 1) is no then please indicate if you think the working
> group should work on the document to include 
> 
> A) Recommendation of adding denial of existence proofs in the chain
> provided by the extension
> B) Adding signaling to require the use of this extension for a period of
> time (Pinning with TTL)
> C) Both
> 
> This call will be open until April 18, 2018.
> 
> Thanks,
> 
> Joe
> 
> 
> 
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>