On Thu, Apr 12, 2018 at 4:06 PM, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote:
> > > > On Apr 12, 2018, at 6:44 PM, Willem Toorop <wil...@nlnetlabs.nl> wrote: > > > > Well... I find it unfortunate that the line you were quoting from > > section 3.4 could be interpreted as prohibiting the possibility of > > denial of existence. So I am open to relaxing that text so that it can > > not be interpreted as such anymore yes. > > Current text: > > The first RRset in the chain MUST contain the TLSA record set being > presented. However, ... > > 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. -Ekr > -- > Viktor. > > _______________________________________________ > 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
