[TLS] draft-housley-tls-tls13-cert-with-extern-psk

In London, I was on the agenda to talk about certificate-based authentication with external pre-shared key (PSK). We ran out of time, and I did not get to make the presentation. The slides are in the proceedings; see

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

> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > I do not support adding a field to the protocol with semantics to be defined > later. Especially a 16-byte field, which is a fair bit of cruft to carry > around. The 16-byte is a typo. It was supposed to be 16-bit. My

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

> On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > I do not support adding a field to the protocol with semantics to be defined > later. And the semantics are defined. The server must send zero, and the client must read it as zero. The propose semantics PROHIBIT

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

On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote: > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni > wrote: > > > > > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > > > I do not support adding a field to the protocol with

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

On Wed, Apr 18, 2018 at 4:56 PM, Nico Williams wrote: > On Wed, Apr 18, 2018 at 04:52:14PM -0400, Richard Barnes wrote: > > On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni > > > wrote: > > > > > > > > > > > > On Apr 18, 2018, at 4:47 PM, Richard

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

On 4/18/18 10:22 AM, Joseph Salowey wrote: > Concerns have been raised about the trade-offs associated with pinning > and I do not think we currently have consensus to add pinning.  While I > think it may be possible to come to consensus on pinning I think it may > take some time.  I believe we

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

On Wed, 18 Apr 2018, Joseph Salowey wrote: This is a combined response of Viktor, Nico and Paul. Concerns have been raised about the trade-offs associated with pinning and I do not think we currently have consensus to add pinning.  While I think it may be possible to come to consensus on

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

> On Apr 18, 2018, at 5:03 PM, Richard Barnes wrote: > > The only "reserved" in RFC 5246 is a few code points that are reserved for > private use. No reserved fields. The field is NOT reserved, it carries an "extension support lifetime" of 16-bits whose zero value means "DO

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

On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote: > On Wed, 18 Apr 2018, Joseph Salowey wrote: > > This is a combined response of Viktor, Nico and Paul. > > Concerns have been raised about the trade-offs associated with pinning >> and I >> do not think we currently have

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

On Wed, Apr 18, 2018 at 4:48 PM, Viktor Dukhovni wrote: > > > > On Apr 18, 2018, at 4:47 PM, Richard Barnes wrote: > > > > I do not support adding a field to the protocol with semantics to be > defined later. Especially a 16-byte field, which is a fair bit

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

> On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > Secondary point. Still don't think we should deliberately include undefined > fields, e.g., because part of the discussion is whether 16 bits is the right > size. 16 bits is clearly enough. If the units are hours that

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

On Wed, Apr 18, 2018 at 4:56 PM, Viktor Dukhovni wrote: > > > > On Apr 18, 2018, at 4:52 PM, Richard Barnes wrote: > > > > Secondary point. Still don't think we should deliberately include > undefined fields, e.g., because part of the discussion is whether

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

We've had a lot of discussion on this thread that has pointed out that there are enough issues with the current document that we should recommend that the AD pull it back from the RFC editor. Concerns have been raised about the trade-offs associated with pinning and I do not think we currently

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

On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote: > We've had a lot of discussion on this thread that has pointed out that > there are enough issues with the current document that we should recommend > that the AD pull it back from the RFC editor. > > Concerns have been

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

> On Apr 18, 2018, at 11:25 PM, Peter Gutmann wrote: > >> That's just silly. Really, 7.5 years (relative, not absolute) measured in >> hours is plenty good enough, and more than outlives current device >> obsolescence. This isn't subject to Moore's law or anything

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

On Wed, Apr 18, 2018 at 4:42 PM, Paul Wouters wrote: > > 2. Explicitly allow (but do not require) DoE be included >> > > The document does not currently allow the extension to be empty. So if > there is no TLSA record and the extension would be present, it therefore > can only

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

Nico Williams writes: >That's just silly. Really, 7.5 years (relative, not absolute) measured in >hours is plenty good enough, and more than outlives current device >obsolescence. This isn't subject to Moore's law or anything like it. I don't know what devices you work