Re: [dane] DANE Client Authentication draft updated

Shumon Huque <shuque@gmail.com> Wed, 13 January 2016 02:03 UTC

Return-Path: <shuque@gmail.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 CDE331B2BBA for <dane@ietfa.amsl.com>; Tue, 12 Jan 2016 18:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 FBjJu2HVSHAA for <dane@ietfa.amsl.com>; Tue, 12 Jan 2016 18:03:27 -0800 (PST)
Received: from mail-qg0-x231.google.com (mail-qg0-x231.google.com [IPv6:2607:f8b0:400d:c04::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9362A1B2BB9 for <dane@ietf.org>; Tue, 12 Jan 2016 18:03:27 -0800 (PST)
Received: by mail-qg0-x231.google.com with SMTP id 6so365887556qgy.1 for <dane@ietf.org>; Tue, 12 Jan 2016 18:03:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=aoMouB/NF2ne6GIdJL2u8WetTdQlt+29rnyN/Zl60nI=; b=Nd6rs2BXOTXyTaC1bVk4KSEZB71rORB2mnOb3C+9+gA22DvtpQFdY4HC8pSi82FVoB RKkWLvcWrpLEP9JHhveHX6y3dJNPE1ahUDdN8Nzrf6OyHKG3nMo6pxI5bnFLzug1KzWq pgrt87E33VUDar0/6X7gR2VceDqiXtwg4Kbu7fJtLaqBY4LOExMoPAkRZBgfA3PNk33d MdA9UB9gwORNQkFQb40nYM6zCYNcYKTVXXszGbNsjzwSYQY84fZ3iFgSEUj+rcPFTEpT WTlb7kEmjJqFpD2Jvjm0u4jxKjLFnSaO6SOIoOLhdQFDq7SwZLd9/paqF/DTOcGm9rP3 QGQw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=aoMouB/NF2ne6GIdJL2u8WetTdQlt+29rnyN/Zl60nI=; b=DN51Ihqz2qTn1k7IMHenKJBBKp8HuTcMyRK1jLo9V7fhu29qb/Pp2lRppJBgbmYlXN M7bYV26egxeuMIkutuKPpm3YIgMgdF1qztEsPWwgWWQKw69h5/h4UtUo0Vm1w2puxynS MNBv/Q8OTe4Lv2LaBw3QlGQT4ZjU9Bbed5h8SH5mEpIPmF0B4en4pq8CYRUDMYgx8AZO aaAp8RNGTvXBw3W1zWwrfv6BY8O28JdAi58JqNn19kdlH2s8CBcvXX3cpM5TOCsjCqOp c+oQlqitjw8RCPBRosh/VrxSfRMDLzDZUQWrNPCr/n3pn0l1HDVrqNTlK8dvoxBAKYz0 gPNg==
X-Gm-Message-State: ALoCoQml5qzPBmrIQL/eupdwWu8LjaNWMZmIUMqPmSFW0f4IC75HXyPBgFqZMuX+XXk7L/Prx5cTEGndxnfT+Km2hniCOLWnzg==
MIME-Version: 1.0
X-Received: by 10.140.237.74 with SMTP id i71mr122018691qhc.55.1452650606706; Tue, 12 Jan 2016 18:03:26 -0800 (PST)
Received: by 10.140.102.9 with HTTP; Tue, 12 Jan 2016 18:03:26 -0800 (PST)
In-Reply-To: <20160113013152.54184.qmail@ary.lan>
References: <CAHPuVdXYWoD5bZubAu5pEe18sfr69Nat=gp_7iagcVrAgTkY=g@mail.gmail.com> <20160113013152.54184.qmail@ary.lan>
Date: Tue, 12 Jan 2016 21:03:26 -0500
Message-ID: <CAHPuVdWC-Si0O2zpr2r7Ucdk9MpU6aPFBcOPn-z_Jpydz_TD7g@mail.gmail.com>
From: Shumon Huque <shuque@gmail.com>
To: John Levine <johnl@taugh.com>
Content-Type: multipart/alternative; boundary=001a1135914c6548b405292d934a
Archived-At: <http://mailarchive.ietf.org/arch/msg/dane/i5rKxDg8yukHpP5KMuR6-Of_d4Q>
Cc: "<dane@ietf.org>" <dane@ietf.org>
Subject: Re: [dane] DANE Client Authentication draft updated
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 13 Jan 2016 02:03:30 -0000

On Tue, Jan 12, 2016 at 8:31 PM, John Levine <johnl@taugh.com> wrote:

> >On the "_smtp-client" label choice, I had originally used just "_smtp",
> but
> >a colleague more plugged into IANA service name registration procedures
> >advised me that I should choose a different client specific label. The
> >"_smtp" label is a server side label with an associated server side port,
> >and that reusing that label for a client identifier would elicit
> objections.
>
> Yes, no kidding.
>
> In the DNS, service names only appear as subnames of transport names.
> So one possibility would be to register smtp-client as a service name,
> so the DNS label would be _smtp-client._tcp.whatever.example.
>

I would say "only appear *today* under transport names", but this isn't a
hard and fast requirement. We should feel free to construct TLSA owner
names in a form that makes sense for the specific application. For the
purposes of this draft, including a transport label might make sense if
we expected clients to have distinct transport protocol specific
authentication
credentials for the same application. This seems unlikely to me.

On the other hand, these certificates aren't identifying services,
> they're identifying clients, and unless I misunderstand, it should be
> equally useful to identify clients for POP, IMAP, submission, and
> anything else that can do TLS.  The list of service names already has
> a fair number of client names, with the naming utterly inconsistent,
> some with a trailing c, some with trailing "client", trailing
> "-client", trailing "-cl", and a few just random acronyms.
>

Yeah, I noticed the inconsistency too - a bit unfortunate!


> To minimize the chaos I'd suggest registering a psedudo-service name
> "client", always used with the actual service name as its subname.
> So for my SMTP, POP, IMAP, and SUBMIT clients, the names would be
>
>  _smtp._client._tcp.whatever.example
>  _pop3s._client._tcp.whatever.example
>  _imaps._client._tcp.whatever.example
>  _submission._client._tcp.whatever.example
>

See Viktor's previous note about why we excluded a _client label.

I suppose you could use the port number like RFC 6698 does but that
> seems wrong since the server picks the port number.  If a SRV record
> says that the server is, say, running pop3s on port 1234, the client
> is still doing pop3s and can't rename its TLSA record on the fly.
>

Right, we arrived at the same conclusion, and hence excluded the port
number from the client record name.

-- 
Shumon Huque