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

Viktor Dukhovni <viktor@dukhovni.org> Thu, 03 May 2018 13:58 UTC

Return-Path: <viktor@dukhovni.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C16A12E03E for <tls@ietfa.amsl.com>; Thu, 3 May 2018 06:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM7ix8ZQ9sDz for <tls@ietfa.amsl.com>; Thu, 3 May 2018 06:57:59 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89E512DA6E for <tls@ietf.org>; Thu, 3 May 2018 06:57:58 -0700 (PDT)
Received: from [192.168.1.161] (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 6FCD77A3309 for <tls@ietf.org>; Thu, 3 May 2018 13:57:57 +0000 (UTC) (envelope-from viktor@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <viktor@dukhovni.org>
In-Reply-To: <20180503125410.GL5742@akamai.com>
Date: Thu, 03 May 2018 09:57:55 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <7409EE8A-425E-4D7A-AAB5-1AB6B36AD4B9@dukhovni.org>
References: <C7CAD4AD-B296-473A-890D-BEBA115990B4@dukhovni.org> <CAHPuVdV+qhC=jS-JEoS6ig6ofRXV__VLOmSL=6c=3_vJK-zCpQ@mail.gmail.com> <429E39D2-58BB-4EF3-902C-5BC441FB932D@dukhovni.org> <20180503125410.GL5742@akamai.com>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/FmML3xTpMUqbluSufljw_L6MB_Q>
Subject: Re: [TLS] Precluding bilateral opt-in for downgrade protection.
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2018 13:58:00 -0000


> On May 3, 2018, at 8:54 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> 
> (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, 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.