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

2018-03-18 Thread Shumon Huque
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)

2018-03-12 Thread Ilari Liusvaara
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)

2018-03-12 Thread Kathleen Moriarty
Hello, Can you please provide updated text that addresses EKR's discuss while this additional discussion continues? I'd like to see if it's possible to get this wrapped up before the plenary in London. Eliminating discuss points and resolving this additional issue are required for that. If this

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

2018-03-12 Thread Paul Wouters
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)

2018-03-05 Thread Paul Wouters
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)

2018-03-05 Thread Viktor Dukhovni
> 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 the expiry date on the RRSIG for

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

2018-03-03 Thread Viktor Dukhovni
[ Not replying for Paul, I'm sure he he'll post views separately ] > On Mar 3, 2018, at 10:21 PM, Eric Rescorla wrote: > > Paul, can you walk me through the security value of a proof of nonexistence > here? Perhaps describe an attack that it stops. My take is: Non-existence

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

2018-03-03 Thread Eric Rescorla
Hi folks, This is way outside the range of my DISCUSS, so maybe we should change the thread title. Paul, can you walk me through the security value of a proof of nonexistence here? Perhaps describe an attack that it stops. -Ekr On Sat, Mar 3, 2018 at 7:09 PM, Paul Wouters

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

2018-03-03 Thread Paul Wouters
On Thu, 1 Mar 2018, Shumon Huque wrote: I do not know if the draft authors and/or WG have an appetite to do the much  more major change suggested by Viktor (i.e in-protocol pinning TTL commitment and requiring subsequent denial of existence proof if DANE is removed). I think it is worth

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

2018-03-01 Thread 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 following instead: >> >>

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

2018-03-01 Thread Shumon Huque
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)

2018-03-01 Thread Shumon Huque
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)

2018-02-28 Thread Nico Williams
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)

2018-02-27 Thread Nico Williams
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)

2018-02-27 Thread Nico Williams
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)

2018-02-27 Thread Shumon Huque
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)

2018-02-27 Thread Viktor Dukhovni
> 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)

2018-02-27 Thread Shumon Huque
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)

2018-02-27 Thread Willem Toorop
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)

2018-02-27 Thread 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 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)

2018-02-27 Thread Benjamin Kaduk
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)

2018-02-26 Thread Viktor Dukhovni
> 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)

2018-02-26 Thread 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 there has been an implicit understanding

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

2018-02-23 Thread Willem Toorop
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)

2018-02-22 Thread Shumon Huque
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)

2018-02-22 Thread 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 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)

2018-02-21 Thread Eric Rescorla
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)

2018-02-21 Thread Viktor Dukhovni
> 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)

2018-02-21 Thread Paul Wouters
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)

2018-02-21 Thread Paul Wouters
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)

2018-02-21 Thread Eric Rescorla
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)

2018-02-21 Thread Shumon Huque
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)

2018-02-21 Thread Viktor Dukhovni
> 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)

2018-02-21 Thread Shumon Huque
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)

2018-02-21 Thread Shumon Huque
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)

2018-02-08 Thread Eric Rescorla
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)

2018-02-08 Thread Viktor Dukhovni
> 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)

2018-02-08 Thread Eric Rescorla
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)

2018-02-08 Thread Shumon Huque
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