Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

[Ilari Liusvaara <[e-mail]>]

On Mon, Mar 12, 2018 at 02:29:55PM -0400, Paul Wouters wrote:
> On Mon, 5 Mar 2018, Willem Toorop wrote:
> 
> > No Paul, the division in sections is irrelevant for a verifier.  The
> > only bit of information in a DNS message that is used by a verifier is
> > the question.  From the question, validation starts and the relevant
> > records are followed and verified.  But the question section is also not
> > needed as the question can be derived from the name and port of the
> > service, i.e. <port>._tcp.<name>. TLSA
> > 
> > The order described in the draft is both an optimization to reduce the
> > number of times a verifier has to go over the RRs, and it makes the
> > content easier to read (and understand) for humans too.
> > 
> > Also, for non existence answers, DNSSEC validators (and thus also a
> > verifier for the chain extension) simply ignore the DNS message header.
> > Proof of non-existence can and must be derived from the set of RRs in
> > the message body/sections too.
> 
> Willem (and Shumon and Viktor) have convinced me the DNS Header and
> Sections are not needed.
> 
> > The extension already supports Denial of Existence proof b.t.w., because
> > it is also needed for wildcard expansions (which are supported).
> 
> The issue here is the requirement of the TLS server to send these
> records in the absence of any TLS record. This allows the clients to
> detect a rogue webserver cert that is valid in webPKI but not valid
> based on DANE. Without this commitment, the TLS extension does not
> really work, as it can be omitted by an attacker.


One idea for adding pinning:

- Add pinned flag to the client request structure. This is set if
  the client has the server pinned, otherwise clear.
- Add max_age field to the server response structure.
- If max_age=0, the payload can either be authenticated TLSA RRset or
  proof no such thing exists. Any sent RRset applies to current
  connection. In either case, the pin breaks immediately.
- If max_age>0, the payload must be TLSA RRset. The TLSA RRset
  appiles to this connection. Pin the name as requiring this extension
  for next max_age seconds.
- Add security consideration that sending TLSA RRsets with max_age=0
  is vulernable to downgrade attacks.

The reason for the flag in client request is to tell the server if
it should bother sending ADoE back or not.


Also, could cached_info extension be extended to cover data for this
extension? It would save some bandwidth...


-Ilari