On Fri, Apr 13, 2018 at 4:30 PM, Nico Williams <n...@cryptonector.com> wrote:
> On Thu, Apr 12, 2018 at 04:10:27PM -0700, Eric Rescorla wrote: > > On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni <ietf-d...@dukhovni.org > > > > wrote: > > > Proposed text: > > > > > > When the server has DNSSEC-signed TLSA records, the first RRset in > > > the chain MUST contain the TLSA record set being presented. > > > However, ... > > > > > > When the server either has no TLSA records, or its domain is not > > > DNSSEC-signed, it is RECOMMENDED that the server return a denial > > > of existence of either the TLSA records, or proof of insecure > > > delegation at some parent domain, rather than omit the extension. > > > Clients that are willing to fall back from DANE to some alternative > > > mechanism may require the denial of existence to make that possible. > > > > > > > I believe that that this text would harm ineteroperability. > > > > The difficulty here is what the server knows about the clients behavior. > > Specifically, if the server serves TLSA records and then ceases doing > > without serving authenticated denial of existence, then it is unable to > > determine if this would cause clients to fail because it doesn't know if > > the client implements the text in the final paragraph. One could argue > > that current clients could pin, but that's totally extratextual, as > opposed > > t having a noninteroperable behavior in the document. > > It's better to send the denial of existence than no extension -- the > client could just as well be pinning (because the I-D said it could, or > because the client does it regardless), and not having extension then > will cause failure. > > Now, clients that don't do opportunistic pinning would have to... notice > the lack of TLSA RRs, but not necessarily bother validating the denial > of existence chain. There's not even a need to say that the client > SHOULD (let alone MUST) validate the denial of existence chain. It > suffices that the server SHOULD send it. > Sure seems like it would be simpler to say "Client MUST NOT cache TLSA state". Yes, that cuts off some use cases. But it avoids all the transition pain that EKR has pointed out. --Richard > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
