Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols

Viktor Dukhovni <viktor1dane@dukhovni.org> Mon, 17 February 2014 20:35 UTC

Return-Path: <viktor1dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7ED3C1A0239 for <dane@ietfa.amsl.com>; Mon, 17 Feb 2014 12:35:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
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 wQNR_X8Mflue for <dane@ietfa.amsl.com>; Mon, 17 Feb 2014 12:35:25 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id A4AB01A026D for <dane@ietf.org>; Mon, 17 Feb 2014 12:35:23 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 684E22AABCE; Mon, 17 Feb 2014 20:35:20 +0000 (UTC)
Date: Mon, 17 Feb 2014 20:35:20 +0000
From: Viktor Dukhovni <viktor1dane@dukhovni.org>
To: dane@ietf.org
Message-ID: <20140217203520.GL278@mournblade.imrryr.org>
References: <20140214200002.GK278@mournblade.imrryr.org> <m37g8x2trc.fsf@carbon.jhcloos.org> <B06F0F91-7200-4ACF-BBB5-7BDC942DBFB8@vpnc.org> <CAHw9_iKVV9EDihH1C-atswzULaXUbyACVNVfXGNND0Q6=NZL-w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAHw9_iKVV9EDihH1C-atswzULaXUbyACVNVfXGNND0Q6=NZL-w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/vbcFNXilUl7-dgMCljd7h7JWQr0
Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Feb 2014 20:35:27 -0000

On Mon, Feb 17, 2014 at 02:54:02PM -0500, Warren Kumari wrote:

> We decided not to do that, but I wonder if in light of recent
> revelations we should revisit this decision. I'm not quite sure how
> we'd cram this into the current record, if it should be defined in
> each of the "DANE with foo" docs or if it would require yet another RR
> type...

For what it is worth, I think that the DANE TLSA RRset is already
too much rope.   There is no need for yet more complexity.

> Or we could give the person publishing the RR the ability to specify.

They do that by publishing the RR, in the context of an application
protocol (e.g. SMTP) where DANE TLS is opportunistic.  My vote is
strongly to let the TLSA RRset stand as-is, and allow "DANE for
foo" specifications to define appropriate semantics in the context
of "foo".  In particular "discovery" would be a "foo-specific"
feature.

> > And, to be blunt, if we think that Viktor is right about DANE
> for SMTP, shouldn't DANE for HTTP have the same MITM protection
> and operational downsides?
> 
> Personally I think that it should, but I might be in the weeds here.

One of the key points in the introduction to the SMTP draft (please
read at least the introduction).  Is that analogies between HTTP
and SMTP are deeply flawed.

HTTP has no STARTTLS.  HTTP has a separate URI scheme for security,
which runs on a different port.

If one were to design an opportunistic downgrade-resistant upgrade
from HTTP to HTTPS, then one might consider approaches similar in
spirit to the SMTP draft, though there would difficulties.  Lack
of STARTTLS means that any secure HTTP would need a separate port,
and thus a simple detection of TLSA RRs is not sufficient.

There would likely need to be SRV records (or something similar)
for HTTP that a client would consult to determine whether a domain
supported HTTPS and on what hosts/ports before falling back to
HTTP.  Since we're not designing HTTP here, I don't think we should
discuss this any further.  It is not really relevant, other than
an observation that direct application of the SMTP draft to HTTP
is not possible.

-- 
	Viktor.