Re: [TLS] Mirja Kühlewind's No Objection on draft-ietf-tls-dnssec-chain-extension-06: (with COMMENT)

nt or wildcard answers, because it simply doesn't forward the NSEC(3) proof for it. The last measurements we at NLnet Labs did was in July 2015: Gorjón, Xavier Torrent, and Willem Toorop. "Discovery method for a DNSSEC validating stub resolver." (2015)

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

Op 22-02-18 om 16:44 schreef Shumon Huque: > On Wed, Feb 21, 2018 at 2:48 PM, Paul Wouters > wrote: > > On Wed, 21 Feb 2018, Shumon Huque wrote: > > Okay, got it. For people that have already implemented this, I think > there has been

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

Op 27-02-18 om 16:12 schreef Viktor Dukhovni: > > >> On Feb 27, 2018, at 9:34 AM, Benjamin Kaduk wrote: >> >> There doesn't seem to be much interest in pinning-like schemes for TLS >> at this point (see also the "TLS server identity pinning" proposal from >> the

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

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.

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

records, but no servers that support the extension? Can they be hampered (for an indefinite period) by a MiTM? That would be really bad for DANE deployment. Op 10-04-18 om 17:22 schreef Paul Wouters: > On Tue, 10 Apr 2018, Willem Toorop wrote: > > I just want to clarify one misc

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

Op 13-04-18 om 00:09 schreef Viktor Dukhovni: > The protocol as described prohibits denial of existence responses. Willem > acknowledged (thus far in an off-list message) that that's an oversight that > should be corrected, and such a correction is the substance of option (A). Well... I find it

Re: [TLS] Proposed text for dnsssec chain extension draft

Thanks for the suggestions, Op 25-04-18 om 07:33 schreef Viktor Dukhovni: > > I've been asked to write up proposed changes to the DNSSEC chain > extension draft (with the 16-bit extension support lifetime field). > In doing that I've discovered that adding the 16-bit field is a > minor tweak to