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

s, 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) https://nlnetla

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 an implicit unders

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 SAAG/secdispatch session at IETF

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

Op 01-03-18 om 22:50 schreef Viktor Dukhovni: > > >> On Mar 1, 2018, at 2:13 PM, Shumon Huque wrote: >> >>> On Wed, Feb 28, 2018 at 3:07 PM, Nico Williams >>> wrote: >>> IF there's an objection to modifying the extension in order to add a >>> pin-to-DANE TTL field, I would propose the followin

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

Op 26-02-18 om 15:26 schreef Paul Wouters: > On Thu, 22 Feb 2018, Shumon Huque wrote: > >> 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 >>   

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. Not

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

DANE 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 mi

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 u

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 t

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

Op 25-04-18 om 07:33 schreef Viktor Dukhovni: >The following is a TLSA RRset denial-of-existence example: > > example.com. IN SOA > RRSIG(example.com. SOA) > example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC Hopefully the DNSKEY rrtype is incl