Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

ers <p...@nohats.ca>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... And to be clear, it's not that nobody is going to implement the extension (it's already been done in an IETF hackathon and elsewhere), the work on t

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

*Sent:* Thursday, May 17, 2018 8:18 PM > *To:* Tim Hollebeek <tim.holleb...@digicert.com> > *Cc:* James Cloos <cl...@jhcloos.com>; Ted Lemon <mel...@fugue.com>; < > tls@ietf.org> <tls@ietf.org> > *Subject:* Re: [TLS] TLS DNSSEC chain consensus text, please

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

James Cloos <cl...@jhcloos.com>; Ted Lemon <mel...@fugue.com>; <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... On May 17, 2018, at 19:44, Tim Hollebeek <tim.holleb...@digicert.com <mailto:tim.holleb...@digice

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 17, 2018, at 19:44, Tim Hollebeek wrote: > > Making things more complicated with no obvious benefit just makes things > more complicated. > > I oppose adding two bytes for some nebulous future purpose. The consequence of this opinion would be this:

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

8 6:20 PM > To: Ted Lemon <mel...@fugue.com> > Cc: <tls@ietf.org> <tls@ietf.org> > Subject: Re: [TLS] TLS DNSSEC chain consensus text, please speak up... > > >>>>> "TL" == Ted Lemon <mel...@fugue.com> writes: > > TL> Melinda

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 17, 2018, at 1:31 AM, Peter Gutmann wrote: > >> And again, nobody has said that they intend to implement the proposed >> mechanism - indeed, when asked, people have said that they won't. > > Doesn't that resolve the issue then? If no-one's going to

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

Melinda Shore writes: >And again, nobody has said that they intend to implement the proposed >mechanism - indeed, when asked, people have said that they won't. Doesn't that resolve the issue then? If no-one's going to implement it then it doesn't matter how

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

On 5/16/18 2:20 PM, James Cloos wrote: > The sixteen bit field harms no one, and when defined and used provides > significant benefit to many. It is one of the peculiarities of the IETF (and engineers in general, I guess) that when we sit down to design a protocol most people will start talking

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> "TL" == Ted Lemon writes: TL> Melinda made a pretty serious technical objection. Your response is not TL> responsive to her objection. She explicitly said that her objection was TL> not the two bytes. I don't see anything in her note today which is a technical

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

We really need to get this published, and in the interest of making progress I will not block the addition of two bytes to the extension. I am highly reassured by Viktor's suggestion that they will never be used, as unused fields with murky semantics have never been shown to be a problem in IETF

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 16, 2018, at 2:38 PM, Christian Huitema wrote: > > Did you publish the proposed pinning draft already? That would certainly > help clarifying the issue. Only the proposed text defining the interim 16-bit field. The follow-on specification has not yet been

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

On 5/16/2018 11:14 AM, Viktor Dukhovni wrote: > >> On May 16, 2018, at 1:59 PM, Christian Huitema wrote: >> >> The way I understand it, your proposal is not so much to "reserve 16 >> bits" but rather to "include a 16 bit field defined as the pinning time >> in hours". Or

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 16, 2018, at 1:59 PM, Christian Huitema wrote: > > The way I understand it, your proposal is not so much to "reserve 16 > bits" but rather to "include a 16 bit field defined as the pinning time > in hours". Or maybe, "reserve 16 bits as set to zero on send and

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

On 5/16/2018 5:34 PM, Viktor Dukhovni wrote: > For the record, the reason that we're confident that two bytes are > enough is that DNS TTLs already take care of sub-hour continuity > for any provided TLSA records. So units of hours are natural, and > make 16 bits quite sufficient. The way I

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 16, 2018, at 12:20 PM, Tom Ritter wrote: > > On the balance, I support adding the two bytes. Thanks for responding, and sorry to frame the request as "please support", I've previously tried to careful and ask people to respond with their comments whatever they might

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

On 15 May 2018 at 22:14, Viktor Dukhovni wrote: > I therefore appeal to the readers who've so far stayed silent on this > issue, to lend support to paving the way for a more broadly applicable > downgrade-resistant protocol, by supporting the inclusion of a two byte >

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 16, 2018, at 1:34 AM, Viktor Dukhovni wrote: > >> I would be grateful if you would have a consistent story on this. >> Clearly, it's not just two bytes, or there wouldn't be a perceived >> need for them. It's two bytes plus the associated semantics and >>

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

I have no pony in this race, but FWIW ~5 people on each side represents a lack of consensus. A lack of consensus means that the work doesn't happen in the working group. Thomas, your response (sorry to pick on you!) illustrates another consensus issue: consensus exists when all technical

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

FWIW: I support the changes proposed by Viktor and others. In particular, I support reserving 2 bytes for which the semantics will be defined in a separate draft. For me, the advantages of this proposal outweighs the disadvantage of having to reserve 2 bytes that might, in worst case, never get

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 16, 2018, at 1:18 AM, Melinda Shore > wrote: > > Your proposal has been discussed > at length on the list, it's been discussed at length off the list, > and there is still no consensus to modify the extension to support > your use case. You say that,

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

On 5/15/18 8:22 PM, Viktor Dukhovni wrote: > It just leaves > the door open going forward, at negligible cost (two bytes on the > wire in bandwidth, and zero in implementation). I would be grateful if you would have a consistent story on this. Clearly, it's not just two bytes, or there wouldn't

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

> On May 16, 2018, at 12:08 AM, Melinda Shore > wrote: > > At any rate this is starting to feel like abuse of process. I was simply following a security AD's suggestion from today's earlier thread with the AD's authors and chairs: > Therefore, if you want to

Re: [TLS] TLS DNSSEC chain consensus text, please speak up...

We've had this discussion already, at terrific length. To my knowledge it's still the case that nobody intends to implement the proposed changes, and it's still the case that should there be interest in implementing the new functionality there's the option of a new extension. At any rate this is