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

James Cloos <cloos@jhcloos.com> Fri, 14 February 2014 22:57 UTC

Return-Path: <cloos@jhcloos.com>
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 AB8D81A01E0 for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 14:57:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_44=0.6, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 ZCDi0eaDiO0D for <dane@ietfa.amsl.com>; Fri, 14 Feb 2014 14:57:34 -0800 (PST)
Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2411A02D0 for <dane@ietf.org>; Fri, 14 Feb 2014 14:57:33 -0800 (PST)
Received: by ore.jhcloos.com (Postfix, from userid 10) id E32A91DF86; Fri, 14 Feb 2014 22:57:30 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1392418650; bh=G6hD1EKHP5bflPQtcG9rfw8WD8WRTHqLc4txKVr56Fw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=heLwnASPXu6XckM3kFFAx2TACYsa/yCAp28ypyaKScBaCZdbYYJklnqzSSEkj6EI6 oyjGlNWQ2f8e1pvtp9btnlKxm2Qn9dEPjzinIFoUSNLbG+6CeSQuZQVDiEzezFQwDy puSbtDMi4G/Mix5NlRQ662LR6HtXwFn+qey4bPNQCRA==
Received: by carbon.jhcloos.org (Postfix, from userid 500) id D29DE60021; Fri, 14 Feb 2014 22:50:44 +0000 (UTC)
From: James Cloos <cloos@jhcloos.com>
To: dane@ietf.org
In-Reply-To: <20140214200002.GK278@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 14 Feb 2014 20:00:02 +0000")
References: <20140214200002.GK278@mournblade.imrryr.org>
User-Agent: Gnus/5.13001 (Ma Gnus v0.10) Emacs/24.3.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2014 James Cloos
OpenPGP: ED7DAEA6; url=http://jhcloos.com/public_key/0xED7DAEA6.asc
OpenPGP-Fingerprint: E9E9 F828 61A4 6EA9 0F2B 63E7 997A 9F17 ED7D AEA6
Date: Fri, 14 Feb 2014 17:50:38 -0500
Message-ID: <m37g8x2trc.fsf@carbon.jhcloos.org>
Lines: 40
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature"
X-Hashcash: 1:30:140214:dane@ietf.org::Ja6HsAXSRpfTZONy:0007J1kL
X-Hashcash: 1:30:140214:viktor1dane@dukhovni.org::XDfW1TRx4b5rbeR6:000000000000000000000000000000000000sILL+
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/3sEB5M9UzXlmIn-Y1cha8LXrMl8
Subject: Re: [dane] Lukewarm discussion: DANE for opportunistic TLS protocols
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Fri, 14 Feb 2014 22:57:38 -0000

It is important to note that many (though not all) of the original
proponents only seemed to care about http, where opportunistic tls
never caught on.

Even with ipp, where existing software actually support it, the
preference seems to be to use ipps:// (on the same port as ipp://)
or https:// (on port 443) uris over using rfc2817 tls upgrade.

But even so there were voices hoping for a mechanism to stipulate that
tls SHOULD or even MUST be used for a given name+port.

My impression at the time was that the consensus not to include language
to that effect it rfc 6698 was not consensus that such a mechanism was
undesireable, but just that it wasn’t generally enough wanted to warrant
making it a part of the base specification rather than part of some more
specific followup specification.

Clearly there needs to be a way to say ‘Use TLS when contacting this
server, even though the protocol takes extra steps to do so.’  The
existence of a relevant, secure TLSA is not an unreasonable way for
specific tls communities to do so.

Even though the broader tls community may not need (or want) such a
mechanism for their servers.

Not only do I encourage rfc publication of some mix of the dane-smtp-
with-dane and dane-srv drafts, but I do not agree that either is
contrary to the consensus for publishing what is now rfc 6698.

Once the details are worked out -- progress looks good -- that also
applies to the smime and openpgp drafts.

The only real question is whether dane-srv and dane-smtp-with-dane
should be published as two rfcs or combined into one?
(I’m leaning towards two, numerically adjacent.)

-JimC
--
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6