Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection.

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 May 2018 07:42:12 -0500

On Sat, Apr 28, 2018 at 03:01:34PM -0400, Paul Wouters wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote:
> 
> [ not going to repeat my technical arguments here, just going to comment
> on process ]
> 
> >First, there is no agreement that your reason for doing pinning,
> >i.e. that DANE needs downgrade resistance against PKIX attacks
> >is even valid.
> 
> This is incorrect. From the replies to the consensus call on the list,
> it actually weights in favour of _some_ kind of downgrade resistance.
> 
> In fact, it worries me that the consensus call outcome seems to come
> from non-public voices and not from a tally of those participants on
> the TLS list.

Given that this mail is framed as just a process comment, and even though you
rightly refer to "technical merits" in a later (trimmed) portion, I must
object to the use of "tally of those participants on the TLS list".
"Tallying participants" implies counting votes, but of course the person
making the consensus call is charged with using their technical judgment to
assess the replies received on the merits.

-Ben

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 3 May 2018 07:54:11 -0500

On Sat, Apr 28, 2018 at 01:40:25PM -0400, Viktor Dukhovni wrote:
> 
> 
> We may yet have to see how much support or opposition the follow-on
> document will meet.  What continues to be puzzling is resistance to
> adding a field that imposes negligible burden on the present spec,
> and would clearly be included in the follow-on extension.  It might

It is not puzzling to me, for two reasons:

(1) fairly early on, the proposal was framed as something that might be
obtained from "good faith in return", which can be interpreted as the
sort of "horse trading" that many IETFers have a visceral objection to.
It is hard to erase this memory when considering subsequent discussions.

(2) It is asking the WG to take on faith and Paul/Viktor/Nico's authority
that the 16-bit value (in hours) is sufficient, and no other fields or
semantic changes would be needed.  While I (and presumably others) do have
a great deal of confidence in your collective technical expertise, it still
seems to be presumptuous and a coopting of the WG consensus process for the
follow-up pinning document.

> well be the only thing that's in the follow-on extension, and so
> provisioning space for it has a strong chance of simplifying the
> burden on future implementations that would need only implement code
> for just one extension structure instead of two.  Worst-case we have
> two reserved bytes in the current extension.

The above notwithstanding, I'm not sure that I can dispute this worst case
assessment, at present.  (Presumably "egg on our collective faces" doesn't
really count.)

-Ben

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 3 May 2018 09:57:55 -0400

> On May 3, 2018, at 8:54 AM, Benjamin Kaduk <[email-masked]> wrote:
> 

Well, MTA-STS is not getting objections for having just "max-age" and
"testing", with a separate specification for an optional reporting
address (that also retroactively supports DANE).  The address is not
part of the STS policy to be delivered in-band with each policy lookup.
It is a obtained separately from a TXT record in DNS.

It is easy to observe that:

  1.  If TLS is to support some sort of contact address for
      resolving operational issues that affect TLS interoperability,
      then it *should not* be restricted to just a particular
      extension.  Such address would be accessed independently of
      the DNSSEC chain extension.  Perhaps in DNS, or perhaps
      solicited via a separate suitable client extension.

  2.  The idea of "testing" makes little sense for negotiating
      a support lifetime for the DNSSEC chain extension that is
      not itself subject to any sort of "testing". The complex
      new behaviour here that one might have wanted to test, is
      introduction of DANE-based authentication.

      Expecting (client side) the extension to  be supported on
      an ongoing  basis for a time no longer than *advertised
      by the server* involves nothing one would want to "test".
      If not sure about ongoing support, the server operator
      should leave the field at zero, or set it to just an hour
      or two.

There's no need here for anything beyond the time field.  And if
we turn out to be wrong about that, then the follow-on document
can still specify a new extension with any additional fields
there, with the lifetime in this extension and the other data
in the new extension.  Surely the new extension will have at
least at least a time field which can still be included in
this one, with additional fields in the new extension.

A second extension to protect a first against downgrades looks
add to me in this day and age.  Integrated downgrade protection
makes more sense.  Let's take a chance on getting it right from
the start.

-- 
	Viktor.