Re: [dane] DANE Client Authentication draft updated

Shumon Huque <> Wed, 13 January 2016 02:27 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E93301B2C06 for <>; Tue, 12 Jan 2016 18:27:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VdGzKudMSThX for <>; Tue, 12 Jan 2016 18:27:28 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EA0E91B2C07 for <>; Tue, 12 Jan 2016 18:27:25 -0800 (PST)
Received: by with SMTP id p186so183910354qke.0 for <>; Tue, 12 Jan 2016 18:27:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eh6yF+W2xlGhieKUHsRX+bweGYMmCzMytFMCBZH2pyU=; b=RHOSFv7+l3MmOWt7Cktz/G0VjB8rPJvOb0CGj/i9lwhHpJebTNA0QoCeRoWJAa1lQV IVhJshdA+8t3m12w2dBw2nrST4nB4OJmUQyDSFvRntH6yeEzgQfgVIxxVX1TWd9dKm1S neLTdLgBmKk2qB4NgL6BHgO4+luxhA1KQIpCEd9kIhOugm+ux+4IGXvw+kAPB2cgIJ6J xwEHF6JkIJRMyMjXweGaDcsrS719eGpKCiAs0nJ6KQfjZApIKET5uP229H1vpANPUows qCV82zfpO7QAAuiDVbnSoefPVIcGyHTtTxw9H6wjrbBJEUnQ+cl7M68d8DgDzI2mdayg p6iw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Eh6yF+W2xlGhieKUHsRX+bweGYMmCzMytFMCBZH2pyU=; b=ASa0JoV/7nLWMUVyQq2RmU/Eo9OQUUJoWCY65d0Ji75ZHYnE05x9y4zAA/6m5CFnNx BL6uGi39RhDi+KAzF2wxGjzuSxD/GB32AJF0wiivRPSPFc7q1wgjugFeespXZS9uE5E3 5DTTNHJW0G//Tn+/U06WqFI381Erc+1kG0Al9z27reyJsNemuspa2OCj1icvruFFFFIj lT8g9qDBeuagcWzC2QAM7mJJdOpaJU/bnI9H91VBUnWHf9sMTOlGI2HpVNjWKmU/tRMr fHRimgbsv9cwXO9LvGDHwB9CPe1eFnYz9LHKS5hWGPRzlUsNcQCro+01Ftuc09YE+eJA tuJg==
X-Gm-Message-State: ALoCoQlgPcMZZmtBSX7o04nrXCOCDJLCRBq+mYkldsaLXkG0sZwooTzr/waJvCr/DqA1jA8dH1oboK7vCYqs+Qc/gyJkbB1wdQ==
MIME-Version: 1.0
X-Received: by with SMTP id m36mr32586668qkh.84.1452652045093; Tue, 12 Jan 2016 18:27:25 -0800 (PST)
Received: by with HTTP; Tue, 12 Jan 2016 18:27:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Tue, 12 Jan 2016 21:27:25 -0500
Message-ID: <>
From: Shumon Huque <>
To: Kim Alvefur <>
Content-Type: multipart/alternative; boundary=001a114411e02150b005292de911
Archived-At: <>
Cc: "<>" <>
Subject: Re: [dane] DANE Client Authentication draft updated
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 13 Jan 2016 02:27:33 -0000

On Tue, Jan 12, 2016 at 9:10 PM, Kim Alvefur <> wrote:

> On 01/12/2016 11:21 PM, Shumon Huque wrote:
> > On the "_smtp-client" label choice,
> That seems like it will cause confusion considering _xmpp-client is used
> in the XMPP world to refer to where the end-users connect their user
> agents to, so basically equivalent to _submission in email.  And then
> there's _xmpp-server for communication between servers.

Yeah, I'm aware of that. I think the XMPP community made an
unfortunate choice in those names  - I might have suggested
"_xmpp-c2s" and "_xmpp-s2s" instead.

As John Levine points out, the client service name choices are already
all over the map in the current IANA service registry, so ...

FWIW, I would suggest _smtp-out as a less confusing label.

The _smtp-client record was just an example we used in the draft.
We weren't trying to impose a uniform convention for IANA client
application labels here (probably not the right place to do so), but
perhaps we can consider making a recommendation in the IANA
Considerations section of the draft.

The word "client" is a bit ambiguous whether it refers to a user agent
> or a server in the process of connecting to another server. It would
> help to be more explicit about which one of these are being referred to,
> or if it applies to both.

In my opinion, it covers any entity acting as a client, so it covers both
the cases you outline. I'm not sure we need to make a distinction in
the draft.

Client-DANE in the later context, enabling mutual authentication between
> SMTP servers could be a nice improvement / complement to SPF & co.

Glad to hear it. That's one of the use cases that this draft had in mind.

Shumon Huque