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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
