IETF Logo Mail Archive

Re: [dane] namespace management, DANE Client Authentication draft updated

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 11 April 2019 17:14 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E0321203E2 for <dane@ietfa.amsl.com>; Thu, 11 Apr 2019 10:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 dQvD6A1t-Uan for <dane@ietfa.amsl.com>; Thu, 11 Apr 2019 10:14:39 -0700 (PDT)
Received: from straasha.imrryr.org (straasha.imrryr.org [100.2.39.101]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50B861202E1 for <dane@ietf.org>; Thu, 11 Apr 2019 10:14:39 -0700 (PDT)
Received: from [192.168.1.161] (unknown [192.168.1.161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by straasha.imrryr.org (Postfix) with ESMTPSA id C23872A5606; Thu, 11 Apr 2019 13:14:37 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <1b9fca81-c4cf-6f15-b9ee-bef4eef1320a@afnic.fr>
Date: Thu, 11 Apr 2019 13:14:36 -0400
Cc: shuque@gmail.com, dane@ietf.org
Reply-To: dane@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <1B9C84C7-A1DE-48DE-AD2B-4340CBD3F0DC@dukhovni.org>
References: <20160114024910.67019.qmail@ary.lan> <1b9fca81-c4cf-6f15-b9ee-bef4eef1320a@afnic.fr>
To: Sandoche Balakrichenan <sandoche.balakrichenan@afnic.fr>
X-Mailer: Apple Mail (2.3445.104.8)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dane/etmI-9sYPPsNVyEgIUHrwh8DV2Y>
Subject: Re: [dane] namespace management, DANE Client Authentication draft updated
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 11 Apr 2019 17:14:42 -0000

> On Apr 11, 2019, at 6:57 AM, Sandoche Balakrichenan <sandoche.balakrichenan@afnic.fr> wrote:
> 
> I have an Internet of Things (IoT) use-case, in which i am evaluating
> using TLSA RR for both server and client authentication.
> 
> For the client authentication mechanism during TLS handshake, the DANE
> client authentication draft seems to be in the right direction.
> 
> Is the draft not updated (since 2017) because the draft is not viable
> operationally or is it just due to lack of interest?
> 
> I did not get this information from the mailing list archive.

The working group shut down before we had a chance to resume progress
on the draft.  There are no fundamental barriers to continuing work,
and I've seen some interest in DANE client auth now and then from others.

At this point the work might need to happen in UTA, if they're willing
to adopt it.

-- 
	Viktor.


> On Apr 11, 2019, at 6:57 AM, Sandoche Balakrichenan <sandoche.balakrichenan@afnic.fr> wrote:
> 
> Shumon and Viktor,
> 
> I have an Internet of Things (IoT) use-case, in which i am evaluating
> using TLSA RR for both server and client authentication.
> 
> For the client authentication mechanism during TLS handshake, the DANE
> client authentication draft seems to be in the right direction.
> 
> Is the draft not updated (since 2017) because the draft is not viable
> operationally or is it just due to lack of interest?
> 
> I did not get this information from the mailing list archive.
> 
> Sandoche.
> 
> 
> On 14/01/2016 03:49, John Levine wrote:
>>> This forces clients that use both TCP and UDP to publish their TLSA
>>> records twice (or better publish one as a CNAME for the other, or
>>> make both CNAMEs to a third thing).  Is this really worth it?
>> How much of a problem has it been for TLSA server records?  I honestly don't
>> know but I'd be surprised if the answer were other than "not much".  
>> 
>> Creating the certificate and turning that into the right hex for the
>> TLSA master record seems vastly harder than adding a CNAME which, if
>> you are right that nobody ever does anything different on TCP and UDP,
>> could be added mechanically.
>> 
>> R's,
>> John
>> 
>> _______________________________________________
>> dane mailing list
>> dane@ietf.org
>> https://www.ietf.org/mailman/listinfo/dane
> 
> 

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email