From nobody Thu Apr 11 03:57:42 2019 Return-Path: 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 9A81F1201B6 for ; Thu, 11 Apr 2019 03:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 RCminndE36XE for ; Thu, 11 Apr 2019 03:57:38 -0700 (PDT) Received: from mx4.nic.fr (mx4.nic.fr [IPv6:2001:67c:2218:2::4:12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1E3212011D for ; Thu, 11 Apr 2019 03:57:37 -0700 (PDT) Received: from mx4.nic.fr (localhost [127.0.0.1]) by mx4.nic.fr (Postfix) with SMTP id EAF73288C85; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) Received: by mx4.nic.fr (Postfix, from userid 500) id E421F288C95; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) Received: from relay01.prive.nic.fr (relay01.prive.nic.fr [IPv6:2001:67c:2218:15::11]) by mx4.nic.fr (Postfix) with ESMTP id DAA64288C85; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) Received: from zimbra.afnic.fr (hebe.prod-int.prive.th3.nic.fr [10.1.81.80]) by relay01.prive.nic.fr (Postfix) with ESMTP id D6F436424E47; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id D06272D7C8B1; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BitC4lCGz4g4; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by zimbra.afnic.fr (Postfix) with ESMTP id 6BD062D7CA2D; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.afnic.fr Received: from zimbra.afnic.fr ([127.0.0.1]) by localhost (zimbra.afnic.fr [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kkBZTkCRT7KT; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) Received: from [10.10.86.48] (unknown [10.10.86.48]) by zimbra.afnic.fr (Postfix) with ESMTPSA id 50ECE2D7C8B1; Thu, 11 Apr 2019 12:57:34 +0200 (CEST) To: shuque@gmail.com References: <20160114024910.67019.qmail@ary.lan> Cc: dane@ietf.org, ietf-dane@dukhovni.org From: Sandoche Balakrichenan Openpgp: preference=signencrypt Message-ID: <1b9fca81-c4cf-6f15-b9ee-bef4eef1320a@afnic.fr> Date: Thu, 11 Apr 2019 12:57:34 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20160114024910.67019.qmail@ary.lan> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US X-Bogosity: No, tests=bogofilter, spamicity=0.151428, version=1.2.2 X-PMX-Version: 6.0.0.2142326, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.4.11.103016 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 10:57:41 -0000 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 From nobody Thu Apr 11 10:14:43 2019 Return-Path: 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 ; 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 ; 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 ; 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 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 X-Mailer: Apple Mail (2.3445.104.8) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2019 17:14:42 -0000 > On Apr 11, 2019, at 6:57 AM, Sandoche Balakrichenan = wrote: >=20 > I have an Internet of Things (IoT) use-case, in which i am evaluating > using TLSA RR for both server and client authentication. >=20 > For the client authentication mechanism during TLS handshake, the DANE > client authentication draft seems to be in the right direction. >=20 > Is the draft not updated (since 2017) because the draft is not viable > operationally or is it just due to lack of interest? >=20 > 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. --=20 Viktor. > On Apr 11, 2019, at 6:57 AM, Sandoche Balakrichenan = wrote: >=20 > Shumon and Viktor, >=20 > I have an Internet of Things (IoT) use-case, in which i am evaluating > using TLSA RR for both server and client authentication. >=20 > For the client authentication mechanism during TLS handshake, the DANE > client authentication draft seems to be in the right direction. >=20 > Is the draft not updated (since 2017) because the draft is not viable > operationally or is it just due to lack of interest? >=20 > I did not get this information from the mailing list archive. >=20 > Sandoche. >=20 >=20 > 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". =20= >>=20 >> 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. >>=20 >> R's, >> John >>=20 >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane >=20 >=20 --=20 Viktor. From nobody Thu Apr 11 18:08:26 2019 Return-Path: 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 4EA49120464 for ; Thu, 11 Apr 2019 18:08:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 6zRsUEAzpMtB for ; Thu, 11 Apr 2019 18:08:22 -0700 (PDT) Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 8C83A1200A0 for ; Thu, 11 Apr 2019 18:08:22 -0700 (PDT) Received: by mail-it1-x136.google.com with SMTP id x132so13015355itf.2 for ; Thu, 11 Apr 2019 18:08:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=efr1e6b0GCtWPneDbfc4ayOgZNWZyXnP1ho2D6G37po=; b=CdN6eF1n3uARqn7D+vCGS4klElD02IJdFS3j40mBoy69TDBc25uQAqHwonGf1LpATR xfoySBBX9FfgiCYes7eON97TxjMHY45+tJkHuErVKxrh7UtgJjelMeBa++/0czicTziX uYsBapGdL+zQbJjNZ0otDojNKQ39fPqc5JN2PQj/CFIu6LNDwAFDe/H+us1KDOahuVCz h2utttfydSyJ5Vz6nXCc0dlzsxQrBg1nlfcED8VZaNmIWM/Y95d+7Zat/mq1Bb5mQFek PMmcuHbBsVI6IasEgX8YU7vRd6lSwgq4oQGJkM6T9VRoIwN496pMvY/5cd/OLrxpvNDe C/Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=efr1e6b0GCtWPneDbfc4ayOgZNWZyXnP1ho2D6G37po=; b=ufDfdNPKP7jW0Ab9HiHv2XNwv/+rxpaD54zdZJfC41f564jZUIPj3iMNiWrZ2drzKr PwtvHv6WpBIQbLNR4X97n8PnjjdbGC2OPYaGHwytPKj+wFrm3vrAeeS1FqBeFhfd72zz QKrMlNsJblZNbH/d+sa38XbP47D8hcVLjudhky4Gin0eXVNXX6LrYZ3QaZdzP7hZoiT9 7vmyZmqZx9n+rgjkPOVImzWuHI7PLXWeNaEnzSPh3MWOVleV7RwSN972lRsOYQpoOS/W G2egeNCzFiZ0CyfcX5r86R04Y0HPGixLB2d9vcbuqmWutVuFTST9cKJzdDsN5tT91PbY Zn3w== X-Gm-Message-State: APjAAAWkhzEw91lGesasM+aQ6g5PvfvDtL6/m4kYM/JZm5pv2FiUzyge M8dB+kpIvgbWD0Y1zRRXs5u01bS/soXWnBK37VcErA== X-Google-Smtp-Source: APXvYqw3/vajimiPVnphkRi6crGJTCP8pfskzQE/1U/cvMzfemc8s7BGMPohuMMt0FhZ+PUkhl2qy5nul5Dy1ZKmGkc= X-Received: by 2002:a24:89c3:: with SMTP id s186mr11659939itd.112.1555031301495; Thu, 11 Apr 2019 18:08:21 -0700 (PDT) MIME-Version: 1.0 References: <20160114024910.67019.qmail@ary.lan> <1b9fca81-c4cf-6f15-b9ee-bef4eef1320a@afnic.fr> <1B9C84C7-A1DE-48DE-AD2B-4340CBD3F0DC@dukhovni.org> In-Reply-To: <1B9C84C7-A1DE-48DE-AD2B-4340CBD3F0DC@dukhovni.org> From: Shumon Huque Date: Thu, 11 Apr 2019 21:08:10 -0400 Message-ID: To: "" Content-Type: multipart/alternative; boundary="00000000000057210a05864af076" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2019 01:08:24 -0000 --00000000000057210a05864af076 Content-Type: text/plain; charset="UTF-8" On Thu, Apr 11, 2019 at 1:14 PM Viktor Dukhovni wrote: > > 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. > If there is additional interest in this draft now, and we can find a home for the work, I would be happy to revive it and try to push it forward. Shumon. --00000000000057210a05864af076 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Apr 11, 2019 at 1:14 PM Viktor Du= khovni <ietf-dane@dukhovni.org= > wrote:
> On Apr 11, 2019, at 6:57 AM, Sandoche Balak= richenan <sandoche.balakrichenan@afnic.fr> wrote:
>
> I have an Internet of Things (IoT) use-case, in which i am evaluating<= br> > 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<= br> > 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.=C2=A0 There are no fundamental barriers to continuing work, and I've seen some interest in DANE client auth now and then from other= s.

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

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

If = there is additional interest in this draft now, and we can find a home for<= /div>
the work, I would be happy to revive it and try to push it forwar= d.

Shumon.

--00000000000057210a05864af076--