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 t

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, valid

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

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)

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 qu

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 the expiry date on the

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

> 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 the > TLSA to be used

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] 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)

[ 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 proofs can clear a

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

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 wrote: > On Thu, 1

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

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 discus

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: >> >>Make the pin-to-DANE be "forever" 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 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 > > > draft, but perhaps many folks did not ful

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 > cleared if DANE is undeploye

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 server

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 perhaps many folks did

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 elaborated on them last ye

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 "adversary with fraudulen

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 services, > like DNS ov

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 benefit. Viktor, Is this

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)

> 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 authenticated denia

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 "answer RR's" come f

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 an Answer Sectio

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 that the format of

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)

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 use >> DANE or not, and whether it w

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 wire format RRs e

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 cached data is st

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 smaller of some refresh

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 n

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 has

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 wrote: > > > > > > IMPORTANT: I'm not sure that this

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: > > > > * Mandatory DANE: MUST Refuse absence of TLSA RRs or failure > > of PKI

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 fail when no TLSA RRs > are cache and t

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 extension. > > * "Opportun

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 > > > independent implementation

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 record). If I recall correctly, this sho

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"). >> >> * With DANE-EE,

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 review and comments. > > > This dr

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 pieces that > a

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

Eric Rescorla has entered the following ballot position for draft-ietf-tls-dnssec-chain-extension-06: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please ref