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

Hi Kathleen, Sorry for the delay. We'll have an updated draft addressing the IESG discuss/comments shortly after the I-D submission window opens early this week. The one other sticking point is the issue that Viktor has raised about extending the protocol to provide pinning to prevent downgrade

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

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,

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

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

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

On Mon, 5 Mar 2018, Viktor Dukhovni wrote: On Mar 5, 2018, at 4:32 AM, Willem Toorop wrote: Therefore, any long-term caching of a destination's support for the extension should require server opt-in, and must have a maximum duration. How do you (all) feel about using

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

> 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 following instead: >> >>

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

On Tue, Feb 27, 2018 at 6:36 PM, Nico Williams wrote: > On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > > >

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

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 following instead: > > Make the pin-to-DANE be "forever" but make it so it can easily be >

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

IF there's an objection to modifying the extension in order to add a pin-to-DANE TTL field, I would propose the following instead: Make the pin-to-DANE be "forever" but make it so it can easily be cleared if DANE is undeployed for the service. That would look like this: - if the

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

On Tue, Feb 27, 2018 at 05:36:12PM -0600, Nico Williams wrote: > On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > > > draft, but

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

On Tue, Feb 27, 2018 at 11:24:31AM -0500, Shumon Huque wrote: > On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > Several of us were well aware of this during the early days of the > > draft, but perhaps many folks did not fully appreciate the impacts > > until I

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

On Tue, Feb 27, 2018 at 10:59 AM, Shumon Huque wrote: > > > Several of us were well aware of this during the early days of the > draft, but perhaps many folks did not fully appreciate the impacts > until I elaborated on them last year, and added text that described > the

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

> On Feb 27, 2018, at 10:47 AM, Willem Toorop wrote: > >> If this protocol has no denial of existence, I don't see any reason >> for anyone to deploy it. Why publish something that's basically >> useless? > > Well.. support of the option could be obligatory for new TLS

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

On Mon, Feb 26, 2018 at 12:19 PM, Viktor Dukhovni wrote: > > I think that as it stands, lack of authenticated denial of existence is > a *fatal* flaw in the protocol. I just don't see a sufficiently practical > scenario in which this extension confers a useful security

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] Eric Rescorla's Discuss on draft-ietf-tls-dnssec-chain-extension-06: (with DISCUSS and COMMENT)

> 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 100). > And I do think the lack of

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

On 02/26/2018 11:20 AM, Viktor Dukhovni wrote: > >> On Feb 26, 2018, at 9:26 AM, Paul Wouters wrote: >> >> So it was decided to not use a full DNS packet format? And then since you >> miss the structure of the Answer Section and Additional/Authority >> Section, you require the

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

> On Feb 26, 2018, at 9:26 AM, Paul Wouters wrote: > > So it was decided to not use a full DNS packet format? And then since you > miss the structure of the Answer Section and Additional/Authority > Section, you require the "answer RR's" come first where you basically > emulate

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

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 there has been an implicit understanding

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)

On Wed, Feb 21, 2018 at 12:51 PM, Eric Rescorla wrote: > > > On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote: > >> >> My comment was about what DANE mode choices the server is offering to >> the client. Certainly, the client can decide whether it wants to

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

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 understanding that the format of the chain >> data is a sequence of concatenated

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

On Wed, Feb 21, 2018 at 11:21 AM, Paul Wouters wrote: > On Thu, 8 Feb 2018, Viktor Dukhovni wrote: > > For clients that do reject PKIX success based on DANE failure, and >> cache obtained TLSA records, it might have been good to recommend >> refreshing the TLSA records while the

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

> On Feb 21, 2018, at 2:21 PM, Paul Wouters wrote: > >> For clients that do reject PKIX success based on DANE failure, and >> cache obtained TLSA records, it might have been good to recommend >> refreshing the TLSA records while the cached data is still valid >> (say the

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

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 understanding that the format of the chain data is a sequence of concatenated wire format RRs exactly as they appear in a DNS message section Note, I would

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

On Thu, 8 Feb 2018, Viktor Dukhovni wrote: For clients that do reject PKIX success based on DANE failure, and cache obtained TLSA records, it might have been good to recommend refreshing the TLSA records while the cached data is still valid (say the smaller of some refresh time or 50% of TTL

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

On Wed, Feb 21, 2018 at 7:52 AM, Shumon Huque wrote: > Sorry for my belated follow-up. Was temporarily overwhelmed by the > day job .. > > > On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote: > > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque

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

On Wed, Feb 21, 2018 at 12:05 PM, Viktor Dukhovni wrote: > > > > On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote: > > > > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni > wrote: > > > > Summary as I see it: > > > > *

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

> On Feb 21, 2018, at 10:57 AM, Shumon Huque wrote: > > On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni > wrote: > > Summary as I see it: > > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure > of PKIX-TA(0) and PKIX-EE(1). Must

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

On Thu, Feb 8, 2018 at 11:35 AM, Viktor Dukhovni wrote: > > > Summary as I see it: > > * Mandatory DANE: > MUST Refuse absence of TLSA RRs or failure > of PKIX-TA(0) and PKIX-EE(1). Must fail when no TLSA RRs > are cache and the server does not present the

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

Sorry for my belated follow-up. Was temporarily overwhelmed by the day job .. On Thu, Feb 8, 2018 at 9:49 AM, Eric Rescorla wrote: > On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote: > > > > IMPORTANT: I'm not sure that this is actually sufficient to allow an

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

Yeah this doesn't seem unreasonable -Ekr On Thu, Feb 8, 2018 at 8:35 AM, Viktor Dukhovni wrote: > > > > On Feb 8, 2018, at 9:49 AM, Eric Rescorla wrote: > > > >> This depends on the mode of DANE in use (i.e. the Certificate Usage > >> field of the TLSA

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

> On Feb 8, 2018, at 9:49 AM, Eric Rescorla wrote: > >> This depends on the mode of DANE in use (i.e. the Certificate Usage >> field of the TLSA record). If I recall correctly, this should all be >> covered in detail in RFC 7671 ("DANE Updates and Operational Guidance"). >> >>

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

On Thu, Feb 8, 2018 at 6:18 AM, Shumon Huque wrote: > On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla wrote: > >> Eric Rescorla has entered the following ballot position for >> draft-ietf-tls-dnssec-chain-extension-06: Discuss >> > > Thanks Eric for your detailed

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

On Wed, Feb 7, 2018 at 9:34 AM, Eric Rescorla wrote: > Eric Rescorla has entered the following ballot position for > draft-ietf-tls-dnssec-chain-extension-06: Discuss > Thanks Eric for your detailed review and comments. > This draft seems generally sound, but I believe there are