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.
- [dane] Lukewarm discussion: DANE for opportunisti… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… James Cloos
- Re: [dane] Lukewarm discussion: DANE for opportun… Peter Saint-Andre
- Re: [dane] Lukewarm discussion: DANE for opportun… Paul Hoffman
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… James Cloos
- Re: [dane] Lukewarm discussion: DANE for opportun… Warren Kumari
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni
- Re: [dane] Lukewarm discussion: DANE for opportun… Phillip Hallam-Baker
- Re: [dane] Lukewarm discussion: DANE for opportun… Jelte Jansen
- Re: [dane] Lukewarm discussion: DANE for opportun… Nicholas Weaver
- Re: [dane] Lukewarm discussion: DANE for opportun… Paul Wouters
- Re: [dane] Lukewarm discussion: DANE for opportun… Nicholas Weaver
- Re: [dane] Lukewarm discussion: DANE for opportun… Viktor Dukhovni