From paul@nohats.ca Sun Jan 5 18:10:00 2014 Return-Path: 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 C1B341ADF31; Sun, 5 Jan 2014 18:10:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.639 X-Spam-Level: X-Spam-Status: No, score=-0.639 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] 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 fBC0HY8EwbCX; Sun, 5 Jan 2014 18:09:58 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 3A5371ADF44; Sun, 5 Jan 2014 18:09:56 -0800 (PST) Received: by bofh.nohats.ca (Postfix, from userid 500) id 7128A80055; Sun, 5 Jan 2014 21:09:46 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1388974186; bh=9+Ih7YDuwO+rpCA0MXU8scmnpS35MvVu3/GsPoq79+s=; h=Date:From:To:Subject; b=VcqJ3QizgoAEmm6EtS5qpJ77NKrv8KGFHOtdbh8oMzaI9Lyli+BnH31iFgTUuTLFr 2M1SdNXCU8tdvdgiLtTmIsRy1IYv1XTxEMJeEukySomDvfSzczdEt+jlT8WE6Nobba a9+2fls6RjYLvA/X1i5ik9rdYB7jUpjGo3nfCHoQ= Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 5DCD880048; Sun, 5 Jan 2014 21:09:46 -0500 (EST) Date: Sun, 5 Jan 2014 21:09:46 -0500 (EST) From: Paul Wouters To: dane WG list , openpgp@ietf.org, dnssec-deployment Message-ID: User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: [dane] first release of openpgpkey-milter, DANE assisted GnuPG email encryption milter X-BeenThere: dane@ietf.org 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: Mon, 06 Jan 2014 02:10:01 -0000 I've released the first version of openpgpkey-milter, a sendmail/postfix milter service that attempts to automatically encrypt emails using gnupg based on the precense of a DNSSEC signed OPENPGPKEY record as specified in http://tools.ietf.org/html/draft-wouters-dane-openpgp It currently uses the private-use RRTYPE 65280. Version 2.3 of hash-slinger has a new openpgpkey command that you can use to generate OPENPGPKEY records. It supports generating the generic type syntax. (http://people.redhat.com/pwouters/hash-slinger/) My paul@nohats.ca email address is pusblishing this record. Feel free to send me test emails, although if you don't hear back from me, perhaps follow up at paul@cypherpunks.ca :) This initial version does not yet handle multipart / MIME emails, and the python-gnupg module has some known bugs with utf-8 / IDN. Punycode support is also not included in this release. It was also not stress tested on a busy mail server. You can grab the tar ball at ftp://ftp.nohats.ca/openpgpkey-milter/ or have a look at https://github.com/letoams/openpgpkey-milter/ Enjoy! Paul From ogud@ogud.com Mon Jan 6 10:25:33 2014 Return-Path: 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 22E581AE168 for ; Mon, 6 Jan 2014 10:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.499 X-Spam-Level: X-Spam-Status: No, score=-0.499 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] 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 lEYxPtiB6ROi for ; Mon, 6 Jan 2014 10:25:30 -0800 (PST) Received: from smtp124.ord1c.emailsrvr.com (smtp124.ord1c.emailsrvr.com [108.166.43.124]) by ietfa.amsl.com (Postfix) with ESMTP id 69A6C1AE0F7 for ; Mon, 6 Jan 2014 10:25:30 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id DF2961A0096 for ; Mon, 6 Jan 2014 13:25:21 -0500 (EST) X-Virus-Scanned: OK Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 74C081A018E for ; Mon, 6 Jan 2014 13:25:20 -0500 (EST) From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_1A8A55E5-D662-4D4A-B0B3-392BA70304A9" Message-Id: Date: Mon, 6 Jan 2014 13:25:24 -0500 To: "dane@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [dane] draft-wouters-dane-openpgp-01 review X-BeenThere: dane@ietf.org 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: Mon, 06 Jan 2014 18:25:33 -0000 --Apple-Mail=_1A8A55E5-D662-4D4A-B0B3-392BA70304A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii This is an interesting draft and looks like a good idea,=20 I just reviewed the draft with an eye if it is ready to be used as = reference for DNS RRYTPE template submission.=20 The draft specifies that Presentation Format for the RRTYPE is Base64 = (good)=20 The draft specifies that the WIRE Format for the RRTYPE is Base64 (bad)=20= I suggest that the draft be expanded to talk about Presentation format = and Wire Format separately.=20 Making this change in the draft will require that Paul needs to update = his tool that he released today.=20 Nits and questions:=20 Section 3 says: "If an an OPENPGPKEY RR contains an expired OpenPGP public key, it MUST NOT be used for encryption."=20 Suggest: "SHOULD" instead=20 Section 3.1 I propose that this section be moved into Section 4, leaving = only=20 3 and 3.2 in section 3.=20 Section 3 then only defines the DNS RR=20 Section 4 then deals with location of the records in zones and how to = convert "email address" into DNS labels.=20 Section 4.4 (KEY size and record size issues) is orthogonal to section = 4. and should (it you keep it) become a new section on usage and operational guidance.=20 In addition to talk about key size it should recommend that a user = SHOULD only have one Active record, i.e. the key it wants others to use to use for encryption.=20 Section 7: should become an appendix (how to generate a record)=20 Question: Transitioning trust from old key to new key is not covered in = this draft, should it ?=20 Olafur --Apple-Mail=_1A8A55E5-D662-4D4A-B0B3-392BA70304A9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii If an an OPENPGPKEY RR contains an expired = OpenPGP
   =
public key, it MUST NOT be used for encryption." 

Suggest: "SHOULD" =
instead 
Section 3.1 I =
propose that this section be moved into Section 4, leaving only 
3 and 3.2 in section 3. 
Section 3 then only =
defines the DNS RR 
DNS labels. 

Section 4.4 (KEY size and record size =
issues) is orthogonal to section 4. and should (it you keep it) become a =
new section
on =
usage and operational guidance. 
In addition to talk about key size it =
should recommend that a user SHOULD only have one Active record, i.e. =
the key
it wants others to =
use to use for encryption. 

Section 7: should become an appendix (how =
to generate a record) 
Question: =
Transitioning trust from old key to new key is not covered in this =
draft, should it ? 

	=
Olafur

    public key, it MUST NOT be used for encryption." 
> 
> Suggest: "SHOULD" instead 

Why should "expired" keys not be used?  So long as the RRSIG on
the OPENPGPKEY record is not expired, the key is not "expired".
If none of the key metadata is authenticated independently from
DNSSEC, we only learn an expiration date modulo the validity of
the DNSSEC identity to key binding and if we trust that, why not
trust the key?  If the key is really expired, it should be replaced
in DNS.

-- 
	Viktor.

From internet-drafts@ietf.org  Mon Jan  6 13:29:14 2014
Return-Path: 
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 82A0B1AE24C; Mon,  6 Jan 2014 13:29:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZgxaSMX0RilG; Mon,  6 Jan 2014 13:29:13 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D98121AE24E; Mon,  6 Jan 2014 13:29:11 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140106212911.12960.24322.idtracker@ietfa.amsl.com>
Date: Mon, 06 Jan 2014 13:29:11 -0800
Cc: dane@ietf.org
Subject: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jan 2014 21:29:14 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the DNS-based Authentication of Named Entitie=
s Working Group of the IETF.

        Title           : Using Secure DNS to Associate Certificates with D=
omain Names For S/MIME
        Authors         : Paul Hoffman
                          Jakob Schlyter
	Filename        : draft-ietf-dane-smime-03.txt
	Pages           : 6
	Date            : 2014-01-06

Abstract:
   This document describes how to use secure DNS to associate an S/MIME
   user's certificate with the intended domain name, similar to the way
   that DANE (RFC 6698) does for TLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smime-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From internet-drafts@ietf.org  Mon Jan  6 14:45:44 2014
Return-Path: 
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 2F7BB1AE2B1; Mon,  6 Jan 2014 14:45:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 S1HMLejT00LP; Mon,  6 Jan 2014 14:45:42 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF1811AE2B2; Mon,  6 Jan 2014 14:45:41 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140106224541.29552.83393.idtracker@ietfa.amsl.com>
Date: Mon, 06 Jan 2014 14:45:41 -0800
Cc: dane@ietf.org
Subject: [dane] I-D Action: draft-ietf-dane-registry-acronyms-03.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 06 Jan 2014 22:45:44 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the DNS-based Authentication of Named Entitie=
s Working Group of the IETF.

        Title           : Adding acronyms to simplify DANE conversations
        Author          : Olafur Gudmundsson
	Filename        : draft-ietf-dane-registry-acronyms-03.txt
	Pages           : 5
	Date            : 2014-01-06

Abstract:
   Experience has show that people get confused using the three numeric
   fields the TLSA record.  This document specifies descriptive acronyms
   for the three numeric fields in the TLSA records.  This document
   updates the format of the IANA registry created by RFC6698.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-registry-acronyms-03


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From warren@kumari.net  Mon Jan  6 15:28:48 2014
Return-Path: 
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 533C41AE2EE for ; Mon,  6 Jan 2014 15:28:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 f4OfijiUOWUR for ; Mon,  6 Jan 2014 15:28:41 -0800 (PST)
Received: from mail-we0-f175.google.com (mail-we0-f175.google.com [74.125.82.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4DF091AE303 for ; Mon,  6 Jan 2014 15:28:31 -0800 (PST)
Received: by mail-we0-f175.google.com with SMTP id t60so16548169wes.34 for ; Mon, 06 Jan 2014 15:28:15 -0800 (PST)
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:content-type; bh=Zzlhq0EdtyaMTFLrWp8m94JrRyb2vAD4variXQ1u8Pc=; b=axyzqDJBbVtVvIXiyAdpKaKVCp48vhhVvnacU5urPJ6d/v10965bsnqqeCMJzKEML5 ZeEraOedEaI1MlnkrB5wQJC1Ggec01z7taNOPjh/XtrP7AC/rYkV6XCAs7lrhQ8k10TM J5nbxhJARxlPp0pN+23EyiPQlWNzuaTAfYdNkDPuGOdvAyIeYJr4q+icjK5ofrPsjPZ+ WWPEVC9NuiJckh3aO0k4NLJLUr5wDZ5AZ4VJN+zGPrBF9HNhGNG7ngg3XWlhXCGiSFqc M25H/fsRSMkOLH8fWVgPjqJRC125z9V8KA5vXEZcoxL6GPwloRKA5WC3EUnaNG1V1krw D/AA==
X-Gm-Message-State: ALoCoQlqt7izC4+WeDYxbAkI2nrZqYjU8SLDC3KPgrNRB4DTyq/d2D1ndnxnEZULpBqahEcHuQhf
MIME-Version: 1.0
X-Received: by 10.180.93.196 with SMTP id cw4mr14412863wib.39.1389050895323; Mon, 06 Jan 2014 15:28:15 -0800 (PST)
Received: by 10.194.54.167 with HTTP; Mon, 6 Jan 2014 15:28:15 -0800 (PST)
X-Originating-IP: [98.244.98.35]
In-Reply-To: <20140106224541.29552.83393.idtracker@ietfa.amsl.com>
References: <20140106224541.29552.83393.idtracker@ietfa.amsl.com>
Date: Mon, 6 Jan 2014 18:28:15 -0500
Message-ID: 
From: Warren Kumari 
To: dane@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-03.txt
X-BeenThere: dane@ietf.org
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: Mon, 06 Jan 2014 23:28:48 -0000

On Mon, Jan 6, 2014 at 5:45 PM,   wrote:
>
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.

This just adds a note to the abstract explaining that it updates the
format of the registry in RFC6698 (to keep the nitter happy...)
W

>
>         Title           : Adding acronyms to simplify DANE conversations
>         Author          : Olafur Gudmundsson
>         Filename        : draft-ietf-dane-registry-acronyms-03.txt
>         Pages           : 5
>         Date            : 2014-01-06
>
> Abstract:
>    Experience has show that people get confused using the three numeric
>    fields the TLSA record.  This document specifies descriptive acronyms
>    for the three numeric fields in the TLSA records.  This document
>    updates the format of the IANA registry created by RFC6698.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/
>
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-03
>
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-registry-acronyms-03
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane

From marka@isc.org  Mon Jan  6 18:10:55 2014
Return-Path: 
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 9A45F1AE3CB for ; Mon,  6 Jan 2014 18:10:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.161
X-Spam-Level: 
X-Spam-Status: No, score=0.161 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, 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 pesVzUgNMbS0 for ; Mon,  6 Jan 2014 18:10:54 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 38BD31ADF2E for ; Mon,  6 Jan 2014 18:10:54 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id E1D08C947C for ; Tue,  7 Jan 2014 02:10:32 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1389060645; bh=MHYOYpaxKH4U1StFyXNwa3I+hipSCDaRNYm/Hb7i8Sg=; h=To:From:References:Subject:In-reply-to:Date; b=WhOqHoYbssO6umL2tNQPYsXvTgEcJfaVpPPFJ4ECE+mWW8/yo5xHkIhQxZCfEWY3q e4B6awpMZglItpdVOai7vkI9fAZQP6ZqBR6GdTj33yrwSlnTzIoYf8Uiozp6c82SSH f7IzMPmFihf4V4sj7Qefx/0RgP2Wnlfccqkp4MrY=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Tue,  7 Jan 2014 02:10:32 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id AA2D2160446 for ; Tue,  7 Jan 2014 02:20:49 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 7C90A160050 for ; Tue,  7 Jan 2014 02:20:49 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id A6C6BC772A3 for ; Tue,  7 Jan 2014 13:11:42 +1100 (EST)
To: "dane@ietf.org list" 
From: Mark Andrews 
References: 
In-reply-to: Your message of "Mon, 06 Jan 2014 13:25:24 -0500." 
Date: Tue, 07 Jan 2014 13:11:42 +1100
Message-Id: <20140107021142.A6C6BC772A3@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
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: Tue, 07 Jan 2014 02:10:55 -0000

Section 3.1 has lots of factually incorrect rationals for
encoding using base32.  The DNS is capable of encoding
binary data in labels up to 63 octets.  I've got no problem
with encoding, but if one intends to include rationalisations
please make them factually correct.

There is no mention of how to encode LHS which exceed 63 octets
when encoded using base32.  Pack the left most labels or the
right most labels?

There is no mention of how to normalise LHS prior to base32 encoding.
Are "Hugh" and "hugh" the same?  Should "hugh" and "hugh+xxx" be
treated the same?  It should be possible to specify normalisation
rules and store them at _openpgpkey.  Is the input UTF-8 or some
other character set.  If UTF-8 what normalisations need to be
applied?

It might be useful to suppress the padding at the end of base32
encoded strings.  We already do similar suppression with NSEC3
records.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From paul@nohats.ca  Mon Jan  6 20:31:04 2014
Return-Path: 
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 A2DC81AE428 for ; Mon,  6 Jan 2014 20:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.338
X-Spam-Level: 
X-Spam-Status: No, score=-1.338 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, J_CHICKENPOX_48=0.6, RP_MATCHES_RCVD=-0.538] autolearn=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 DJM8htZafgk6 for ; Mon,  6 Jan 2014 20:31:03 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC571ADF7B for ; Mon,  6 Jan 2014 20:31:03 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 51D6A80055; Mon,  6 Jan 2014 23:30:54 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1389069054; bh=xlx+xPs6PO1HNGJzH98LCCwxiu9cLZhxXtY+WSwf7aA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=hXD/Qm9magPBEmwlsNpPC6O2fJI5rKZYon8PI7AufiGNfgxPCSD7MVQ3IKkIYRKWu PzRGxiMAf4FW0I4C9CD3Ux7y1OgkTnJSbuTZWBEdPVk4J/O5E2Za4F13qXziTyI3Z9 jIUUGPle9ZAvOHGKh1LlkhrDomchM6naBPGRj67I=
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 4185E80048; Mon,  6 Jan 2014 23:30:54 -0500 (EST)
Date: Mon, 6 Jan 2014 23:30:54 -0500 (EST)
From: Paul Wouters 
To: Mark Andrews 
In-Reply-To: <20140107021142.A6C6BC772A3@rock.dv.isc.org>
Message-ID: 
References:  <20140107021142.A6C6BC772A3@rock.dv.isc.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: "dane@ietf.org list" 
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
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: Tue, 07 Jan 2014 04:31:04 -0000

On Tue, 7 Jan 2014, Mark Andrews wrote:

Thanks for the review Mark.

> Section 3.1 has lots of factually incorrect rationals for
> encoding using base32.  The DNS is capable of encoding
> binary data in labels up to 63 octets.  I've got no problem
> with encoding, but if one intends to include rationalisations
> please make them factually correct.

I took those from draft-hoffman-dane-smime-01, Paul Hoffman and
Jacob Schlyter believe these to be right as well? Can you explain
what's wrong or perhaps write a replacement paragraph that would
agree with you more? It's mostly there to explain why we did not
end up using username._openpgpkey.domain.com and require base32 encoding.

> There is no mention of how to encode LHS which exceed 63 octets
> when encoded using base32.  Pack the left most labels or the
> right most labels?

Is that really a use-case we need to cover? How many _real_ +- 50+ LHS
character email addresses do people use? I'm happy to document the
limitation, a little more reserved for specifying tricks to go beyond.
For example, http://tools.ietf.org/html/rfc6763 mentions this limit too
in context of UTF8,unicode,Kanji without defining anything to extend
this limit.

> There is no mention of how to normalise LHS prior to base32 encoding.

That was discussed offline, but you are right in that the result of
that discussion is missing. Since there seems to be great variety in
how SMTP servers normalise the LHS, we did not want to enforce our
one normalisation.

> Are "Hugh" and "hugh" the same?

That really depends on the SMTP server implementation, the OS it runs
on, the email client used by the sender, etc.

> Should "hugh" and "hugh+xxx" be treated the same?

I don't think so? The "+" sign as magic "this is the same user as"
is also not a feature supported by all SMTP servers or specified in
a standard, correct? And people might want to use different keys for
paul+personal versus paul+ietf.

> It should be possible to specify normalisation
> rules and store them at _openpgpkey.

But those rules could change if the SMTP implementation changes?

So, this document is leaving these as unclear as whether your email
will arrive at all or not based on the presence or absence of
normalisation rules of the SMTP server.

> It might be useful to suppress the padding at the end of base32
> encoded strings.  We already do similar suppression with NSEC3
> records.

Unlike NSEC3 we will see some interaction with userland tools and humans
that will use stock base32 that produces the padding. So I have a slight
preference to stick with the output generated by standard base32 code in
the hope that it will be less confusing to users and developers.

Paul

From paul@nohats.ca  Mon Jan  6 20:35:28 2014
Return-Path: 
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 035D41ADF7E for ; Mon,  6 Jan 2014 20:35:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] 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 2o5faj0oskYN for ; Mon,  6 Jan 2014 20:35:26 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 7B2D51ADF7B for ; Mon,  6 Jan 2014 20:35:26 -0800 (PST)
Received: by bofh.nohats.ca (Postfix, from userid 500) id 8846C80055; Mon,  6 Jan 2014 23:35:17 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1389069317; bh=9qiUQguIWvC17zX5n7Jf70hlvebNdMsLbMIyahAVdf0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=tGk282bTaQkF5QdQc6P4Emg5PH+djV9qoT/F8sLAcTKkSy7+3iMiFBtTUKZAYNLwD VzzkLF9giKShNuUWD2hXltpYeGC/vSnBqwDmNuP0rwpbwqeVsyIWvh8ape+AFTHViC eGGS3eXSXU8/nn99r/9NLydh4rIRK9wLtPbGw/qk=
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 75EC380048; Mon,  6 Jan 2014 23:35:17 -0500 (EST)
Date: Mon, 6 Jan 2014 23:35:17 -0500 (EST)
From: Paul Wouters 
To: Olafur Gudmundsson 
In-Reply-To: 
Message-ID: 
References: 
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8BIT
Cc: "dane@ietf.org list" 
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
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: Tue, 07 Jan 2014 04:35:28 -0000

On Mon, 6 Jan 2014, Olafur Gudmundsson wrote:

> I just reviewed the draft with an eye if it is ready to be used as reference for DNS RRYTPE template submission. 
> 
> The draft specifies that Presentation Format for the RRTYPE is Base64 (good) 
> The draft specifies that the WIRE Format for the RRTYPE is Base64 (bad) 
> 
> I suggest that the draft be expanded to talk about Presentation format and Wire Format separately. 

That was a very good point and unclear in the document. I've addressed
these and will submit the new version soon.

> Making this change in the draft will require that Paul needs to update his tool that he released today. 

That's fine :)

> Nits and questions: 
> Section 3 says: "If an an OPENPGPKEY RR contains an expired OpenPGP
>
>    public key, it MUST NOT be used for encryption." 
> 
> Suggest: "SHOULD" instead 
> 
> Section 3.1 I propose that this section be moved into Section 4, leaving only 
> 
> 3 and 3.2 in section 3. 
> 
> Section 3 then only defines the DNS RR 
> 
> Section 4 then deals with location of the records in zones and how to convert "email address" into
> 
> DNS labels. 
> 
> Section 4.4 (KEY size and record size issues) is orthogonal to section 4. and should (it you keep it) become a new section
> 
> on usage and operational guidance. 
> 
> In addition to talk about key size it should recommend that a user SHOULD only have one Active record, i.e. the key
> 
> it wants others to use to use for encryption. 
> 
> Section 7: should become an appendix (how to generate a record)

I've made these changes, and after some more talking decided to split
this document in two. One for just the technical specification of the
DNS record, and one for the recommended usage of the DNS record.

> Question: Transitioning trust from old key to new key is not covered in this draft, should it ?

I don't think so. I cannot come up with any good "rollover advise" I
would give other than "replace the DNS record once you have a new PGP
key". Whether you lost your old PGP key or not, when you are ready for
the new PGP key, you can just remove the old one.

Paul


From marka@isc.org  Mon Jan  6 21:26:40 2014
Return-Path: 
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 146571AE435 for ; Mon,  6 Jan 2014 21:26:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.239
X-Spam-Level: 
X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 feQQSjsm5buY for ; Mon,  6 Jan 2014 21:26:37 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id 25DF61AE434 for ; Mon,  6 Jan 2014 21:26:37 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 1EF082383D7; Tue,  7 Jan 2014 05:26:15 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id E82DC1602B4; Tue,  7 Jan 2014 05:36:31 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 84FC8160050; Tue,  7 Jan 2014 05:36:31 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 4EBA9C79C09; Tue,  7 Jan 2014 16:27:24 +1100 (EST)
To: Paul Wouters 
From: Mark Andrews 
References:  <20140107021142.A6C6BC772A3@rock.dv.isc.org> 
In-reply-to: Your message of "Mon, 06 Jan 2014 23:30:54 -0500." 
Date: Tue, 07 Jan 2014 16:27:24 +1100
Message-Id: <20140107052724.4EBA9C79C09@rock.dv.isc.org>
Cc: "dane@ietf.org list" 
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
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: Tue, 07 Jan 2014 05:26:40 -0000

In message , Paul Wouters wr
ites:
> On Tue, 7 Jan 2014, Mark Andrews wrote:
> 
> Thanks for the review Mark.
> 
> > Section 3.1 has lots of factually incorrect rationals for
> > encoding using base32.  The DNS is capable of encoding
> > binary data in labels up to 63 octets.  I've got no problem
> > with encoding, but if one intends to include rationalisations
> > please make them factually correct.
> 
> I took those from draft-hoffman-dane-smime-01, Paul Hoffman and
> Jacob Schlyter believe these to be right as well? Can you explain
> what's wrong or perhaps write a replacement paragraph that would
> agree with you more? It's mostly there to explain why we did not
> end up using username._openpgpkey.domain.com and require base32 encoding.
> 
> > There is no mention of how to encode LHS which exceed 63 octets
> > when encoded using base32.  Pack the left most labels or the
> > right most labels?
> 
> Is that really a use-case we need to cover?

Yes.  Lots of mail systems use real names and some people have long names.

> How many _real_ +- 50+ LHS character email addresses do people use?

The fact that you can't answer that is the reason you need to support
them.

> I'm happy to document the
> limitation, a little more reserved for specifying tricks to go beyond.
> For example, http://tools.ietf.org/html/rfc6763 mentions this limit too
> in context of UTF8,unicode,Kanji without defining anything to extend
> this limit.
>
> > There is no mention of how to normalise LHS prior to base32 encoding.
> 
> That was discussed offline, but you are right in that the result of
> that discussion is missing. Since there seems to be great variety in
> how SMTP servers normalise the LHS, we did not want to enforce our
> one normalisation.

I didn't say enforce one normalisation, though you should specify
how to handle all the forms of Postmaster as that is required to
be treated as a case insensitive value.

> > Are "Hugh" and "hugh" the same?
> 
> That really depends on the SMTP server implementation, the OS it runs
> on, the email client used by the sender, etc.
> 
> > Should "hugh" and "hugh+xxx" be treated the same?
> 
> I don't think so? The "+" sign as magic "this is the same user as"
> is also not a feature supported by all SMTP servers or specified in
> a standard, correct? And people might want to use different keys for
> paul+personal versus paul+ietf.

And this is not a decision that needs to made by us.  This is a decision
that should be made by the publisher of the data.  One could even have
a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/"

> > It should be possible to specify normalisation
> > rules and store them at _openpgpkey.
> 
> But those rules could change if the SMTP implementation changes?

So you update the rules.
 
> So, this document is leaving these as unclear as whether your email
> will arrive at all or not based on the presence or absence of
> normalisation rules of the SMTP server.

This is about how to discover the pgp key stored in the DNSN for a
user given a email address.

I know that my email address is in various databases as "marka@isc.org"
and "MARKA@ISC.ORG" despite me entering it as "marka@isc.org" in
all cases.  I still want those who have stored the address as
"MARKA@ISC.ORG" to be able to find my PGP key.  I do not want to
have to add 31 CNAME records to the DNS to account for all the
permutations of MaRkA.

> > It might be useful to suppress the padding at the end of base32
> > encoded strings.  We already do similar suppression with NSEC3
> > records.
> 
> Unlike NSEC3 we will see some interaction with userland tools and humans
> that will use stock base32 that produces the padding. So I have a slight
> preference to stick with the output generated by standard base32 code in
> the hope that it will be less confusing to users and developers.

s/=*// 

> Paul
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From viktor1dane@dukhovni.org  Mon Jan  6 21:44:13 2014
Return-Path: 
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 CD6E91AE390 for ; Mon,  6 Jan 2014 21:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.7
X-Spam-Level: 
X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_44=0.6, J_CHICKENPOX_48=0.6] autolearn=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 JoVCl3_U3dLr for ; Mon,  6 Jan 2014 21:44:12 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8711ADF9F for ; Mon,  6 Jan 2014 21:44:11 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A4AE32AB198; Tue,  7 Jan 2014 05:44:02 +0000 (UTC)
Date: Tue, 7 Jan 2014 05:44:02 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140107054402.GW2317@mournblade.imrryr.org>
References:  <20140107021142.A6C6BC772A3@rock.dv.isc.org>  <20140107052724.4EBA9C79C09@rock.dv.isc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140107052724.4EBA9C79C09@rock.dv.isc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 07 Jan 2014 05:44:14 -0000

On Tue, Jan 07, 2014 at 04:27:24PM +1100, Mark Andrews wrote:

> > I don't think so? The "+" sign as magic "this is the same user as"
> > is also not a feature supported by all SMTP servers or specified in
> > a standard, correct? And people might want to use different keys for
> > paul+personal versus paul+ietf.
> 
> And this is not a decision that needs to made by us.  This is a decision
> that should be made by the publisher of the data.  One could even have
> a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/"

Sorry, CMU-style address extensions are a local matter entirely
outside the world of email standards.  On some domains "+" is
special, on other domains "-", and others still some other convenient
character not used in real email addresses.

It is not possible to handle these without substantially complicating
the logic.  One would have to query the domain for the domain's
recipient delimiter first, and then for the address.

-- 
	Viktor.

From marka@isc.org  Mon Jan  6 22:31:26 2014
Return-Path: 
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 81C721AE44F for ; Mon,  6 Jan 2014 22:31:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.339
X-Spam-Level: 
X-Spam-Status: No, score=-1.339 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, J_CHICKENPOX_48=0.6, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=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 Q8AllCD3tLrr for ; Mon,  6 Jan 2014 22:31:25 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 5139B1AE44D for ; Mon,  6 Jan 2014 22:31:25 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id DD739C949D for ; Tue,  7 Jan 2014 06:31:03 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1389076276; bh=mET37LMUnvFPwS50lptHu67v+XjgJOdN5R4Lo027vXk=; h=To:From:References:Subject:In-reply-to:Date; b=NQL2rZ2VLmpMy+zhj5+wOG5wxbGljAmMoxYPpufgqR2ylGDYUNFZEJwRRLcbdDAfJ G8kYBPtGEgPySbz0VfHxoYZ5ojLZXZm9WuGpQ2C5YMhYyPRb4Whlsq/eqaZ0FD5maL 8PKm1grjIssKSJpOYkoslZSHVv1dR7vFgkKwSOeg=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP for ; Tue,  7 Jan 2014 06:31:03 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 72410160446 for ; Tue,  7 Jan 2014 06:41:21 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 44E0416042E for ; Tue,  7 Jan 2014 06:41:21 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 82D61C7A081 for ; Tue,  7 Jan 2014 17:32:13 +1100 (EST)
To: dane@ietf.org
From: Mark Andrews 
References:  <20140107021142.A6C6BC772A3@rock.dv.isc.org>  <20140107052724.4EBA9C79C09@rock.dv.isc.org> <20140107054402.GW2317@mournblade.imrryr.org>
In-reply-to: Your message of "Tue, 07 Jan 2014 05:44:02 -0000." <20140107054402.GW2317@mournblade.imrryr.org>
Date: Tue, 07 Jan 2014 17:32:13 +1100
Message-Id: <20140107063213.82D61C7A081@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
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: Tue, 07 Jan 2014 06:31:26 -0000

In message <20140107054402.GW2317@mournblade.imrryr.org>, Viktor Dukhovni write
s:
> On Tue, Jan 07, 2014 at 04:27:24PM +1100, Mark Andrews wrote:
> 
> > > I don't think so? The "+" sign as magic "this is the same user as"
> > > is also not a feature supported by all SMTP servers or specified in
> > > a standard, correct? And people might want to use different keys for
> > > paul+personal versus paul+ietf.
> > 
> > And this is not a decision that needs to made by us.  This is a decision
> > that should be made by the publisher of the data.  One could even have
> > a rule which says "if *+* try as is and on nxdomain try /\(*\)+*/\1/"
> 
> Sorry, CMU-style address extensions are a local matter entirely
> outside the world of email standards.  On some domains "+" is
> special, on other domains "-", and others still some other convenient
> character not used in real email addresses.

All of which is irrelevent provided you can encode that into a policy
which can be transmitted.

> It is not possible to handle these without substantially complicating
> the logic.  One would have to query the domain for the domain's
> recipient delimiter first, and then for the address.

So.  One of the reasons to go with base32 and not raw binary is
that the DNS does normalisation which is potentially different to
the normalisation done by the SMTP server.

At a minimum we should be able to specifying "no normalisation" vs
"case fold" (and which direction) for ascii LHS.

Yes, it makes things more complicated but the real world is
complicated.

Remember that one is comparing this to a SRV record which points
to a key server that does all the normalisation required to return
the correct key 100% of the time.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From Jelte.Jansen@sidn.nl  Tue Jan  7 04:23:56 2014
Return-Path: 
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 2934D1ADBD7 for ; Tue,  7 Jan 2014 04:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.444
X-Spam-Level: 
X-Spam-Status: No, score=-0.444 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.538, SPF_PASS=-0.001] autolearn=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 sSmXy5UdTyBU for ; Tue,  7 Jan 2014 04:23:54 -0800 (PST)
Received: from ede1-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) by ietfa.amsl.com (Postfix) with ESMTP id 737C51A1F78 for ; Tue,  7 Jan 2014 04:23:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn_nl; c=relaxed/relaxed;  h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:content-type:content-transfer-encoding:x-originating-ip; bh=AdhBuc2NNrIfT09ls0E7ZHW1W8bdS3CFB8tWrvvQ0Tc=; b=KIK+1osHFGaG7BzGrrksa5XEkDXTraVzYqJDnhXVq9FWjfC5tiGoz3i5Xb8a5lPXzcmmWMWEzyU/CO/2Kgk/oO0xwAbPcYCG2bGLdBI6gOI3XctTaVL33gDyqR++n6Fzwzy+Xs9JbWUk84I44xsOE2Fk0RtfzNuBQ42g6n/zu+U=
Received: from kahubcasn01.SIDN.local ([192.168.2.73]) by ede1-kamx.sidn.nl  with ESMTP id s07CNhiW008075-s07CNhiZ008075 (version=TLSv1 cipher=AES128-SHA bits=128 verify=CAFAIL); Tue, 7 Jan 2014 13:23:44 +0100
Received: from [94.198.152.214] (94.198.152.214) by kahubcasn01.SIDN.local (192.168.2.77) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 7 Jan 2014 13:23:39 +0100
Message-ID: <52CBF1CA.4050800@sidn.nl>
Date: Tue, 7 Jan 2014 13:23:38 +0100
From: Jelte Jansen 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Mark Andrews , 
References:  <20140107021142.A6C6BC772A3@rock.dv.isc.org>  <20140107052724.4EBA9C79C09@rock.dv.isc.org> <20140107054402.GW2317@mournblade.imrryr.org> <20140107063213.82D61C7A081@rock.dv.isc.org>
In-Reply-To: <20140107063213.82D61C7A081@rock.dv.isc.org>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [94.198.152.214]
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
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: Tue, 07 Jan 2014 12:23:56 -0000

On 07-01-14 07:32, Mark Andrews wrote:
>
> All of which is irrelevent provided you can encode that into a policy
> which can be transmitted.
>
>> It is not possible to handle these without substantially complicating
>> the logic.  One would have to query the domain for the domain's
>> recipient delimiter first, and then for the address.
>
> So.  One of the reasons to go with base32 and not raw binary is
> that the DNS does normalisation which is potentially different to
> the normalisation done by the SMTP server.
>
> At a minimum we should be able to specifying "no normalisation" vs
> "case fold" (and which direction) for ascii LHS.
>

Seems to me these are both the same issue, and they could either be 
resolved with one (probably nasty) policy-specification, or not at all 
(leave 'em out like smtp does). Not a big fan of either :)

> Yes, it makes things more complicated but the real world is
> complicated.
>
> Remember that one is comparing this to a SRV record which points
> to a key server that does all the normalisation required to return
> the correct key 100% of the time.
>

Are you suggesting this as a possible solution (which sounds more like 
using DNS(SEC) to specify personal pgp key servers to get around the 
current pgp key server problem)?

(while I type this, I wonder whether this functionality should be on 
this level in the first place; shouldn't it fit better in smtp itself, 
which is the only real place that currently know what normalization and 
other rules apply?)

One small thing on the draft itself: IMO the last part of section 2 
should not use 2119 terminology; it's not about interoperability nor 
implementation. Oh and 'sent' should be 'send' :)

Jelte

From scottr.nist@gmail.com  Wed Jan  8 06:58:59 2014
Return-Path: 
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 19B171AE3F4 for ; Wed,  8 Jan 2014 06:58:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 gdsPfMAuCPsX for ; Wed,  8 Jan 2014 06:58:57 -0800 (PST)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 054EE1AE3C1 for ; Wed,  8 Jan 2014 06:58:57 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 8 Jan 2014 09:58:21 -0500
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 8 Jan 2014 09:58:43 -0500
Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s08EwWx5009804	for ; Wed, 8 Jan 2014 09:58:32 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Scott Rose 
In-Reply-To: <20140106212911.12960.24322.idtracker@ietfa.amsl.com>
Date: Wed, 8 Jan 2014 09:58:31 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com>
To: 
X-Mailer: Apple Mail (2.1827)
X-NIST-MailScanner-Information: 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-BeenThere: dane@ietf.org
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, 08 Jan 2014 14:58:59 -0000

I support this work and would like to see more discussion on the list.  =
Some of us have even proposed text with additions =
(http://www.ietf.org/mail-archive/web/dane/current/msg06180.html). =20

Haven't seen much discussion on the list, and missed the informal DANE =
lunch at the last IETF.  Is there enough interest in having the SMIMEA =
RR?  Some of the changes we offered:

1. naming convention to help distinguish between signing and encryption =
key certs (for enterprises that use separate certs for encrypting and =
signing).  It helps reduce the size of the SMIMEA RRset a bit, but =
admittedly minor compared to the size of an X.509 cert.

2. a new CU value for "revoked" to indicate that this user's =
certificates have been revoked. =20

There are some signed/encrypted email projects rolling out now that are =
using CERT RR's or combinations of SRV RR's and LDAP servers.  Having =
something like SMIME would be an improvement, but the spec needs to be =
finalized. =20

Scott


On Jan 6, 2014, at 4:29 PM, internet-drafts@ietf.org wrote:

>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>=20
>        Title           : Using Secure DNS to Associate Certificates =
with Domain Names For S/MIME
>        Authors         : Paul Hoffman
>                          Jakob Schlyter
> 	Filename        : draft-ietf-dane-smime-03.txt
> 	Pages           : 6
> 	Date            : 2014-01-06
>=20
> Abstract:
>   This document describes how to use secure DNS to associate an S/MIME
>   user's certificate with the intended domain name, similar to the way
>   that DANE (RFC 6698) does for TLS.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dane-smime/
>=20
> There's also a htmlized version available at:
> http://tools.ietf.org/html/draft-ietf-dane-smime-03
>=20
> A diff from the previous version is available at:
> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-03
>=20
>=20
> Please note that it may take a couple of minutes from the time of =
submission
> until the htmlized version and diff are available at tools.ietf.org.
>=20
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane


From internet-drafts@ietf.org  Wed Jan  8 07:23:24 2014
Return-Path: 
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 5A2FA1AE3F7; Wed,  8 Jan 2014 07:23:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 nhrb8ok5huRi; Wed,  8 Jan 2014 07:23:23 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AF2FA1AE448; Wed,  8 Jan 2014 07:23:21 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140108152321.10496.88212.idtracker@ietfa.amsl.com>
Date: Wed, 08 Jan 2014 07:23:21 -0800
Cc: dane@ietf.org
Subject: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 15:23:24 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the DNS-based Authentication of Named Entitie=
s Working Group of the IETF.

        Title           : Using Secure DNS to Associate Certificates with D=
omain Names For S/MIME
        Authors         : Paul Hoffman
                          Jakob Schlyter
	Filename        : draft-ietf-dane-smime-04.txt
	Pages           : 6
	Date            : 2014-01-08

Abstract:
   This document describes how to use secure DNS to associate an S/MIME
   user's certificate with the intended domain name, similar to the way
   that DANE (RFC 6698) does for TLS.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-smime/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-smime-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-04


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From scottr.nist@gmail.com  Wed Jan  8 07:37:38 2014
Return-Path: 
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 B35B21ADF7D for ; Wed,  8 Jan 2014 07:37:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.033
X-Spam-Level: 
X-Spam-Status: No, score=-2.033 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, J_CHICKENPOX_64=0.6, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] autolearn=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 wdEF0MWoNCrW for ; Wed,  8 Jan 2014 07:37:34 -0800 (PST)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 97BE51AE4C0 for ; Wed,  8 Jan 2014 07:37:33 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 8 Jan 2014 10:37:01 -0500
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 8 Jan 2014 10:37:23 -0500
Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s08FbLNU012216	for ; Wed, 8 Jan 2014 10:37:22 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Scott Rose 
In-Reply-To: <52CBF1CA.4050800@sidn.nl>
Date: Wed, 8 Jan 2014 10:37:20 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <52FA9BE6-7334-4AE4-BFD5-9987D079549A@gmail.com>
References:  <20140107021142.A6C6BC772A3@rock.dv.isc.org>  <20140107052724.4EBA9C79C09@rock.dv.isc.org> <20140107054402.GW2317@mournblade.imrryr.org> <20140107063213.82D61C7A081@rock.dv.isc.org> <52CBF1CA.4050800@sidn.nl>
To: 
X-Mailer: Apple Mail (2.1827)
X-NIST-MailScanner-Information: 
Subject: Re: [dane] draft-wouters-dane-openpgp-01 review
X-BeenThere: dane@ietf.org
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, 08 Jan 2014 15:37:39 -0000

On Jan 7, 2014, at 7:23 AM, Jelte Jansen  wrote:

>=20
> One small thing on the draft itself: IMO the last part of section 2 =
should not use 2119 terminology; it's not about interoperability nor =
implementation. Oh and 'sent' should be 'send' :)
>=20

Second.  Also some minor nits that may not have been covered:

Section 3 second paragraph: Should the last sentence (if retrained) be =
moved to Sec. 4?  It discusses key considerations and feels out of place =
here in in the RR description.

Sec 4.3 first paragraph "This public key cannot be used..." Is that part =
of the OpenPGP spec (not familiar with it)?  Otherwise, should it be =
"This public key SHOULD(MUST?) NOT be used if it would only contain the =
key uid "hugh@example.net"'

Sec 4.4 spelling Resoruce/Resource.  Also, "recommended" is in the last =
paragraph - should it be the RFC 2119 keyword RECOMMENDED?  It is a =
solid thing to add in order to reduce problems with large RRsets.

I think this can co-exist with the SMIMEA RR as well.  Wish there was a =
nice way to know which to query for when trying to discover an email =
cert. :)

Scott




> Jelte
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane


From paul.hoffman@vpnc.org  Wed Jan  8 07:54:45 2014
Return-Path: 
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 37DEA1ADF58 for ; Wed,  8 Jan 2014 07:54:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 as2KryNMtX8z for ; Wed,  8 Jan 2014 07:54:44 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 398981AD68A for ; Wed,  8 Jan 2014 07:54:44 -0800 (PST)
Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s08FYWkR078644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 8 Jan 2014 08:34:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman 
In-Reply-To: 
Date: Wed, 8 Jan 2014 07:54:26 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org>
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com> 
To: Scott Rose 
X-Mailer: Apple Mail (2.1827)
Cc: "dane@ietf.org list" 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-BeenThere: dane@ietf.org
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, 08 Jan 2014 15:54:45 -0000

Thanks for the review, Scott. I didn't see it until I has pulled the =
lever on -04 to deal with a few of Mark's comments.

On Jan 8, 2014, at 6:58 AM, Scott Rose  wrote:

> 1. naming convention to help distinguish between signing and =
encryption key certs (for enterprises that use separate certs for =
encrypting and signing).  It helps reduce the size of the SMIMEA RRset a =
bit, but admittedly minor compared to the size of an X.509 cert.

The slight saving of space also introduces a new, significant failure =
mode, namely that if the person listing the cert in the DNS gets the =
type wrong then the receiver can't use it. I'd say "no" on this one.

> 2. a new CU value for "revoked" to indicate that this user's =
certificates have been revoked. =20

We considered things like this for TLSA, and the WG seemed very hesitant =
to have the DNS be used as a second, unofficial revocation mechanism. =
For instance, what would it mean for the DNS to say that an S/MIME cert =
is revoked, but when the user pulls a fresh CRL, the cert isn't there? =
The best we might do is to have a signal for "go refresh your revocation =
view" in the DNS, but that seems like very marginal value.

> There are some signed/encrypted email projects rolling out now that =
are using CERT RR's or combinations of SRV RR's and LDAP servers.  =
Having something like SMIME would be an improvement, but the spec needs =
to be finalized. =20

And Jakob and I apologize for the long lag since the earlier draft. We =
too would like to see this finished.

--Paul Hoffman=

From viktor1dane@dukhovni.org  Wed Jan  8 08:02:07 2014
Return-Path: 
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 C422B1AE4D1 for ; Wed,  8 Jan 2014 08:02:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 npAuFkucMduq for ; Wed,  8 Jan 2014 08:02:05 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id BE4781AD9AD for ; Wed,  8 Jan 2014 08:02:05 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E9632AB190; Wed,  8 Jan 2014 16:01:56 +0000 (UTC)
Date: Wed, 8 Jan 2014 16:01:56 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140108160156.GE2317@mournblade.imrryr.org>
References: <20140108152321.10496.88212.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140108152321.10496.88212.idtracker@ietfa.amsl.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 16:02:08 -0000

On Wed, Jan 08, 2014 at 07:23:21AM -0800, internet-drafts@ietf.org wrote:

> 	Filename        : draft-ietf-dane-smime-04.txt

Given the use of base32 encoding, and explicit non-support for
names that encode to more than 63 bytes of base32 text, I would
like to suggest that trailing "=*" padding be explicitly dropped
from the base32 label allowing for somewhat longer inputs and less
redundant outputs.

With base32, every 5 octets of input text encode to 8 octets of
encoded text, therefore 35 octets encode to 56 octets, but anything
longer encodes to 64 octets which is too long.  Thus inputs with
36-39 octets cannot be represented when the "=" padding is part
of the encoded text.

Also, with say "6" octets of input, e.g. "viktor", we have 48 bits
of input which encodes to 9 full octets of 5 bit per octet output,
plus a short 3 bit encoded octet, and then *7* octets of padding:

	OZUWW5DPOI======

This seems rather wasteful.  The truncated encoding:

    OZUWW5DPOI

carries identical information.

Finally is the word "prohibited" appropriate in the new text:

       Also note that user names can be any length, and labels are
       limited to 63 octets.  Also note that user names that are
       encoded with Base32 are longer than the original user name.
       Any user name that would cause a label of longer than 63
       octets is expressly prohibited by this specification.

I would think "unsupported" or "incompatible" would be closer,
since such local parts remain valid, even though there are incompatible
with SMIMEA.

One way to get around the length limit would be to break up long
encoded strings into multiple labels at each 32 bytes of output
(which decode to 20 bytes of input).  Thus the encoding of "Base32
is a notation for encoding arbitrary byte data using a restricted
set of symbols":

    IJQXGZJTGIQGS4ZAMEQG433UMF2GS33O
    EBTG64RAMVXGG33ENFXGOIDBOJRGS5DS
    MFZHSIDCPF2GKIDEMF2GCIDVONUW4ZZA
    MEQHEZLTORZGSY3UMVSCA43FOQQG6ZRA
    ON4W2YTPNRZQ			// trailing "====" truncated

would result in a multi-label DNS prefix of:

    ijqxgzjtgiqgs4zameqg433umf2gs33o.ebtg64ramvxgg33enfxgoidbojrgs5ds.mfzhsidcpf2gkidemf2gcidvonuw4zza.meqhezltorzgsy3umvsca43foqqg6zra.on4w2ytpnrzq

Allowing for significantly longer local parts (ultimately limited
by the total length of a DNS fqdn when combined with the relevant
suffix derived from the domain part).

-- 
	Viktor.

From paul.hoffman@vpnc.org  Wed Jan  8 08:48:25 2014
Return-Path: 
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 0F9AA1AE016 for ; Wed,  8 Jan 2014 08:48:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 uYdC-qbocur2 for ; Wed,  8 Jan 2014 08:48:23 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id AD4621ADFD7 for ; Wed,  8 Jan 2014 08:48:23 -0800 (PST)
Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s08GSGYO080222 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 8 Jan 2014 09:28:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman 
In-Reply-To: <20140108160156.GE2317@mournblade.imrryr.org>
Date: Wed, 8 Jan 2014 08:48:09 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
References: <20140108152321.10496.88212.idtracker@ietfa.amsl.com> <20140108160156.GE2317@mournblade.imrryr.org>
To: "dane@ietf.org list" 
X-Mailer: Apple Mail (2.1827)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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, 08 Jan 2014 16:48:25 -0000

On Jan 8, 2014, at 8:01 AM, Viktor Dukhovni  =
wrote:

> On Wed, Jan 08, 2014 at 07:23:21AM -0800, internet-drafts@ietf.org =
wrote:
>=20
>> 	Filename        : draft-ietf-dane-smime-04.txt
>=20
> Given the use of base32 encoding, and explicit non-support for
> names that encode to more than 63 bytes of base32 text, I would
> like to suggest that trailing "=3D*" padding be explicitly dropped
> from the base32 label allowing for somewhat longer inputs and less
> redundant outputs.
>=20
> With base32, every 5 octets of input text encode to 8 octets of
> encoded text, therefore 35 octets encode to 56 octets, but anything
> longer encodes to 64 octets which is too long.  Thus inputs with
> 36-39 octets cannot be represented when the "=3D" padding is part
> of the encoded text.

In the real world, there are few users who have LHS user names that are =
more than 30 (or maybe even 20) characters long. What you are proposing =
is "base32 but not really base32" and that could introduce errors in =
libraries looking up the names.

> Also, with say "6" octets of input, e.g. "viktor", we have 48 bits
> of input which encodes to 9 full octets of 5 bit per octet output,
> plus a short 3 bit encoded octet, and then *7* octets of padding:
>=20
> 	OZUWW5DPOI=3D=3D=3D=3D=3D=3D
>=20
> This seems rather wasteful.

Relative to, say, the size of a PKIX certificate? :-)=20

>  The truncated encoding:
>=20
>    OZUWW5DPOI
>=20
> carries identical information.

Yes it does. It also puts a burden on the application to use our new =
"base32ish" encoding instead of the base32 encoding they already have. =
In order to save five bytes.

> Finally is the word "prohibited" appropriate in the new text:
>=20
>       Also note that user names can be any length, and labels are
>       limited to 63 octets.  Also note that user names that are
>       encoded with Base32 are longer than the original user name.
>       Any user name that would cause a label of longer than 63
>       octets is expressly prohibited by this specification.
>=20
> I would think "unsupported" or "incompatible" would be closer,
> since such local parts remain valid, even though there are =
incompatible
> with SMIMEA.

You are right: we'll change to "incompatible" in the next draft.

> One way to get around the length limit would be to break up long
> encoded strings into multiple labels at each 32 bytes of output
> (which decode to 20 bytes of input).  Thus the encoding of "Base32
> is a notation for encoding arbitrary byte data using a restricted
> set of symbols":
>=20
>    IJQXGZJTGIQGS4ZAMEQG433UMF2GS33O
>    EBTG64RAMVXGG33ENFXGOIDBOJRGS5DS
>    MFZHSIDCPF2GKIDEMF2GCIDVONUW4ZZA
>    MEQHEZLTORZGSY3UMVSCA43FOQQG6ZRA
>    ON4W2YTPNRZQ			// trailing "=3D=3D=3D=3D" =
truncated
>=20
> would result in a multi-label DNS prefix of:
>=20
>    =
ijqxgzjtgiqgs4zameqg433umf2gs33o.ebtg64ramvxgg33enfxgoidbojrgs5ds.mfzhsidc=
pf2gkidemf2gcidvonuw4zza.meqhezltorzgsy3umvsca43foqqg6zra.on4w2ytpnrzq
>=20
> Allowing for significantly longer local parts (ultimately limited
> by the total length of a DNS fqdn when combined with the relevant
> suffix derived from the domain part).

I think this is vast overkill for a rarely-needed use case, but I'm open =
to hear where people think LHS names longer than 35 characters are used =
in places where S/MIME or PGP are also used.

--Paul Hoffman=

From viktor1dane@dukhovni.org  Wed Jan  8 09:13:23 2014
Return-Path: 
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 D2B761AE4B5 for ; Wed,  8 Jan 2014 09:13:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jS9wsPrEyj8t for ; Wed,  8 Jan 2014 09:13:20 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 785D31ADFA0 for ; Wed,  8 Jan 2014 09:13:20 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CEC092AB190; Wed,  8 Jan 2014 17:13:10 +0000 (UTC)
Date: Wed, 8 Jan 2014 17:13:10 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140108171310.GF2317@mournblade.imrryr.org>
References: <20140108152321.10496.88212.idtracker@ietfa.amsl.com> <20140108160156.GE2317@mournblade.imrryr.org> <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 08 Jan 2014 17:13:24 -0000

On Wed, Jan 08, 2014 at 08:48:09AM -0800, Paul Hoffman wrote:

> In the real world, there are few users who have LHS user names
> that are more than 30 (or maybe even 20) characters long. What you
> are proposing is "base32 but not really base32" and that could
> introduce errors in libraries looking up the names.

This encoding of localparts to DNS labels is one way only, to
generate query domain labels.  It is not used to encode data that
the consumer will need to decode.  If so, completely standard
encoding routines can be used to generate the base32 text, but the
output can be easily truncated at the first "=" sign.

There is no need to force up to 6 bytes of needless padding into
write-only DNS labels.

> > 	OZUWW5DPOI======
> > 
> > This seems rather wasteful.
> 
> Relative to, say, the size of a PKIX certificate? :-) 

You're right in  absolute terms, it is of course just 1-6 bytes of
waste.  In relative terms however, given the limits on label lengths
and DNS name lengths, every byte can count when you're close to
the limit.  The limits for X.509 certs are much more generous, they
to fit (as a complete chain) into a 16KiB SSL record.

> > One way to get around the length limit would be to break up long
> > encoded strings into multiple labels at each 32 bytes of output
> > (which decode to 20 bytes of input).
> >
> > [...]
> > 
> > Allowing for significantly longer local parts (ultimately limited
> > by the total length of a DNS fqdn when combined with the relevant
> > suffix derived from the domain part).
> 
> I think this is vast overkill for a rarely-needed use case, but
> I'm open to hear where people think LHS names longer than 35
> characters are used in places where S/MIME or PGP are also used.

I think we need to hear from some users with Spanish names who use
full names as local parts.  At previous employer IIRC we had
something along the lines of:

    Ferndando.Fernando.Fernandez@...

which is 28 bytes, perhaps 8 more is not as uncommon as we think,
but I have no examples.  Perhaps the histogram showing username
lengths at this link is useful:

http://www.eph.co.uk/resources/email-address-length-faq/#emailwildlength

The uptick around 30 bytes is interesting, but there is no indication
of sample size, and we don't how representative their dataset is.

-- 
	Viktor.

From scottr.nist@gmail.com  Wed Jan  8 12:34:40 2014
Return-Path: 
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 A936E1AE18F for ; Wed,  8 Jan 2014 12:34:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 7Y4oLPUTYnTE for ; Wed,  8 Jan 2014 12:34:38 -0800 (PST)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 884751AE156 for ; Wed,  8 Jan 2014 12:34:38 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.174.1; Wed, 8 Jan 2014 15:34:01 -0500
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Wed, 8 Jan 2014 15:34:27 -0500
Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s08KYJFl029493	for ; Wed, 8 Jan 2014 15:34:19 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Scott Rose 
In-Reply-To: <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org>
Date: Wed, 8 Jan 2014 15:34:19 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: 
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com>  <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org>
To: "dane@ietf.org list" 
X-Mailer: Apple Mail (2.1827)
X-NIST-MailScanner-Information: 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-BeenThere: dane@ietf.org
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, 08 Jan 2014 20:34:40 -0000

On Jan 8, 2014, at 10:54 AM, Paul Hoffman  wrote:

> Thanks for the review, Scott. I didn't see it until I has pulled the =
lever on -04 to deal with a few of Mark's comments.
>=20
I'd rather hear negative reviews of bad ideas than no reviews of good =
ones.=20


> On Jan 8, 2014, at 6:58 AM, Scott Rose  wrote:
>=20
>> 1. naming convention to help distinguish between signing and =
encryption key certs (for enterprises that use separate certs for =
encrypting and signing).  It helps reduce the size of the SMIMEA RRset a =
bit, but admittedly minor compared to the size of an X.509 cert.
>=20
> The slight saving of space also introduces a new, significant failure =
mode, namely that if the person listing the cert in the DNS gets the =
type wrong then the receiver can't use it. I'd say "no" on this one.

Admittedly it doesn't save much. =20

>=20
>> 2. a new CU value for "revoked" to indicate that this user's =
certificates have been revoked. =20
>=20
> We considered things like this for TLSA, and the WG seemed very =
hesitant to have the DNS be used as a second, unofficial revocation =
mechanism. For instance, what would it mean for the DNS to say that an =
S/MIME cert is revoked, but when the user pulls a fresh CRL, the cert =
isn't there? The best we might do is to have a signal for "go refresh =
your revocation view" in the DNS, but that seems like very marginal =
value.
>=20

Our thinking was with local trust anchors where places may not keep =
their CRL's up to date or even make it available.  I hope it's not =
optimistic in thinking that new DANE uses will encourage people to keep =
CRL's current.


>> There are some signed/encrypted email projects rolling out now that =
are using CERT RR's or combinations of SRV RR's and LDAP servers.  =
Having something like SMIME would be an improvement, but the spec needs =
to be finalized. =20
>=20
> And Jakob and I apologize for the long lag since the earlier draft. We =
too would like to see this finished.
>=20

Count me as a reviewer.

Scott

> --Paul Hoffman


From paul@cypherpunks.ca  Wed Jan  8 13:02:09 2014
Return-Path: 
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 114741AE5D3 for ; Wed,  8 Jan 2014 13:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 CwGKKNXILRIW for ; Wed,  8 Jan 2014 13:02:08 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id D82CC1AE5C8 for ; Wed,  8 Jan 2014 13:02:07 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D115A80055; Wed,  8 Jan 2014 16:01:56 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s08L1u3E028796; Wed, 8 Jan 2014 16:01:56 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Wed, 8 Jan 2014 16:01:56 -0500 (EST)
From: Paul Wouters 
X-X-Sender: paul@bofh.nohats.ca
To: Paul Hoffman 
In-Reply-To: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
Message-ID: 
References: <20140108152321.10496.88212.idtracker@ietfa.amsl.com> <20140108160156.GE2317@mournblade.imrryr.org> <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Cc: "dane@ietf.org list" 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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, 08 Jan 2014 21:02:09 -0000

On Wed, 8 Jan 2014, Paul Hoffman wrote:

> In the real world, there are few users who have LHS user names that are more than 30 (or maybe even 20) characters long. What you are proposing is "base32 but not really base32" and that could introduce errors in libraries looking up the names.

It's not _that_ hard:

paul@thinkpad:~$ python
Python 2.7.5 (default, Nov 12 2013, 16:45:54) 
[GCC 4.8.2 20131017 (Red Hat 4.8.2-1)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> x = bas64.b32encode("PaulReallyIHaveNoMiddleNameAndThatOtherGuyIsNotMeAndIdontBowlEitherNorRunaNudeBeachInRotterdamWouters")
>>> [ x[i:i+60] for i in range(0, chunks, 60) ]
>>> ".".join([ x[i:i+60] for i in range(0, chunks, 60) ]).lower()
'kbqxk3csmvqwy3dzjfegc5tfjzxu22lemrwgkttbnvsuc3tekrugc5cporug.k4shov4us42on52e2zkbnzseszdpnz2ee33xnrcws5dimvze433skj2w4yko.ovsgkqtfmfrwqslokjxxi5dfojsgc3kxn52xizlsom======'

Similarly, it's easy to add a .strip("=")

>> Also, with say "6" octets of input, e.g. "viktor", we have 48 bits
>>
>> 	OZUWW5DPOI======
>>
>> This seems rather wasteful.
>
> Relative to, say, the size of a PKIX certificate? :-)

In some sense, I'm more interested in skipping the '=' symbols because
some GUI's won't allow "=" in DNS names. Size does not really matter
to me.

>> Allowing for significantly longer local parts (ultimately limited
>> by the total length of a DNS fqdn when combined with the relevant
>> suffix derived from the domain part).
>
> I think this is vast overkill for a rarely-needed use case, but I'm open to hear where people think LHS names longer than 35 characters are used in places where S/MIME or PGP are also used.

That I agree with. I'd rather not do it if it is not a "real thing".

Paul

From stephen.farrell@cs.tcd.ie  Wed Jan  8 17:42:03 2014
Return-Path: 
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 C8C541ADF9C for ; Wed,  8 Jan 2014 17:42:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.438
X-Spam-Level: 
X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538] 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 Dcu1ghsey9kl for ; Wed,  8 Jan 2014 17:42:01 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id A903A1ADF9A for ; Wed,  8 Jan 2014 17:42:01 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0DA0CBE3F; Thu,  9 Jan 2014 01:41:51 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1rAmmo4vlW9D; Thu,  9 Jan 2014 01:41:48 +0000 (GMT)
Received: from [10.87.48.14] (unknown [86.41.58.242]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CA0F9BE38; Thu,  9 Jan 2014 01:41:48 +0000 (GMT)
Message-ID: <52CDFE5C.7020200@cs.tcd.ie>
Date: Thu, 09 Jan 2014 01:41:48 +0000
From: Stephen Farrell 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Warren Kumari , dane@ietf.org
References: <20140106224541.29552.83393.idtracker@ietfa.amsl.com> 
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-03.txt
X-BeenThere: dane@ietf.org
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: Thu, 09 Jan 2014 01:42:04 -0000

Thanks for that. I've requested IETF last call as-is
since I don't have a problem with the current acronyms
nor a startlingly better alternative.

I've a couple of nits, its fine to fix 'em anytime.

section 1:
- s/confused as what/confused as to what/
- s/column with acronym/column with an acronym/

section 2:
- maybe s/upper or lower/upper, mixed or lower/ ?

Cheers,
S.



On 01/06/2014 11:28 PM, Warren Kumari wrote:
> On Mon, Jan 6, 2014 at 5:45 PM,   wrote:
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>  This draft is a work item of the DNS-based Authentication of Named Entities Working Group of the IETF.
> 
> This just adds a note to the abstract explaining that it updates the
> format of the registry in RFC6698 (to keep the nitter happy...)
> W
> 
>>
>>         Title           : Adding acronyms to simplify DANE conversations
>>         Author          : Olafur Gudmundsson
>>         Filename        : draft-ietf-dane-registry-acronyms-03.txt
>>         Pages           : 5
>>         Date            : 2014-01-06
>>
>> Abstract:
>>    Experience has show that people get confused using the three numeric
>>    fields the TLSA record.  This document specifies descriptive acronyms
>>    for the three numeric fields in the TLSA records.  This document
>>    updates the format of the IANA registry created by RFC6698.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/
>>
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-03
>>
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dane-registry-acronyms-03
>>
>>
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>> _______________________________________________
>> dane mailing list
>> dane@ietf.org
>> https://www.ietf.org/mailman/listinfo/dane
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane
> 
> 

From lst_hoe02@kwsoft.de  Thu Jan  9 01:47:25 2014
Return-Path: 
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 651691AE1EB for ; Thu,  9 Jan 2014 01:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.088
X-Spam-Level: 
X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.538] 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 X1ZsKvgxCcIv for ; Thu,  9 Jan 2014 01:47:23 -0800 (PST)
Received: from mailer.kwsoft.de (mailer.kwsoft.de [IPv6:2a03:3500:111:4::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3DD7E1AE1B2 for ; Thu,  9 Jan 2014 01:47:22 -0800 (PST)
Received: from mailer (localhost [127.0.0.1]) by mailer.kwsoft.de (Postfix) with ESMTP id 39DE0180F9F for ; Thu,  9 Jan 2014 10:47:11 +0100 (CET)
Received: from ftp (ftp.kwsoft.de [213.164.67.83]) by mailer.kwsoft.de (Postfix) with ESMTPS id 80CA9180F9F for ; Thu,  9 Jan 2014 10:47:10 +0100 (CET)
Received: from hoedlepc.hq.kwsoft.de (hoedlepc.hq.kwsoft.de [10.1.53.102]) by webmail.kwsoft.de (Horde Framework) with HTTP; Thu, 09 Jan 2014 10:47:10 +0100
Date: Thu, 09 Jan 2014 10:47:10 +0100
From: lst_hoe02@kwsoft.de
To: dane@ietf.org
Message-ID: <20140109104710.Horde.OmwiW4yZLk87Iwqh2D0I2g1@webmail.kwsoft.de>
In-Reply-To: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
References: <20140108152321.10496.88212.idtracker@ietfa.amsl.com> <20140108160156.GE2317@mournblade.imrryr.org> <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-1; boundary="----=_Part_5672_47864842.1389260831148"
User-Agent: Internet Messaging Program (IMP) H5 (6.1.6)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Thu, 09 Jan 2014 09:47:25 -0000

------=_Part_5672_47864842.1389260831148
Content-Type: text/plain; charset=UTF-8; format=flowed; DelSp=Yes
Content-Disposition: inline


Zitat von Paul Hoffman :

> On Jan 8, 2014, at 8:01 AM, Viktor Dukhovni  wrote:
>
>> On Wed, Jan 08, 2014 at 07:23:21AM -0800, internet-drafts@ietf.org wrote:
>>
>>> 	Filename        : draft-ietf-dane-smime-04.txt
>>
>> Given the use of base32 encoding, and explicit non-support for
>> names that encode to more than 63 bytes of base32 text, I would
>> like to suggest that trailing "=*" padding be explicitly dropped
>> from the base32 label allowing for somewhat longer inputs and less
>> redundant outputs.
>>
>> With base32, every 5 octets of input text encode to 8 octets of
>> encoded text, therefore 35 octets encode to 56 octets, but anything
>> longer encodes to 64 octets which is too long.  Thus inputs with
>> 36-39 octets cannot be represented when the "=" padding is part
>> of the encoded text.
>
> In the real world, there are few users who have LHS user names that  
> are more than 30 (or maybe even 20) characters long. What you are  
> proposing is "base32 but not really base32" and that could introduce  
> errors in libraries looking up the names.

Not followed closely on the topic but LHS part of e-mail addresses  
with more than 20 characters are common here in Germany because of the  
schema which uses .@domain. With the double lastname  
this will even get .- in some cases. With names  
from other contries this could be even worse like the following  
(slightly modified) example show:

Dr.Massouf.Najani.Maryam.Nemari

Furthermore "descriptive" e-mail addresses are often used, for example  
"wirtschaftsrat-deutschland", "Redaktionsservice-Buch" and the like.

An short estimate on our input relay would be around 5% > 20  
characters and <1% with more than 30 characters. But IMHO one should  
try to avoid to limit the useable scope from the begining as far as  
possible, no?

Regards

Andreas



------=_Part_5672_47864842.1389260831148
Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIAwggZCMIIF
KqADAgECAgMHyd4wDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFy
dENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgw
NgYDVQQDEy9TdGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQTAe
Fw0xMzEwMDkwMTA5MzFaFw0xNDEwMDkxOTM3NDRaMF0xGTAXBgNVBA0TEDZTN0UzbXFldW00MjY4
a1ExHDAaBgNVBAMME2xzdF9ob2UwMkBrd3NvZnQuZGUxIjAgBgkqhkiG9w0BCQEWE2xzdF9ob2Uw
MkBrd3NvZnQuZGUwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDCfjF7OsDDKD/1b2Ph
Bvn4oefq5/n4ncI1qwDexFtQDcKgJdtHyR8KSqSWvAhBD5D3RbbQxsWxT9Wbv8rg5IzRH+CWQu4F
ZWKVp2E2fQGzzdxW7bJg9DzaJ31z/gPd0Zk0uMaqTiu5Pd3PpASFoKeERuuuH8ZHw8VqmK9eS6R2
kAxG9mgazA/0XZwh+1MUlLSKkvnsQNjuYp9+xqLf7CdfxzkaFEaRyE8iU1fC5U/sBqPYOMo33AsS
ZiyAAwznAaoeqweBqo5E4T5GVmARhwRmUNdo6lOHM6eL5L0+SrUzqDY2vJrplbGUyzhmJw0nXgpL
ytNCzm/cCZ3qT++9yAI7AgMBAAGjggLZMIIC1TAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNV
HSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwHQYDVR0OBBYEFD1q0F8h5f/BTEBzIxCLfj9gpS5F
MB8GA1UdIwQYMBaAFFNy7ZKc4NrLAVx8fpY1TvLUuFGCMB4GA1UdEQQXMBWBE2xzdF9ob2UwMkBr
d3NvZnQuZGUwggFMBgNVHSAEggFDMIIBPzCCATsGCysGAQQBgbU3AQIDMIIBKjAuBggrBgEFBQcC
ARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjCB9wYIKwYBBQUHAgIwgeowJxYg
U3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwAwIBARqBvlRoaXMgY2VydGlmaWNhdGUg
d2FzIGlzc3VlZCBhY2NvcmRpbmcgdG8gdGhlIENsYXNzIDEgVmFsaWRhdGlvbiByZXF1aXJlbWVu
dHMgb2YgdGhlIFN0YXJ0Q29tIENBIHBvbGljeSwgcmVsaWFuY2Ugb25seSBmb3IgdGhlIGludGVu
ZGVkIHB1cnBvc2UgaW4gY29tcGxpYW5jZSBvZiB0aGUgcmVseWluZyBwYXJ0eSBvYmxpZ2F0aW9u
cy4wNgYDVR0fBC8wLTAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNzbC5jb20vY3J0dTEtY3JsLmNy
bDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0cDovL29jc3Auc3RhcnRzc2wuY29t
L3N1Yi9jbGFzczEvY2xpZW50L2NhMEIGCCsGAQUFBzAChjZodHRwOi8vYWlhLnN0YXJ0c3NsLmNv
bS9jZXJ0cy9zdWIuY2xhc3MxLmNsaWVudC5jYS5jcnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z
dGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUAA4IBAQB5+n7pdX+GaEBfLHQ0KTn/5H+O5sHMMVHG
ExAnzXkHDwQ+ZX6olNIfvLWrepxTWHiJ2FN7Ixhw37mruukJYvdRVr9hnUe9q6s8kGYgpqalQHqm
a5+vm74YWXCuFFkeRBI7aUgufhufcJUgl2WUW6POB+eVVcXJbDonBmXnVRh7+Yzeglem10iL2PiH
qp1mNtv0/TmrxSleRXYUMmMiYGhSxMtFor/vKHkCZqKhB0grl941bxFfbOKChKApYwW3GND0kc97
+AV2SBEhqw7k+kd2bo9za92eT4GKLBRPZJkWPJ49AMUi1XEwRTTOAUsXZP4bTU8ZcKKkW58AtBko
hyJkMIIGNDCCBBygAwIBAgIBHjANBgkqhkiG9w0BAQUFADB9MQswCQYDVQQGEwJJTDEWMBQGA1UE
ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2ln
bmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDcxMDI0
MjEwMTU1WhcNMTcxMDI0MjEwMTU1WjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t
IEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNV
BAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMIIBIjAN
BgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxwmDzM4t2BqxKaQuE6uWvooyg4ymiEGWVUet1G8S
D+rqvyNH4QrvnEIaFHxOhESip7vMz39ScLpNLbL1QpOlPW/tFIzNHS3qd2XRNYG5Sv9RcGE+T4qb
LtsjjJbi6sL7Ls/f/X9ftTyhxvxWkf8KW37iKrueKsxw2HqolH7GM6FX5UfNAwAu4ZifkpmZzU1s
lBhyWwaQPEPPZRsWoTb7q8hmgv6Nv3Hg9rmA1/VPBIOQ6SKRkHXG0Hhmq1dOFoAFI411+a/9nWm5
rcVjGcIWZ2v/43Yksq60jExipA4l5uv9/+Hm33mbgmCszdj/Dthf13tgAv2O83hLJ0exTqfrlwID
AQABo4IBrTCCAakwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFFNy
7ZKc4NrLAVx8fpY1TvLUuFGCMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMGYGCCsG
AQUFBwEBBFowWDAnBggrBgEFBQcwAYYbaHR0cDovL29jc3Auc3RhcnRzc2wuY29tL2NhMC0GCCsG
AQUFBzAChiFodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcnQwWwYDVR0fBFQwUjAnoCWg
I4YhaHR0cDovL3d3dy5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMCegJaAjhiFodHRwOi8vY3JsLnN0
YXJ0c3NsLmNvbS9zZnNjYS5jcmwwgYAGA1UdIAR5MHcwdQYLKwYBBAGBtTcBAgEwZjAuBggrBgEF
BQcCARYiaHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5LnBkZjA0BggrBgEFBQcCARYoaHR0
cDovL3d3dy5zdGFydHNzbC5jb20vaW50ZXJtZWRpYXRlLnBkZjANBgkqhkiG9w0BAQUFAAOCAgEA
CoMIfXirLAZcuGOMXq4cuSN3TaFx2H2GvD5VSy/6rV55BYHbWNaPeQn3oBSU8KgQZn/Kck1JxbLp
AxVCNtsxeW1R87ifhsYZ0qjdrA9anrW2MAWCtosmAOT4OxK9QPoSjCMxM3HbkZCDJgnlE8jMopH2
1BbyAYr7b5EfGRQJNtgWcvqSXwKHnTutR08+Kkn0KAkXCzeQNLeA5LlYUzFyM7kPAp8pIRMQ+seH
unmyG642S2+y/qHEdMuGIwpfz3eDF1PdctL04qYK/zu+Qg1Bw0RwgigVZs/0c5HP2/e9DBHh7eSw
tzYlk4AUr6yxLlcwSjOfOmKEQ/Q8tzh0IFiNu9IPuTGAPBn4CPxD0+Ru8T2wg8/s43R/PT3kd1OE
qOJUl7q+h+r6fpvU0Fzxd2tC8Ga6fDEPme+1Nbi+03pVjuZQKbGwKJ66gEn06WqaxVZC+J8hh/jR
0k9mST1iAZPNYulcNJ8tKmVtjYsv0L1TSm2+NwON58tO+pIVzu3DWwSEXSf+qkDavQam+QtEOZxL
BXI++aMUEapSn+k3Lxm48ZCYfAWLb/Xj7F5JQMbZvCexglAbYR0kIHqW5DnsYSdMD/IplJMojx0N
BrxJ3fN9dvX2Y6BIXRsF1du4qESm4/3CKuyUV7p9DW3mPlHTGLvYxnyKQy7VFBkoLINszBrOUeIw
ggfJMIIFsaADAgECAgEBMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1T
dGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5n
MSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNjA5MTcxOTQ2
MzZaFw0zNjA5MTcxOTQ2MzZaMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBT
dGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCC
AgoCggIBAMGI2wm8bEZ8eJ+Ve7UzkPJyYtbBNiAiJF7O6XfyQwqiBmSkzI42+DjmI/BubbE83XKj
hRyh0z20MyvTL6/+6rBBWWe2xAZ9Cp50hdZ5TIA3et85BVJZ9/QbRkOk0oWF0sNx83ViNLosin8e
j+7tNNARx5bNUj26M9bdTd4LO0pLn8ImL/q1FhxyNXfKPF3myuEmixo2dlwB23QUJf7ttaCID914
yi0fB5cwAS1yefpG1hMqqLmmq4NJHeXy793kAY4YCo9jUxaFYqkOGTrMtWamwmt0B+Qr4XY+tG3Y
9kThc2IfO8S+oFNWJWxRCfeqq8q/dv1tm/Od2789ZrwMVqqvmEiVOkvfp1hQ2Th1qVvqQwwC/5nr
6GxNcFspZZzdql3MrwEx7Azr0o3o6px75m73J2YMGkjXbkLjP94hPnvhDXD7Y6qobBpUtFwlesmi
yYsWprssfhdeBU1YbhIdAe4SEA3GMn8Y//z0+s1ukeg2Sb4aSGmLwpZNGhKyaRfBCpDW+nkiSL+6
e2n4cMf6ejfY2A3Sdk9X/5C345HS3e/CYLdnOt3+qpzw1It/ciLOxp+XtviviqAQqNn7GMa2tVxS
PIm2GSpzAQoPA7MSYPJ6L4Hbo27/JjCX9YvdiVe2rT2zryvFt3YC8KXWK5qGFCpy9uMzjF0JSxPf
u4x0E1JLAgMBAAGjggJSMIICTjAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBrjAdBgNVHQ4EFgQU
TgvvGqRAW6UXaYcwyjRoQ9BBrvIwZAYDVR0fBF0wWzAsoCqgKIYmaHR0cDovL2NlcnQuc3RhcnRj
b20ub3JnL3Nmc2NhLWNybC5jcmwwK6ApoCeGJWh0dHA6Ly9jcmwuc3RhcnRjb20ub3JnL3Nmc2Nh
LWNybC5jcmwwggFdBgNVHSAEggFUMIIBUDCCAUwGCysGAQQBgbU3AQEBMIIBOzAvBggrBgEFBQcC
ARYjaHR0cDovL2NlcnQuc3RhcnRjb20ub3JnL3BvbGljeS5wZGYwNQYIKwYBBQUHAgEWKWh0dHA6
Ly9jZXJ0LnN0YXJ0Y29tLm9yZy9pbnRlcm1lZGlhdGUucGRmMIHQBggrBgEFBQcCAjCBwzAnFiBT
dGFydCBDb21tZXJjaWFsIChTdGFydENvbSkgTHRkLjADAgEBGoGXTGltaXRlZCBMaWFiaWxpdHks
IHJlYWQgdGhlIHNlY3Rpb24gKkxlZ2FsIExpbWl0YXRpb25zKiBvZiB0aGUgU3RhcnRDb20gQ2Vy
dGlmaWNhdGlvbiBBdXRob3JpdHkgUG9saWN5IGF2YWlsYWJsZSBhdCBodHRwOi8vY2VydC5zdGFy
dGNvbS5vcmcvcG9saWN5LnBkZjARBglghkgBhvhCAQEEBAMCAAcwOAYJYIZIAYb4QgENBCsWKVN0
YXJ0Q29tIEZyZWUgU1NMIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MA0GCSqGSIb3DQEBBQUAA4IC
AQAWbJn0Zgw09dCFXn0K7NoQTjgcXt+mJQVLkTLB6DvxPd1ECVsHSYopy2YCt7Ga9yWYCTyOG+Hd
NocrS7to0zlmPaAmx/I5kR1Rq4J7ftXOWuTiA1dwaZcI+V5YpgrfjAaaRRYWOApeV/Zix3oCBea8
HrXynvSpKYP4shTjbiiHRMOQGt44qTysQ01kRc7dKKlc8nN7BPgX6Kux8y5cZG5zMToSuLyzEeR9
j4FRmjuNifRNk2Z7PAPt05odmvNlUPWg0HWfL6/w6oJDmPhpnIl5xEOORnLjZDYSr/clHjiJkHd+
w2tqucPLREuseJCL58csHksRRMg0UifNCl2fhcGJ1Rp48pUQUzLdgIRmddm1aCj7YS6+hKg4wJkS
hqUeZ2StBi4vqXCFx5YPfIll9Y5DVA6r3aWAOZRgwDTJlnAsoxL1H0h7vRx+a7edkPQiO674/CrK
+oJSoO+vS1WT68G18CKLrDROJiIEoYcsdUq35X0T17gMZMA20skvhhKMIwnBG4I7c0mjaleHlOXW
eMWZQ2PjTeB3LeFlmXJpBBpHCeYPAVYk+x+/DnmpWC65xAkBfpW6bQAGPrLqShA52NAr9b/sdb+X
AsUJGwjcVTfigfs3hENiIMrnVktl6v5swSSTJKE06wX/miKum30/8WVRCqYwarP0iByADfxyiuiD
XgAAMYICvTCCArkCAQEwgZQwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu
MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMTgwNgYDVQQDEy9T
dGFydENvbSBDbGFzcyAxIFByaW1hcnkgSW50ZXJtZWRpYXRlIENsaWVudCBDQQIDB8neMAkGBSsO
AwIaBQCggf4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwMTA5
MDk0NzExWjAjBgkqhkiG9w0BCQQxFgQUJuskeiwRnU6qZkOJ+kWqmaovKhYwgZ4GCSqGSIb3DQEJ
DzGBkDCBjTALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D
BzAOBggqhkiG9w0DAgICAIAwDwYJKoZIhvZ9B0IKAgIAgDANBgsqgwiMmks9AQEBBDANBgsqgwiM
mks9AQEBAzANBgsqgwiMmks9AQEBAjAKBggqgxqMmkQBBDANBgkqhkiG9w0BAQEFAASCAQBYWfGS
wRXVjeUz4kninNx2chVHzsVJUN9HCnzneHEDtWaqe808smujMyFQmyg2o76n72Y5ctjVExy0DoOb
nJvk/KTxGhldChe9bq52vZZQ/wcf7lKdsRKJuaO+CUBOmBEKoKFuICT5p3bDAYy1BoirF6Q5OfFw
iBocZnbE7LF29mQ9SQCOJkEqIXroOkhfyc65T3H89bbywYxZ9sgmuv5e/xntt1wHxuO9FS4Fq9sk
Q4CKOLTQgSHhqF090dBeXIRZaTGsS+idREIGW9TCSTw3/mZIG4y+jDy1rsYE3eVku7KB/x1MBaNj
VZMhOdAHvnALyBNj6ZeK/duO5m1sYRUZAAAAAAAA
------=_Part_5672_47864842.1389260831148--

From iesg-secretary@ietf.org  Thu Jan  9 06:31:29 2014
Return-Path: 
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 DBB0C1AE361; Thu,  9 Jan 2014 06:31:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 EPOk3y5Ji2kn; Thu,  9 Jan 2014 06:31:28 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A1D1AE30F; Thu,  9 Jan 2014 06:31:28 -0800 (PST)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG 
To: IETF-Announce 
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Sender: 
Message-ID: <20140109143128.21922.56834.idtracker@ietfa.amsl.com>
Date: Thu, 09 Jan 2014 06:31:28 -0800
Cc: dane@ietf.org
Subject: [dane] Last Call:  (Adding acronyms to simplify DANE conversations) to Proposed Standard
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Reply-To: ietf@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 14:31:30 -0000

The IESG has received a request from the DNS-based Authentication of
Named Entities WG (dane) to consider the following document:
- 'Adding acronyms to simplify DANE conversations'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2014-01-23. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


   Experience has show that people get confused using the three numeric
   fields the TLSA record.  This document specifies descriptive acronyms
   for the three numeric fields in the TLSA records.  This document
   updates the format of the IANA registry created by RFC6698.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/ballot/


No IPR declarations have been submitted directly on this I-D.



From bdickson@verisign.com  Thu Jan  9 09:08:42 2014
Return-Path: 
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 DAC981ADF96 for ; Thu,  9 Jan 2014 09:08:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 I2r8x2SDMwYr for ; Thu,  9 Jan 2014 09:08:40 -0800 (PST)
Received: from exprod6og121.obsmtp.com (exprod6og121.obsmtp.com [64.18.1.237]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2B1ADFB7 for ; Thu,  9 Jan 2014 09:08:39 -0800 (PST)
Received: from peregrine.verisign.com ([216.168.239.74]) (using TLSv1) by exprod6ob121.postini.com ([64.18.5.12]) with SMTP ID DSNKUs7Xjgx0tkyNbi45XLDcyuxG7O6e5qjW@postini.com; Thu, 09 Jan 2014 09:08:31 PST
Received: from brn1wnexcas01.vcorp.ad.vrsn.com (brn1wnexcas01.vcorp.ad.vrsn.com [10.173.152.205]) by peregrine.verisign.com (8.13.6/8.13.4) with ESMTP id s09H8Ttn019829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 9 Jan 2014 12:08:29 -0500
Received: from BRN1WNEXMBX01.vcorp.ad.vrsn.com ([::1]) by brn1wnexcas01.vcorp.ad.vrsn.com ([::1]) with mapi id 14.02.0342.003; Thu, 9 Jan 2014 12:08:29 -0500
From: "Dickson, Brian" 
To: Paul Hoffman , "dane@ietf.org list" 
Thread-Topic: [dane] I-D Action: draft-ietf-dane-smime-04.txt
Thread-Index: AQHPDIWROXmKcpQJ/ky85WTI7CjLRZp7UK8AgAAM6YCAAUQuAA==
Date: Thu, 9 Jan 2014 17:08:28 +0000
Message-ID: 
In-Reply-To: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/14.3.5.130515
x-originating-ip: [10.173.152.4]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <0E619CE2443F9943A863FA9F9F550C1F@verisign.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Thu, 09 Jan 2014 17:08:43 -0000

On 1/8/14 11:48 AM, "Paul Hoffman"  wrote:

>On Jan 8, 2014, at 8:01 AM, Viktor Dukhovni 
>wrote:
>
>> On Wed, Jan 08, 2014 at 07:23:21AM -0800, internet-drafts@ietf.org
>>wrote:
>>=20
>>> 	Filename        : draft-ietf-dane-smime-04.txt
>>=20
>> Given the use of base32 encoding, and explicit non-support for
>> names that encode to more than 63 bytes of base32 text


[snip, include all useful context ;-)]

>Yes it does. It also puts a burden on the application to use our new
>"base32ish" encoding instead of the base32 encoding they already have. In
>order to save five bytes.
>
>> Finally is the word "prohibited" appropriate in the new text:
>>=20
>>       Also note that user names can be any length, and labels are
>>       limited to 63 octets.  Also note that user names that are
>>       encoded with Base32 are longer than the original user name.
>>       Any user name that would cause a label of longer than 63
>>       octets is expressly prohibited by this specification.
>>=20
>> I would think "unsupported" or "incompatible" would be closer,
>> since such local parts remain valid, even though there are incompatible
>> with SMIMEA.
>
>You are right: we'll change to "incompatible" in the next draft.

Let's see if I understand the purpose of the original proposal (base32
encoding of local-part/"local part"), the limitations, and the
counter-proposals.

These are for deterministically putting something into DNS, and for
deterministically finding the thing that was put into DNS.
The RHS is the interesting thing (e.g. smime stuff), and the LHS just has
to be deterministic, right?

The input can be either non-international (arbitrary length ASCII
characters, bytes with first bit 0) or international (arbitrary length
strings of UTF8). Even adding a distinguisher between the two input sets,
at best would only optimize fixed-upper-limit functions (7 onto 5 or 8
onto 5 encoding schemes with 63 character max).

So instead of "encoding" per se, what about using a hash function?

It does not have to automatically be an existing hash function, although
re-use of the NSEC3 code might be reasonable.

All that matters is that the probability of hash collisions is very very
low, and perhaps the addition of some collision-mitigation would help.

LDH =3D 26 alpha + 10 digit + hyphen =3D 37 characters
37^63 is a big big number (about 100 decimal digits starting with "6").

It means on average the lhs is longer, but in practical terms removes the
upper limit on the encoding (since the hash function has no upper limit on
input).

We're talking about stuff that hasn't yet been developed, right, so a
major shift in LHS stuff is no biggie?

Brian


From viktor1dane@dukhovni.org  Thu Jan  9 09:39:57 2014
Return-Path: 
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 171731AE502 for ; Thu,  9 Jan 2014 09:39:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 uv0uLvczxYi3 for ; Thu,  9 Jan 2014 09:39:55 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 167BC1AE503 for ; Thu,  9 Jan 2014 09:39:53 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C2B302AB218; Thu,  9 Jan 2014 17:39:43 +0000 (UTC)
Date: Thu, 9 Jan 2014 17:39:43 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140109173943.GL2317@mournblade.imrryr.org>
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 17:39:57 -0000

On Thu, Jan 09, 2014 at 05:08:28PM +0000, Dickson, Brian wrote:

> So instead of "encoding" per se, what about using a hash function?

An intriguing suggestion.  If the hash is HMAC-SHA1(domain, username),
its hex representation is 40 octets which fits comfortably into a
DNS label.  Dictionary harvesting attacks by following NSEC records
are a bit harder, since HMAC with the domain as a key makes the
use of rainbow tables less useful.

-- 
	Viktor.

From cloos@jhcloos.com  Thu Jan  9 11:51:55 2014
Return-Path: 
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 8587D1AE3D5 for ; Thu,  9 Jan 2014 11:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, 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 ukmQR4EFIclb for ; Thu,  9 Jan 2014 11:51:52 -0800 (PST)
Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 69FAF1AE114 for ; Thu,  9 Jan 2014 11:51:52 -0800 (PST)
Received: by ore.jhcloos.com (Postfix, from userid 10) id 4FF891DEB5; Thu,  9 Jan 2014 19:51:39 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1389297099; bh=NsQM+qjiYS2Xb78QFeGOMcW5+4hFAFfXLhfYATPOZGs=; h=From:To:Subject:In-Reply-To:References:Date:From; b=H4w/I/csb7GXTQb53xrxUrPJVOHMf+eRmdqD2Bz5oqgKplWwI+eh/1p0g2/8xq1x/ dtXWHh2QFDtqRC5Cp9j9kLjKl/200wyyDC9wiClOTLqTjQ9EMJyZp9h8oLg/VlAXHx uQ8D67hd9cb28uM1ykfgcq0z1CzSgCr+rQZeYz2tISQ==
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 96FE360027; Thu,  9 Jan 2014 19:45:50 +0000 (UTC)
From: James Cloos 
To: dane@ietf.org
In-Reply-To: <20140109173943.GL2317@mournblade.imrryr.org> (Viktor Dukhovni's message of "Thu, 9 Jan 2014 17:39:43 +0000")
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2013 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: Thu, 09 Jan 2014 14:45:50 -0500
Message-ID: 
Lines: 35
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:140109:dane@ietf.org::ZhMC6X+SKOoWK7LS:000cjKhA
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Thu, 09 Jan 2014 19:51:55 -0000

>>>>> "BD" == Brian Dickson  writes:
>>>>> "VD" == Viktor Dukhovni  writes:

BD>> So instead of "encoding" per se, what about using a hash function?
BD>> ... re-use of the NSEC3 code might be reasonable

VD> An intriguing suggestion.

Very!

VD> If the hash is HMAC-SHA1(domain, username), its hex representation
VD> is 40 octets which fits comfortably into a DNS label.

As hex; and 40 hex vs 32 base32 isn't enough of a difference to warrant
adding extra code for base32.  A win overall.

Should anyone insist of hmac-sha256, though, base32 would be necessary.
But I've yet to see any credible claims that sha1's vulnerabilities
affect hmac-sha1, so there shouldn't be a reason for sha2 or sha3.

VD> HMAC with the domain as a key makes rainbow tables less useful.

If hmac nonetheless isn't used, then the nsec3 hash SHOULD be.

The issue of normalization (before hashing) remains, as foo will
generate a different hash than LHS or Lhs (or lHs), not to mention
the differences between NFC vs NFD (eg,  vs ).

I like the idea of a published policy (perhaps using the token _policy)
to specify the details for that zone.  With lc(nfc(lhs)) as the default
policy, if none is specified.

-JimC
--
James Cloos          OpenPGP: 1024D/ED7DAEA6

From viktor1dane@dukhovni.org  Thu Jan  9 12:56:18 2014
Return-Path: 
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 700801ADFA6 for ; Thu,  9 Jan 2014 12:56:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 vDDF98mbz--g for ; Thu,  9 Jan 2014 12:56:16 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 1E9F41AE177 for ; Thu,  9 Jan 2014 12:56:14 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5DB172AB173; Thu,  9 Jan 2014 20:56:04 +0000 (UTC)
Date: Thu, 9 Jan 2014 20:56:04 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140109205604.GM2317@mournblade.imrryr.org>
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 09 Jan 2014 20:56:18 -0000

On Thu, Jan 09, 2014 at 02:45:50PM -0500, James Cloos wrote:
> >>>>> "BD" == Brian Dickson  writes:
> >>>>> "VD" == Viktor Dukhovni  writes:
> 
> BD>> So instead of "encoding" per se, what about using a hash function?
> BD>> ... re-use of the NSEC3 code might be reasonable
> 
> VD> An intriguing suggestion.
> 
> Very!
> 
> VD> If the hash is HMAC-SHA1(domain, username), its hex representation
> VD> is 40 octets which fits comfortably into a DNS label.
> 
> As hex; and 40 hex vs 32 base32 isn't enough of a difference to warrant
> adding extra code for base32.  A win overall.
> 
> Should anyone insist of hmac-sha256, though, base32 would be necessary.
> But I've yet to see any credible claims that sha1's vulnerabilities
> affect hmac-sha1, so there shouldn't be a reason for sha2 or sha3.

Indeed, but if one really wants to avoid HMAC-SHA1 because it is
now unfashionable, one can use SHA2-224 to get a 56-byte label.

Choices of canonicalization rules for the HMAC input are identical
to those for the base32 input.  Neither is particularly more amenable
to case-insensitive or other imprecise matching on the encoded output.

So it seems that there is little advantage to base32, and clear
disadvantages.  The only upside I can see for base32 is that with
HMAC the DNS administrator who forgets which user a given key is
for, can't easily recover that information, but he can with base32.
Keeping the user names "secret" is arguably a security feature when
DNS is outsourced.

A sensible administrator will keep the unhashed input names in a
configuration system that generates the corresponding DNS entries.

-- 
	Viktor.

From viktor1dane@dukhovni.org  Thu Jan  9 16:17:45 2014
Return-Path: 
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 3838C1AD7BE for ; Thu,  9 Jan 2014 16:17:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ajKBtdp2MBNs for ; Thu,  9 Jan 2014 16:17:39 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 170CE1AD957 for ; Thu,  9 Jan 2014 16:17:37 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id EEE612AB173; Fri, 10 Jan 2014 00:17:26 +0000 (UTC)
Date: Fri, 10 Jan 2014 00:17:26 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140110001726.GO2317@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: [dane] Postfix 2.11.0-RC2 available with feature-complete DANE support
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jan 2014 00:17:45 -0000

Postfix 2.11.0 is now in code-freeze.  With 2.11.0-RC2 the DANE
support is feature complete, and matches the DANE SMTP draft.

The official 2.11.0 release will happen in the next couple of weeks.
Test feedback welcome.

    http://www.postfix.org/TLS_README.html#client_tls_dane
    http://www.postfix.org/TLS_README.html#client_tls_policy

While I am busy with IETF drafts, some brave souls have volunteered
to contribute a more consolidated DANE_README tutorial.  I'll post
a link here when/if all goes well on that front.  Currently the
DANE related information is scattered over a few documents.

Minimal client configuration:

    Note: A DNSSEC validating resolver MUST be present on the
    LOOPBACK interface and MUST be the only resolver listed in
    /etc/resolv.conf.  Postfix delegates DNSSEC processing to the
    system's caching resolver.  A local resolver is in any case a
    good idea for an MTA that handles non-trivial mail volumes.

    /etc/resolv.conf:
	nameserver 127.0.0.1

    main.cf:
	smtp_host_lookup = dns
	smtp_dns_support_level = dnssec
	smtp_tls_security_level = dane
	ignore_mx_lookup_error = no

Recommended Server DNS configuration:

	example.com. IN MX 0 mx.example.com.

    Publish one of the two TLSA record forms below, the remaining
    22 combinations have little to recommend them:

	; Per-service EE SPKI TLSA RR:
	;
	_25._tcp.mx.example.com. IN TLSA 3 1 1 {EE SPKI SHA2-256 digest}

	or

	; Domain-wide TA CERT TLSA RR, aliased from each service:
	;
	_25._tcp.mx.example.com. IN CNAME 2.1.1._tlsa.example.com.
	2.1.1._tlsa.example.com. IN TLSA 2 0 1 {TA CERT SHA2-256 digest}

    In the second case the domain-issued TA certificate MUST be
    included in the server chain file:

	# cd /etc/postfix
	# cat ee-cert.pem intermediate.pem ... root-ta.pem > chain.pem
	# postconf -e 'smtpd_tls_security_level = may'
	# postconf -e 'smtpd_tls_cert_file = ${config_directory}/chain.pem'
	# postconf -e 'smtpd_tls_key_file = ${config_directory}/ee-key.pem'

    and the ee-cert MUST have at least one of "mx.example.com" or
    "example.com" as a DNS subjectAltName or subject commonName.

    Avoid wildcard certs, they may allow MITM attackers to redirect
    connections to the wrong hosts.

See http://www.postfix.org/FORWARD_SECRECY_README.html for additional
server TLS tuning.

-- 
	Viktor.

From viktor1dane@dukhovni.org  Thu Jan  9 16:25:45 2014
Return-Path: 
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 8E9A01ADA74 for ; Thu,  9 Jan 2014 16:25:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 i6_FhE3lq0hN for ; Thu,  9 Jan 2014 16:25:44 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 0D83F1ADAEA for ; Thu,  9 Jan 2014 16:25:43 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id F0E772AB173; Fri, 10 Jan 2014 00:25:33 +0000 (UTC)
Date: Fri, 10 Jan 2014 00:25:33 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140110002533.GP2317@mournblade.imrryr.org>
References: <20140110001726.GO2317@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140110001726.GO2317@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Postfix 2.11.0-RC2 available with feature-complete DANE support
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jan 2014 00:25:45 -0000

On Fri, Jan 10, 2014 at 12:17:26AM +0000, Viktor Dukhovni wrote:

More proof-reading might be a good idea:

> 	; Domain-wide TA CERT TLSA RR, aliased from each service:
> 	;
> 	_25._tcp.mx.example.com. IN CNAME 2.1.1._tlsa.example.com.
> 	2.1.1._tlsa.example.com. IN TLSA 2 0 1 {TA CERT SHA2-256 digest}

The "2.1.1" should have been a  "2.0.1":

 	; Domain-wide TA CERT TLSA RR, aliased from each service:
 	;
 	_25._tcp.mx.example.com. IN CNAME 2.0.1._tlsa.example.com.
 	2.0.1._tlsa.example.com. IN TLSA 2 0 1 {TA CERT SHA2-256 digest}

The reason for "2 0 1" is that with "2 0 1" records Postfix honours
various properties in the TA certificate.  For example, path length
constraints, ...  With "2 1 1", the public key is trusted directly,
and the rest of the TA certificate is ignored.

So I had the right TLSA parameters, but a misleading associated
domain name.

-- 
	Viktor.

From paul@cypherpunks.ca  Thu Jan  9 16:27:05 2014
Return-Path: 
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 E12E31ADA74 for ; Thu,  9 Jan 2014 16:27:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ct_rf_WGiEBS for ; Thu,  9 Jan 2014 16:27:03 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 421DB1AD8EB for ; Thu,  9 Jan 2014 16:27:03 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 66F5280055 for ; Thu,  9 Jan 2014 19:26:52 -0500 (EST)
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s0A0Qqd6007164 for ; Thu, 9 Jan 2014 19:26:52 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Thu, 9 Jan 2014 19:26:51 -0500 (EST)
From: Paul Wouters 
X-X-Sender: paul@bofh.nohats.ca
To: dane WG list 
In-Reply-To: <20140109205604.GM2317@mournblade.imrryr.org>
Message-ID: 
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Fri, 10 Jan 2014 00:27:06 -0000

On Thu, 9 Jan 2014, Viktor Dukhovni wrote:

>> Should anyone insist of hmac-sha256, though, base32 would be necessary.
>> But I've yet to see any credible claims that sha1's vulnerabilities
>> affect hmac-sha1, so there shouldn't be a reason for sha2 or sha3.
>
> Indeed, but if one really wants to avoid HMAC-SHA1 because it is
> now unfashionable, one can use SHA2-224 to get a 56-byte label.

SHA2-224 would have my preference, as SHA1 is on its way out FIPS-wise
and it is just easing not having to maintain SHA1 exceptions to the
"disallow sha1" code paths.

> A sensible administrator will keep the unhashed input names in a
> configuration system that generates the corresponding DNS entries.

Yes, base32 is as unradable as a hash for the admin eye.

I think I'm fine with using sha2-224, if it saves us the hassle of doing
label splitting. But still a little worried about hashing various
character sets.

Paul

From marka@isc.org  Thu Jan  9 16:47:21 2014
Return-Path: 
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 7DBDD1ADBE8 for ; Thu,  9 Jan 2014 16:47:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, 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 jKi4avFHK5qh for ; Thu,  9 Jan 2014 16:47:19 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5231ADA74 for ; Thu,  9 Jan 2014 16:47:19 -0800 (PST)
Received: from mx.pao1.isc.org (localhost [127.0.0.1]) by mx.pao1.isc.org (Postfix) with ESMTP id C48E3C949B; Fri, 10 Jan 2014 00:46:56 +0000 (UTC) (envelope-from marka@isc.org)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=dkim2012; t=1389314829; bh=uxvclOGLVHq7n26GLvhlv6g6piIAv5WN45uKLKBQUOY=; h=To:Cc:From:References:Subject:In-reply-to:Date; b=VMqYeMHa9a9px0cVum9Y1wf4lNa7n4p4oU80k7RWQVdl9QeTJ2w+rD5nZTC/yMYqi AOY7NH21DQSGTD6Bh/0TA2UQS22OXJdAns/qaCSQwlxhJs4w016iegPBOjdptJ7+Un bmdauXo8jD8H8RYOAHLX2FG5O1HSjmbOFIZW+uz8=
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.pao1.isc.org (Postfix) with ESMTP; Fri, 10 Jan 2014 00:46:56 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 6B4FC160475; Fri, 10 Jan 2014 00:57:26 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 3E798160459; Fri, 10 Jan 2014 00:57:26 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 7A9F3CA6B8A; Fri, 10 Jan 2014 11:48:13 +1100 (EST)
To: Paul Wouters 
From: Mark Andrews 
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org> 
In-reply-to: Your message of "Thu, 09 Jan 2014 19:26:51 -0500." 
Date: Fri, 10 Jan 2014 11:48:12 +1100
Message-Id: <20140110004813.7A9F3CA6B8A@rock.dv.isc.org>
X-DCC--Metrics: post.isc.org; whitelist
Cc: dane WG list 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Fri, 10 Jan 2014 00:47:21 -0000

Whatever encoding is choosen can draft-ietf-dane-smime and
draft-wouters-dane-openpgp please use the same encoding method for
the local part.  I would even go so much as to say we should split
this out of both drafts and make it a seperate draft that they can
reference.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From viktor1dane@dukhovni.org  Thu Jan  9 16:50:07 2014
Return-Path: 
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 E88CC1ADBE8 for ; Thu,  9 Jan 2014 16:50:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 fK7dBOIQjEs3 for ; Thu,  9 Jan 2014 16:50:05 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E0D081ADBCE for ; Thu,  9 Jan 2014 16:50:04 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 49DF72AB215; Fri, 10 Jan 2014 00:49:54 +0000 (UTC)
Date: Fri, 10 Jan 2014 00:49:54 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140110004954.GQ2317@mournblade.imrryr.org>
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jan 2014 00:50:08 -0000

On Thu, Jan 09, 2014 at 07:26:51PM -0500, Paul Wouters wrote:

> SHA2-224 would have my preference, as SHA1 is on its way out FIPS-wise
> and it is just easing not having to maintain SHA1 exceptions to the
> "disallow sha1" code paths.

I can live with HMAC SHA2-224.

> I think I'm fine with using sha2-224, if it saves us the hassle of doing
> label splitting. But still a little worried about hashing various
> character sets.

Email addresses are still (multiple failed[*] attempts at SMTP + UTF-8
addresses notwithstanding) US-ASCII strings.  One can canonicalize
these via the identity map to UTF-8 if one wants to pretend otherwise.

-- 
	Viktor.

[*] RFCs that nobody implements do not count as success.

From cloos@jhcloos.com  Thu Jan  9 18:06:10 2014
Return-Path: 
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 1718E1ADF81 for ; Thu,  9 Jan 2014 18:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.539
X-Spam-Level: 
X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538, 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 129SGM3lQw9k for ; Thu,  9 Jan 2014 18:06:08 -0800 (PST)
Received: from ore.jhcloos.com (ore.jhcloos.com [IPv6:2604:2880::b24d:a297]) by ietfa.amsl.com (Postfix) with ESMTP id 6313D1ADF0E for ; Thu,  9 Jan 2014 18:06:07 -0800 (PST)
Received: by ore.jhcloos.com (Postfix, from userid 10) id 2485B1DED7; Fri, 10 Jan 2014 02:05:56 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jhcloos.com; s=ore13; t=1389319556; bh=l0jyJYJJqKo12LkYxCssl1dPC6uwwzruwm4XR8HCqzk=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=E1bJZA7SD1poNjJCT1JrHvi7GXP8wGpWHf7llNRopR+gxQqPZAWzzFGsMwp/64iAN DKBN1cTTjMCdXvEsTuVzjovYtC1zBqWeyZhfEr4mlWiunqOq3nOjI7PLwVl2PkSwJH cAmqE2r/sU63glakCShH58p291WmzVZAXOOaLIrBo9A==
Received: by carbon.jhcloos.org (Postfix, from userid 500) id 7C99360027; Fri, 10 Jan 2014 02:02:36 +0000 (UTC)
From: James Cloos 
To: Viktor Dukhovni 
In-Reply-To: <20140110004954.GQ2317@mournblade.imrryr.org> (Viktor Dukhovni's message of "Fri, 10 Jan 2014 00:49:54 +0000")
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3.50 (gnu/linux)
Face: iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAgMAAABinRfyAAAACVBMVEX///8ZGXBQKKnCrDQ3 AAAAJElEQVQImWNgQAAXzwQg4SKASgAlXIEEiwsSIYBEcLaAtMEAADJnB+kKcKioAAAAAElFTkSu QmCC
Copyright: Copyright 2013 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: Thu, 09 Jan 2014 21:02:36 -0500
Message-ID: 
Lines: 15
MIME-Version: 1.0
Content-Type: text/plain
X-Hashcash: 1:30:140110:viktor1dane@dukhovni.org::wcqOsICqJJ+9nniy:000000000000000000000000000000000000B5d2Z
X-Hashcash: 1:30:140110:dane@ietf.org::IpHVqEmsUlW7VT36:000lAZr4
Cc: dane@ietf.org
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Fri, 10 Jan 2014 02:06:10 -0000

>>>>> "VD" == Viktor Dukhovni  writes:

VD> Email addresses are still (multiple failed[*] attempts at SMTP + UTF-8
VD> addresses notwithstanding) US-ASCII strings.

One of the reasons for base32 in the original smime draft was that some
sites have local email addresses which differ only in case.

upper() vs lower() vs nothing(), as well as whether to strip some suffix
or other are still a valid local policy issue when normalizing the strings
before hashing or base32ing.

-JimC
--
James Cloos          OpenPGP: 1024D/ED7DAEA6

From viktor1dane@dukhovni.org  Thu Jan  9 18:17:59 2014
Return-Path: 
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 5E1871ADF7C for ; Thu,  9 Jan 2014 18:17:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 jzoMS_Jme3KU for ; Thu,  9 Jan 2014 18:17:57 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 86AEE1ADF65 for ; Thu,  9 Jan 2014 18:17:57 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 833092AB215; Fri, 10 Jan 2014 02:17:46 +0000 (UTC)
Date: Fri, 10 Jan 2014 02:17:46 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140110021746.GR2317@mournblade.imrryr.org>
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 10 Jan 2014 02:17:59 -0000

On Thu, Jan 09, 2014 at 09:02:36PM -0500, James Cloos wrote:

> VD> Email addresses are still (multiple failed[*] attempts at SMTP + UTF-8
> VD> addresses notwithstanding) US-ASCII strings.
> 
> One of the reasons for base32 in the original smime draft was that some
> sites have local email addresses which differ only in case.
> 
> upper() vs lower() vs nothing(), as well as whether to strip some suffix
> or other are still a valid local policy issue when normalizing the strings
> before hashing or base32ing.

How does this bear on the encoding lookup key labels? Any encoding
(e.g. base32, or HMAC-SHA-224, but not punycode) that does not map
input strings that differ only in case to output strings that differ
only in case offers no advantage over a 1-way hash function.

I am not sure what you're getting at.  Perhaps I'm missing something.

-- 
	Viktor.

From paul.hoffman@vpnc.org  Thu Jan  9 19:22:29 2014
Return-Path: 
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 509971ADFD9 for ; Thu,  9 Jan 2014 19:22:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 8Ih9w8s3dxVf for ; Thu,  9 Jan 2014 19:22:28 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E87491ADFD6 for ; Thu,  9 Jan 2014 19:22:27 -0800 (PST)
Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0A32JUR060865 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 9 Jan 2014 20:02:21 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman 
In-Reply-To: <20140110021746.GR2317@mournblade.imrryr.org>
Date: Thu, 9 Jan 2014 19:21:53 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org>  <20140110021746.GR2317@mournblade.imrryr.org>
To: "dane@ietf.org list" 
X-Mailer: Apple Mail (2.1827)
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Fri, 10 Jan 2014 03:22:29 -0000

On Jan 9, 2014, at 6:17 PM, Viktor Dukhovni  =
wrote:

> How does this bear on the encoding lookup key labels? Any encoding
> (e.g. base32, or HMAC-SHA-224, but not punycode) that does not map
> input strings that differ only in case to output strings that differ
> only in case offers no advantage over a 1-way hash function.
>=20
> I am not sure what you're getting at.  Perhaps I'm missing something.

The person looking up someone's S/MIME or PGP cert either knows how the =
LHS is spelled (including exact case, and character encoding) or they =
don't. This issue is for a layer that is not ours.

--Paul Hoffman=

From marka@isc.org  Thu Jan  9 19:58:41 2014
Return-Path: 
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 20AE41AE00E for ; Thu,  9 Jan 2014 19:58:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.439
X-Spam-Level: 
X-Spam-Status: No, score=-7.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.538, 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 GLT5i9LCbEEz for ; Thu,  9 Jan 2014 19:58:40 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [199.6.1.65]) by ietfa.amsl.com (Postfix) with ESMTP id D63601ADF9B for ; Thu,  9 Jan 2014 19:58:39 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id E7EEC23839C; Fri, 10 Jan 2014 03:58:16 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 93D8A160459; Fri, 10 Jan 2014 04:08:46 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 63C201602E9; Fri, 10 Jan 2014 04:08:46 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 31003CADEAB; Fri, 10 Jan 2014 14:59:33 +1100 (EST)
To: Paul Hoffman 
From: Mark Andrews 
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org>  <20140110021746.GR2317@mournblade.imrryr.org> 
In-reply-to: Your message of "Thu, 09 Jan 2014 19:21:53 -0800." 
Date: Fri, 10 Jan 2014 14:59:32 +1100
Message-Id: <20140110035933.31003CADEAB@rock.dv.isc.org>
Cc: "dane@ietf.org list" 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Fri, 10 Jan 2014 03:58:41 -0000

In message , Paul Hoffman writes
:
> On Jan 9, 2014, at 6:17 PM, Viktor Dukhovni  wrote:
> 
> > How does this bear on the encoding lookup key labels? Any encoding
> > (e.g. base32, or HMAC-SHA-224, but not punycode) that does not map
> > input strings that differ only in case to output strings that differ
> > only in case offers no advantage over a 1-way hash function.
> > 
> > I am not sure what you're getting at.  Perhaps I'm missing something.
> 
> The person looking up someone's S/MIME or PGP cert either knows how the LHS i
> s spelled (including exact case, and character encoding) or they don't. This 
> issue is for a layer that is not ours.

So a user has my address as "MARKA@ISC.ORG" (this is not made up,
some companies have it saved as that despite the fact that I entered
it in lowercase).  Is the MUA supposed to lowercase "MARKA" or not
before looking for a SMIME key?

>From my perspective there isn't a hard and fast answer to that.

We could publish rules, in the DNS, for the MUA to use so that it
doesn't have to guess.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From paul.hoffman@vpnc.org  Fri Jan 10 08:23:33 2014
Return-Path: 
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 5E78B1AE0D7 for ; Fri, 10 Jan 2014 08:23:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 UHBrOqKVSdFO for ; Fri, 10 Jan 2014 08:23:31 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE471AE0D6 for ; Fri, 10 Jan 2014 08:23:31 -0800 (PST)
Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0AG3Li4095701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 10 Jan 2014 09:03:23 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman 
In-Reply-To: <20140110035933.31003CADEAB@rock.dv.isc.org>
Date: Fri, 10 Jan 2014 08:23:18 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <65157350-8CCE-43D0-B8AC-163A2149F43D@vpnc.org>
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org>  <20140110021746.GR2317@mournblade.imrryr.org>  <20140110035933.31003CADEAB@rock.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1827)
Cc: "dane@ietf.org list" 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Fri, 10 Jan 2014 16:23:33 -0000

On Jan 9, 2014, at 7:59 PM, Mark Andrews  wrote:

>=20
> In message , Paul =
Hoffman writes
> :
>> On Jan 9, 2014, at 6:17 PM, Viktor Dukhovni =
 wrote:
>>=20
>>> How does this bear on the encoding lookup key labels? Any encoding
>>> (e.g. base32, or HMAC-SHA-224, but not punycode) that does not map
>>> input strings that differ only in case to output strings that differ
>>> only in case offers no advantage over a 1-way hash function.
>>>=20
>>> I am not sure what you're getting at.  Perhaps I'm missing =
something.
>>=20
>> The person looking up someone's S/MIME or PGP cert either knows how =
the LHS i
>> s spelled (including exact case, and character encoding) or they =
don't. This=20
>> issue is for a layer that is not ours.
>=20
> So a user has my address as "MARKA@ISC.ORG" (this is not made up,
> some companies have it saved as that despite the fact that I entered
> it in lowercase).  Is the MUA supposed to lowercase "MARKA" or not
> before looking for a SMIME key?

Again: this is an issue is for a layer that is not ours. The question is =
identical to whether or not your SMTP server will or will not accept =
both "marka" and "MARKA".

>> =46rom my perspective there isn't a hard and fast answer to that.
>=20
> We could publish rules, in the DNS, for the MUA to use so that it
> doesn't have to guess.

We could. And the SMTP folks could do the same. Or we could finish this =
work in the next five years.

--Paul Hoffman=

From paul@nohats.ca  Fri Jan 10 11:50:19 2014
Return-Path: 
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 E46FD1AE005 for ; Fri, 10 Jan 2014 11:50:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.538
X-Spam-Level: 
X-Spam-Status: No, score=-2.538 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.538] 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 7pZej2NAgIKv for ; Fri, 10 Jan 2014 11:50:18 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5431AE1C1 for ; Fri, 10 Jan 2014 11:50:17 -0800 (PST)
Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 69BE180055; Fri, 10 Jan 2014 14:50:06 -0500 (EST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1389383406; bh=rYeHo4aI1yb4j1o6jlttwFQwgQ72fw8DXRjVJouYASs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=Imdu3FNQpuAV6e1zwdJrPxYNJtNfjs0EmdtjlYI8fA3/181E2MFu3JuU1EN4WXuH2 0pVARrQruZe+COx0l55klJApcmfK3ksjqN7QFnEbtqAgkTpsJfmq7T/szB/DnzZ3o2 P/rqknqzpS7AMVbgqu7Y8MbOvOctVk51Zqvh0XT8=
Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s0AJo5vA010762; Fri, 10 Jan 2014 14:50:05 -0500
X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs
Date: Fri, 10 Jan 2014 14:50:05 -0500 (EST)
From: Paul Wouters 
To: Mark Andrews , Paul Hoffman 
In-Reply-To: <20140110004813.7A9F3CA6B8A@rock.dv.isc.org>
Message-ID: 
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004813.7A9F3CA6B8A@rock.dv.isc.org>
User-Agent: Alpine 2.10 (LFD 1266 2009-07-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Cc: dane WG list 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Fri, 10 Jan 2014 19:50:20 -0000

On Fri, 10 Jan 2014, Mark Andrews wrote:

> Whatever encoding is choosen can draft-ietf-dane-smime and
> draft-wouters-dane-openpgp please use the same encoding method for
> the local part.

Yes we will, which is why I have  been waiting with posting an updated draft.

Paul

From marka@isc.org  Sun Jan 12 15:58:31 2014
Return-Path: 
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 70A2A1ACC86 for ; Sun, 12 Jan 2014 15:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 Tmz7AZcsI5Dg for ; Sun, 12 Jan 2014 15:58:28 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6001ACC83 for ; Sun, 12 Jan 2014 15:58:28 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 00D782383C9; Sun, 12 Jan 2014 23:58:04 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 10446160459; Mon, 13 Jan 2014 00:08:46 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id D060C16032F; Mon, 13 Jan 2014 00:08:45 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id BBCA6CD007C; Mon, 13 Jan 2014 10:59:27 +1100 (EST)
To: Paul Hoffman 
From: Mark Andrews 
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org>  <20140110021746.GR2317@mournblade.imrryr.org>  <20140110035933.31003CADEAB@rock.dv.isc.org> <65157350-8CCE-43D0-B8AC-163A2149F43D@vpnc.org>
In-reply-to: Your message of "Fri, 10 Jan 2014 08:23:18 -0800." <65157350-8CCE-43D0-B8AC-163A2149F43D@vpnc.org>
Date: Mon, 13 Jan 2014 10:59:27 +1100
Message-Id: <20140112235927.BBCA6CD007C@rock.dv.isc.org>
Cc: "dane@ietf.org list" 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Sun, 12 Jan 2014 23:58:31 -0000

In message <65157350-8CCE-43D0-B8AC-163A2149F43D@vpnc.org>, Paul Hoffman writes
:
> On Jan 9, 2014, at 7:59 PM, Mark Andrews  wrote:
>
> >
> > In message , Paul
> Hoffman writes
> > :
> >> On Jan 9, 2014, at 6:17 PM, Viktor Dukhovni 
> wrote:
> >>
> >>> How does this bear on the encoding lookup key labels? Any encoding
> >>> (e.g. base32, or HMAC-SHA-224, but not punycode) that does not map
> >>> input strings that differ only in case to output strings that differ
> >>> only in case offers no advantage over a 1-way hash function.
> >>>
> >>> I am not sure what you're getting at.  Perhaps I'm missing something.
> >>
> >> The person looking up someone's S/MIME or PGP cert either knows how
> the LHS i
> >> s spelled (including exact case, and character encoding) or they
> don't. This
> >> issue is for a layer that is not ours.
> >
> > So a user has my address as "MARKA@ISC.ORG" (this is not made up,
> > some companies have it saved as that despite the fact that I entered
> > it in lowercase).  Is the MUA supposed to lowercase "MARKA" or not
> > before looking for a SMIME key?
>
> Again: this is an issue is for a layer that is not ours. The question is
> identical to whether or not your SMTP server will or will not accept both
> "marka" and "MARKA".

No it isn't.

The SMTP server for my addresses will treat the input as case
insensitive.

The input to this process is treated as case sensitive.  This means
that I have to enter records for:

marka, markA, marKa, maRka, mArka, Marka, marKA, maRKa, mARka, MArka,
maRkA, mArkA, MarkA, ...

to achieve parity.

Note both this draft and SMTP are taking email address as input, not
normalised email addresses.

> >> From my perspective there isn't a hard and fast answer to that.
> >
> > We could publish rules, in the DNS, for the MUA to use so that it
> > doesn't have to guess.
>
> We could. And the SMTP folks could do the same. Or we could finish this
> work in the next five years.

Yes, IDNA was a horrible protracted problem.

> --Paul Hoffman
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From paul.hoffman@vpnc.org  Sun Jan 12 16:12:59 2014
Return-Path: 
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 42D1D1AC4AB for ; Sun, 12 Jan 2014 16:12:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.347
X-Spam-Level: 
X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] autolearn=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 muvEe0Fj8v0T for ; Sun, 12 Jan 2014 16:12:58 -0800 (PST)
Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 876921A1F56 for ; Sun, 12 Jan 2014 16:12:58 -0800 (PST)
Received: from [10.20.30.90] (50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230]) (authenticated bits=0) by hoffman.proper.com (8.14.7/8.14.7) with ESMTP id s0CNqiNn015027 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 12 Jan 2014 16:52:46 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: hoffman.proper.com: Host 50-1-51-230.dsl.dynamic.fusionbroadband.com [50.1.51.230] claimed to be [10.20.30.90]
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Paul Hoffman 
In-Reply-To: <20140112235927.BBCA6CD007C@rock.dv.isc.org>
Date: Sun, 12 Jan 2014 16:12:28 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C146AD8-5E93-4D8D-A615-C0C2D9904697@vpnc.org>
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org>  <20140110021746.GR2317@mournblade.imrryr.org>  <20140110035933.31003CADEAB@rock.dv.isc.org> <65157350-8CCE-43D0-B8AC-163A2149F43D@vpnc.org> <20140112235927.BBCA6CD007C@rock.dv.isc.org>
To: Mark Andrews 
X-Mailer: Apple Mail (2.1827)
Cc: "dane@ietf.org list" 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Mon, 13 Jan 2014 00:12:59 -0000

If you believe that the DANE WG gets to change the SMTP standard, there =
is not much we have to discuss, is there?

--Paul Hoffman=

From marka@isc.org  Sun Jan 12 17:15:51 2014
Return-Path: 
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 4D5441AD8EA for ; Sun, 12 Jan 2014 17:15:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.439
X-Spam-Level: 
X-Spam-Status: No, score=-2.439 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.538, 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 xOcb1CbGQlFd for ; Sun, 12 Jan 2014 17:15:49 -0800 (PST)
Received: from mx.ams1.isc.org (mx.ams1.isc.org [IPv6:2001:500:60::65]) by ietfa.amsl.com (Postfix) with ESMTP id 909311ACC91 for ; Sun, 12 Jan 2014 17:15:49 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) by mx.ams1.isc.org (Postfix) with ESMTP id 7A8F82383D2; Mon, 13 Jan 2014 01:15:25 +0000 (UTC) (envelope-from marka@isc.org)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C1DFF160485; Mon, 13 Jan 2014 01:26:07 +0000 (UTC)
Received: from rock.dv.isc.org (c211-30-183-50.carlnfd1.nsw.optusnet.com.au [211.30.183.50]) by zmx1.isc.org (Postfix) with ESMTPSA id 8BB4A160484; Mon, 13 Jan 2014 01:26:07 +0000 (UTC)
Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 0BDA2CD076B; Mon, 13 Jan 2014 12:16:49 +1100 (EST)
To: Paul Hoffman 
From: Mark Andrews 
References: <89AE05E1-BC6C-46BA-A4CC-A8F29070096D@vpnc.org>  <20140109173943.GL2317@mournblade.imrryr.org>  <20140109205604.GM2317@mournblade.imrryr.org>  <20140110004954.GQ2317@mournblade.imrryr.org>  <20140110021746.GR2317@mournblade.imrryr.org>  <20140110035933.31003CADEAB@rock.dv.isc.org> <65157350-8CCE-43D0-B8AC-163A2149F43D@vpnc.org> <20140112235927.BBCA6CD007C@rock.dv.isc.org> <0C146AD8-5E93-4D8D-A615-C0C2D9904697@vpnc.org>
In-reply-to: Your message of "Sun, 12 Jan 2014 16:12:28 -0800." <0C146AD8-5E93-4D8D-A615-C0C2D9904697@vpnc.org>
Date: Mon, 13 Jan 2014 12:16:49 +1100
Message-Id: <20140113011650.0BDA2CD076B@rock.dv.isc.org>
Cc: "dane@ietf.org list" 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-04.txt
X-BeenThere: dane@ietf.org
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: Mon, 13 Jan 2014 01:15:51 -0000

In message <0C146AD8-5E93-4D8D-A615-C0C2D9904697@vpnc.org>, Paul Hoffman writes
:
> If you believe that the DANE WG gets to change the SMTP standard, there =
> is not much we have to discuss, is there?
> 
> --Paul Hoffman=

Dane is *externalising* a function that in normally internal to SMTP.
Dane needs to address this issue.

This is like if the DNS was case sensitive.  gethostbyname would
have to downcase/uppercase the inputs to the DNS call and the data
entry would have to be similarly case converted.  Rather than doing
this it was decided that the keys would be case insensitive in DNS
lookups.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org

From scottr.nist@gmail.com  Tue Jan 14 05:56:50 2014
Return-Path: 
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 5DE4B1ADF76 for ; Tue, 14 Jan 2014 05:56:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level: 
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_MED=-2.3, SPF_SOFTFAIL=0.665] 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 05EZaG6ReCAp for ; Tue, 14 Jan 2014 05:56:48 -0800 (PST)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id A45121ADFF8 for ; Tue, 14 Jan 2014 05:56:48 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 14 Jan 2014 08:56:00 -0500
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 14 Jan 2014 08:56:36 -0500
Received: from 6-140.antd.nist.gov (6-140.antd.nist.gov [129.6.140.6])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s0EDuXlR008893	for ; Tue, 14 Jan 2014 08:56:33 -0500
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Scott Rose 
In-Reply-To: <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org>
Date: Tue, 14 Jan 2014 08:56:33 -0500
Content-Transfer-Encoding: quoted-printable
Message-ID: <410B9D9B-E437-4335-82AD-AF96AE46C3E8@gmail.com>
References: <20140106212911.12960.24322.idtracker@ietfa.amsl.com>  <58D91468-4295-4AEB-A5F4-3C796CBF047A@vpnc.org>
To: "dane@ietf.org list" 
X-Mailer: Apple Mail (2.1827)
X-NIST-MailScanner-Information: 
Subject: Re: [dane] I-D Action: draft-ietf-dane-smime-03.txt
X-BeenThere: dane@ietf.org
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: Tue, 14 Jan 2014 13:56:50 -0000

On Jan 8, 2014, at 10:54 AM, Paul Hoffman  wrote:

> Thanks for the review, Scott. I didn't see it until I has pulled the =
lever on -04 to deal with a few of Mark's comments.
>=20
I'd rather hear negative reviews of bad ideas than no reviews of good =
ones.=20


> On Jan 8, 2014, at 6:58 AM, Scott Rose  wrote:
>=20
>> 1. naming convention to help distinguish between signing and =
encryption key certs (for enterprises that use separate certs for =
encrypting and signing).  It helps reduce the size of the SMIMEA RRset a =
bit, but admittedly minor compared to the size of an X.509 cert.
>=20
> The slight saving of space also introduces a new, significant failure =
mode, namely that if the person listing the cert in the DNS gets the =
type wrong then the receiver can't use it. I'd say "no" on this one.

Admittedly it doesn't save much. =20

>=20
>> 2. a new CU value for "revoked" to indicate that this user's =
certificates have been revoked. =20
>=20
> We considered things like this for TLSA, and the WG seemed very =
hesitant to have the DNS be used as a second, unofficial revocation =
mechanism. For instance, what would it mean for the DNS to say that an =
S/MIME cert is revoked, but when the user pulls a fresh CRL, the cert =
isn't there? The best we might do is to have a signal for "go refresh =
your revocation view" in the DNS, but that seems like very marginal =
value.
>=20

Our thinking was with local trust anchors where places may not keep =
their CRL's up to date or even make it available.  I hope it's not =
optimistic in thinking that new DANE uses will encourage people to keep =
CRL's current.


>> There are some signed/encrypted email projects rolling out now that =
are using CERT RR's or combinations of SRV RR's and LDAP servers.  =
Having something like SMIME would be an improvement, but the spec needs =
to be finalized. =20
>=20
> And Jakob and I apologize for the long lag since the earlier draft. We =
too would like to see this finished.
>=20

Count me as a reviewer.

Scott

> --Paul Hoffman


From stephen.nightingale@nist.gov  Tue Jan 14 07:58:52 2014
Return-Path: 
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 862921AE017 for ; Tue, 14 Jan 2014 07:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 CEOyLgQWUIrN for ; Tue, 14 Jan 2014 07:58:51 -0800 (PST)
Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 4A7021ADFCD for ; Tue, 14 Jan 2014 07:58:51 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.174.1; Tue, 14 Jan 2014 10:58:06 -0500
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Tue, 14 Jan 2014 10:58:38 -0500
Received: from [127.0.0.1] (31-140.antd.nist.gov [129.6.140.31])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s0EFwSDh019459;	Tue, 14 Jan 2014 10:58:29 -0500
Message-ID: <52D55E7E.1090702@nist.gov>
Date: Tue, 14 Jan 2014 10:57:50 -0500
From: Stephen Nightingale 
Organization: NIST
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: 
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-Information: 
Subject: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: night@nist.gov
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jan 2014 15:58:52 -0000

Per the BCP, section 3.3 on Certificate Name Check conventions, the Note 
says that "except with certificate usage 3, where name checks are not 
applicable (see section 4.1) ....."

Section 4.1 is presently empty.  Is there a notion of populating the 
Type Specific DANE Guidelines in section 4?

 From all the above I take it to mean that if the Subject Alt Name in 
the TLS Server served certificate  differs from the domain name in the 
TLSA record (for example it offers an email address instead of a DNS 
label or wildcard), it doesn't matter because we don't check it.

Cheers,

Stephen.



From viktor1dane@dukhovni.org  Tue Jan 14 08:31:34 2014
Return-Path: 
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 10EBC1AE10A for ; Tue, 14 Jan 2014 08:31:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 crd3BtSGJOmN for ; Tue, 14 Jan 2014 08:31:31 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 26FD71AE0FD for ; Tue, 14 Jan 2014 08:31:30 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C96E02AB21A; Tue, 14 Jan 2014 16:31:18 +0000 (UTC)
Date: Tue, 14 Jan 2014 16:31:18 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140114163118.GB2317@mournblade.imrryr.org>
References: <52D55E7E.1090702@nist.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52D55E7E.1090702@nist.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 14 Jan 2014 16:31:34 -0000

On Tue, Jan 14, 2014 at 10:57:50AM -0500, Stephen Nightingale wrote:

> Per the BCP, section 3.3 on Certificate Name Check conventions, the
> Note says that "except with certificate usage 3, where name checks
> are not applicable (see section 4.1) ....."
> 
> Section 4.1 is presently empty.  Is there a notion of populating the
> Type Specific DANE Guidelines in section 4?

Yes, I added the new text last week.  Wes should be reviewing it today,
so your timing is perfect.

You can grab a copy at:

	https://github.com/vdukhovni/ietf.git

> From all the above I take it to mean that if the Subject Alt Name in
> the TLS Server served certificate  differs from the domain name in
> the TLSA record (for example it offers an email address instead of a
> DNS label or wildcard), it doesn't matter because we don't check it.

Yes, and in fact there need not be any subjectAltNames, the subject
DN may be an empty sequence, and the certificate may be either
already expired, not yet valid, or both.  With usage 3 the TLSA
record binds the service end-point directly to a public key, the
certificate itself is just a public-key container.

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: 
        Validity
            Not Before: Jan 14 16:25:19 2014 GMT
            Not After : Jan 13 16:25:19 2014 GMT
        Subject: 
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub: 
                    04:ae:38:28:5a:22:68:0b:40:6d:51:c3:14:17:4d:
                    99:51:50:21:88:0f:01:c2:a3:0d:f2:02:28:07:a4:
                    93:07:22:fd:e9:82:88:f9:6e:da:4c:43:3f:3e:24:
                    4b:9d:aa:fe:8e:6a:f7:af:48:e1:7b:e5:25:77:05:
                    ec:37:d9:54:8a
                ASN1 OID: prime256v1
    Signature Algorithm: ecdsa-with-SHA256
        30:45:02:20:3b:cf:71:f5:21:ce:69:2f:82:49:37:ee:ee:7b:
        4d:f9:6a:36:a9:f6:f4:9c:29:43:f8:51:b0:b2:dc:63:9a:c8:
        02:21:00:e2:2f:d2:61:ef:3b:56:c0:4a:a4:3e:e0:67:17:9c:
        7c:3b:41:b1:7e:f0:23:22:7d:55:80:aa:4d:85:a1:0f:05
-----BEGIN CERTIFICATE-----
MIHsMIGToAMCAQICAQEwCgYIKoZIzj0EAwIwADAeFw0xNDAxMTQxNjI1MTlaFw0x
NDAxMTMxNjI1MTlaMAAwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAASuOChaImgL
QG1RwxQXTZlRUCGIDwHCow3yAigHpJMHIv3pgoj5btpMQz8+JEudqv6OavevSOF7
5SV3Bew32VSKMAoGCCqGSM49BAMCA0gAMEUCIDvPcfUhzmkvgkk37u57TflqNqn2
9JwpQ/hRsLLcY5rIAiEA4i/SYe87VsBKpD7gZxecfDtBsX7wIyJ9VYCqTYWhDwU=
-----END CERTIFICATE-----

-- 
	Viktor.

From p@sys4.de  Wed Jan 15 09:25:55 2014
Return-Path: 
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 D3CFB1AE0E7 for ; Wed, 15 Jan 2014 09:25:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.99
X-Spam-Level: 
X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538, 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 FgGizzSvp0rp for ; Wed, 15 Jan 2014 09:25:53 -0800 (PST)
Received: from mail.sys4.de (mail.sys4.de [194.126.158.139]) by ietfa.amsl.com (Postfix) with ESMTP id B897C1ADF7F for ; Wed, 15 Jan 2014 09:25:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sys4.de; h= content-transfer-encoding:content-disposition:content-type :content-type:mime-version:message-id:subject:subject:from:from :date:date; s=mail201310; t=1389806836; x=1391621237; bh=FQ3cKSj D+VJSoyRRe2Jsb11UYCx6y9yKlGuhge0OYlI=; b=wEHVPdzsccRv6w0Vi6OeOHZ g+Kpthc+DdqBPcWnY+klshgTgdWlLDvAK9gDAz6+bKpR0cNm41YGzC4blgUP6dQv hgXQIGei60mfP2rZ6qPqqHn7nfSNBzXECZh+xrSeBngnbpZW7Tw2TTbHYzR14NzK oCm6wktgxgiao7HrGI8/PyGjRq74nvrgWCkl1J34UGJvuNFfakcXwNTZwaJkedtO qA6hbDCJY0cE3A2jyLcR6I3EfE5v8F/UH6bqK64esDG2OhfSgcL/hc7IO+rVLlFj aZ+UAj1BZsaajswLrWQZ/Kwi5Y8u82lEMI3RWUYbGll5VnZj6SOy45LLNgDUFAg= =
X-Virus-Scanned: Debian amavisd-new at mail.sys4.de
Received: from sys4.de (ppp-93-104-190-186.dynamic.mnet-online.de [93.104.190.186]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sys4.de (Postfix) with ESMTPSA id 3f4FpX5NRWzR2 for ; Wed, 15 Jan 2014 18:27:16 +0100 (CET)
Date: Wed, 15 Jan 2014 18:25:38 +0100
From: Patrick Ben Koetter 
To: dane@ietf.org
Message-ID: <20140115172538.GF22625@sys4.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Subject: [dane] Clarification for "2.3.1. TLSA certificate usages"
X-BeenThere: dane@ietf.org
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, 15 Jan 2014 17:25:56 -0000

Greetings,

I worked my way through

today.

Unless I missed an explanation in another section I think the introduction to
"2.3.1. TLSA certificate usages" would benefit from a few words on the meaning
of "usage", "selector" and "associated data" or a reference to documents that
specify the terminology.

All subsections use them and I think knowing their meaning would help
understand the subsections better.

Regards

Patrick Koetter
p@rick

-- 
[*] sys4 AG
 
http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München
 
Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
 

From viktor1dane@dukhovni.org  Wed Jan 15 09:40:07 2014
Return-Path: 
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 9E2EE1AE144 for ; Wed, 15 Jan 2014 09:40:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 pgEB-9X4-eRF for ; Wed, 15 Jan 2014 09:40:05 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 475751AE11D for ; Wed, 15 Jan 2014 09:40:05 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E05A62AB212; Wed, 15 Jan 2014 17:39:52 +0000 (UTC)
Date: Wed, 15 Jan 2014 17:39:52 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140115173952.GG2317@mournblade.imrryr.org>
References: <20140115172538.GF22625@sys4.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140115172538.GF22625@sys4.de>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Clarification for "2.3.1. TLSA certificate usages"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 15 Jan 2014 17:40:07 -0000

On Wed, Jan 15, 2014 at 06:25:38PM +0100, Patrick Ben Koetter wrote:

> I worked my way through
> 
> today.
> 
> Unless I missed an explanation in another section I think the introduction to
> "2.3.1. TLSA certificate usages" would benefit from a few words on the meaning
> of "usage", "selector" and "associated data" or a reference to documents that
> specify the terminology.
> 
> All subsections use them and I think knowing their meaning would help
> understand the subsections better.

Thanks,  this is a timely comment, we're about to submit the work
in progress updates.  The SMTP draft was cleaved in twain early in
its evolution from a document that aimed to cover more protocols
than just SMTP.  The part that defines these terms is in its other
half, draft-dane-ops-02.html, we can add a brief description of
the terms with references to RFC 6698.

-- 
	Viktor.

From dromasca@avaya.com  Wed Jan 15 07:11:52 2014
Return-Path: 
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 79F281AE38D; Wed, 15 Jan 2014 07:11:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level: 
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 JMqYjjT4AMJY; Wed, 15 Jan 2014 07:11:46 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id EDA0C1AE395; Wed, 15 Jan 2014 07:11:35 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AsYYAE6k1lKHCzI1/2dsb2JhbABZgkcjIThWpXkIjCOIW4EVFnSCJwEBAxIbTBIBFQcOViYBBA4NARmHYgEMnWWmQ40OgUAgEYI2D2aBEwSZUIU8iymDLYIq
X-IronPort-AV: E=Sophos;i="4.95,663,1384318800"; d="scan'208,217";a="45074901"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 15 Jan 2014 10:11:21 -0500
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 15 Jan 2014 09:59:27 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Wed, 15 Jan 2014 16:11:20 +0100
From: "Romascanu, Dan (Dan)" 
To: "gen-art@ietf.org" 
Thread-Topic: Gen-ART Review of draft-ietf-dane-registry-acronyms-03
Thread-Index: Ac8SBAXAPosF7k1MRom7f+BaACrMYw==
Date: Wed, 15 Jan 2014 15:11:19 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243CEC9A@AZ-FFEXMB04.global.avaya.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA243CEC9AAZFFEXMB04globa_"
MIME-Version: 1.0
X-Mailman-Approved-At: Wed, 15 Jan 2014 10:05:03 -0800
Cc: "draft-ietf-dane-registry-acronyms.all@tools.ietf.org" , "dane@ietf.org" 
Subject: [dane] Gen-ART Review of draft-ietf-dane-registry-acronyms-03
X-BeenThere: dane@ietf.org
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, 15 Jan 2014 15:11:52 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA243CEC9AAZFFEXMB04globa_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR=
T, please see the FAQ at



.



Please resolve these comments along with any other Last Call comments you m=
ay receive.



Document: http://www.ietf.org/id/draft-ietf-dane-registry-acronyms-03.txt

Reviewer: Dan Romascanu

Review Date: 1/15/2014

IETF LC End Date: 1/23/2014

IESG Telechat date:



Summary:

Ready with issues



Major issues:

None - it's a simple, clear and useful document.



Minor issues:

1.       In Section 2.3 the I-D recommends that the values in reference col=
umn for SHA-256 and SHA-512 refer to [RFC 6698] while the IANA Consideratio=
ns section in RFC 6698 recommends and the registry entries in the TLSA Matc=
hing Types table at http://www.iana.org/assignments/dane-parameters/dane-pa=
rameters.xhtml  point to [RFC 6234].

2.       As this I-D updates the registries with a column for acronyms, it =
seems more accurate that the reference columns of all tables mention both  =
[RFC 6698] and [RFC XXXX] (this RFC)



Nits/editorial comments:

In the Introduction section:

'This document updates the IANA registry definition for TLSA

   record to add a column with acronym for each specified field'

s/acronym/an acronym/










--_000_9904FB1B0159DA42B0B887B7FA8119CA243CEC9AAZFFEXMB04globa_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











I am the assigned Gen-ART reviewer for this draft=
. For background on Gen-ART, please see the FAQ at


 


<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArt=
faq>.


 


Please resolve these comments along with any othe=
r Last Call comments you may receive.


 


Document: http://www.ietf.org/id/draft-ietf-dane-=
registry-acronyms-03.txt


Reviewer: Dan Romascanu


Review Date: 1/15/2014


IETF LC End Date: 1/23/2014


IESG Telechat date:


 


Summary:


Ready with issues


 


Major issues:


None – it’s a simple, clear and usefu=
l document. 


 


Minor issues:



1.      
In Section 2.3 the I-D rec=
ommends that the values in reference column for SHA-256 and SHA-512 refer t=
o [RFC 6698] while the IANA Considerations section in RFC 6698 recommends a=
nd the registry entries in the TLSA
 Matching Types table at 
http://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml &=
nbsp;point to [RFC 6234].



2.      
As this I-D updates the re=
gistries with a column for acronyms, it seems more accurate that the refere=
nce columns of all tables mention both  [RFC 6698] and [RFC XXXX] (thi=
s RFC)


 


Nits/editorial comments:


In the Introduction section: 


‘This document updates the IANA registry definition for TLSA


   record to add a colu=
mn with acronym for each specified field’



s/acronym/an acronym/<=
/span>


 


 


 


 


 






--_000_9904FB1B0159DA42B0B887B7FA8119CA243CEC9AAZFFEXMB04globa_--

From internet-drafts@ietf.org  Wed Jan 15 19:45:46 2014
Return-Path: 
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 DEA3C1AE1B4; Wed, 15 Jan 2014 19:45:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 1MS9c0k2vwHG; Wed, 15 Jan 2014 19:45:45 -0800 (PST)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B70F11AE206; Wed, 15 Jan 2014 19:45:44 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: internet-drafts@ietf.org
To: i-d-announce@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 4.90.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20140116034544.28539.14191.idtracker@ietfa.amsl.com>
Date: Wed, 15 Jan 2014 19:45:44 -0800
Cc: dane@ietf.org
Subject: [dane] I-D Action: draft-ietf-dane-ops-02.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 03:45:47 -0000

A New Internet-Draft is available from the on-line Internet-Drafts director=
ies.
 This draft is a work item of the DNS-based Authentication of Named Entitie=
s Working Group of the IETF.

        Title           : DANE TLSA implementation and operational guidance
        Authors         : Viktor Dukhovni
                          Wes Hardaker
	Filename        : draft-ietf-dane-ops-02.txt
	Pages           : 19
	Date            : 2014-01-15

Abstract:
   This memo provides guidance to server operators to help ensure that
   clients will be able to authenticate a server's certificate chain via
   published TLSA records.  Guidance is also provided to clients for
   selecting reliable TLSA record parameters and using them for server
   authentication.  Finally, guidance is given to protocol designers who
   wish to make use of TLSA records when securing protocols using a
   combination of TLS and TLSA.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dane-ops/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dane-ops-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-ops-02


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From mrex@sap.com  Thu Jan 16 07:20:14 2014
Return-Path: 
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 D206E1AE4C5 for ; Thu, 16 Jan 2014 07:20:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 i_zQm_ItaW6K for ; Thu, 16 Jan 2014 07:20:12 -0800 (PST)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4451AE4C0 for ; Thu, 16 Jan 2014 07:20:12 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s0GFJxLs009009 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 16 Jan 2014 16:19:59 +0100 (MET)
In-Reply-To: <20140114163118.GB2317@mournblade.imrryr.org>
To: dane@ietf.org
Date: Thu, 16 Jan 2014 16:19:59 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 15:20:15 -0000

Viktor Dukhovni wrote:
>
> Yes, and in fact there need not be any subjectAltNames, the subject
> DN may be an empty sequence, and the certificate may be either
> already expired, not yet valid, or both.  With usage 3 the TLSA
> record binds the service end-point directly to a public key, the
> certificate itself is just a public-key container.
> 
> Certificate:
>     Data:
>         Version: 3 (0x2)
>         Serial Number: 1 (0x1)
>         Signature Algorithm: ecdsa-with-SHA256
>         Issuer: 
>         Validity
>             Not Before: Jan 14 16:25:19 2014 GMT
>             Not After : Jan 13 16:25:19 2014 GMT
>         Subject: 
>         Subject Public Key Info:
>             Public Key Algorithm: id-ecPublicKey
>                 Public-Key: (256 bit)
>                 pub: 
>                     04:ae:38:28:5a:22:68:0b:40:6d:51:c3:14:17:4d:
>                     99:51:50:21:88:0f:01:c2:a3:0d:f2:02:28:07:a4:
>                     93:07:22:fd:e9:82:88:f9:6e:da:4c:43:3f:3e:24:
>                     4b:9d:aa:fe:8e:6a:f7:af:48:e1:7b:e5:25:77:05:
>                     ec:37:d9:54:8a
>                 ASN1 OID: prime256v1
>     Signature Algorithm: ecdsa-with-SHA256
>         30:45:02:20:3b:cf:71:f5:21:ce:69:2f:82:49:37:ee:ee:7b:
>         4d:f9:6a:36:a9:f6:f4:9c:29:43:f8:51:b0:b2:dc:63:9a:c8:
>         02:21:00:e2:2f:d2:61:ef:3b:56:c0:4a:a4:3e:e0:67:17:9c:
>         7c:3b:41:b1:7e:f0:23:22:7d:55:80:aa:4d:85:a1:0f:05


Excuse me while I panic.

Don't be surprised if the above will be unconditionally rejected by some
PKIX software (because it is not well formed and should fail
plausibility checks in the certificate parser).

AFAIK, the issuer field of an X.509v3 certficate must never be empty,
and the subject field can only be empty if a non-empty subjectAltName
is present.

-Martin

From warren@kumari.net  Thu Jan 16 07:58:31 2014
Return-Path: 
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 A8EE81AE35F for ; Thu, 16 Jan 2014 07:58:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 7617h6bbwhdt for ; Thu, 16 Jan 2014 07:58:30 -0800 (PST)
Received: from mail-we0-f170.google.com (mail-we0-f170.google.com [74.125.82.170]) by ietfa.amsl.com (Postfix) with ESMTP id 181421AE0E2 for ; Thu, 16 Jan 2014 07:58:29 -0800 (PST)
Received: by mail-we0-f170.google.com with SMTP id u57so3410438wes.29 for ; Thu, 16 Jan 2014 07:58:17 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=OmOWRhBFFSy/wmQw2CB/HzqaR9lcfBpEJcvSZVDIUbU=; b=MH9LHQ3GqncxJwXl+WBrb+2tTr0DJ1H7QMWpjeQcMQe50K+LD8EO5OyhcEDfxzMOMp wW0Kw7q1IOxURNdESbNSlY5N87PXarPfu9KUN/hssLK4VtSkkxfTWqEZi1dkNyTlk9y/ AEZUNehmDLGGT8LQfAJ4BFBfbmtmWtaVmp1Wf1UC4dqpPm/zs5DiUCLTWmT9R8KHgbe8 jwzXVbV1cpJZ9ludEc+PwYYsISjbLxIj3l/w49Z7IbRVvjP7g6ux6LX+QKhW7S8Z/CBg 76Ydhq+f+Ej1L4i+rYkp0VNRybnQEP6p6PS8BHX5KXsNMBxfIEJIPjcabTpOT/l/hI7D 4qgg==
X-Gm-Message-State: ALoCoQkoeX7q3f2STX2liC12o0BYemU30c8uym7KLvGXYedSmYwUmfw+j7GoGJME2KhHGm3uBsUv
MIME-Version: 1.0
X-Received: by 10.180.12.70 with SMTP id w6mr8849882wib.4.1389887896532; Thu, 16 Jan 2014 07:58:16 -0800 (PST)
Received: by 10.194.54.167 with HTTP; Thu, 16 Jan 2014 07:58:16 -0800 (PST)
X-Originating-IP: [98.244.98.35]
Date: Thu, 16 Jan 2014 10:58:16 -0500
Message-ID: 
From: Warren Kumari 
To: dane@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: [dane] Meeting at IETF89 (London).
X-BeenThere: dane@ietf.org
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: Thu, 16 Jan 2014 15:58:31 -0000

Hi all,

We have requested a 2 hour DNAE session in London.

It has been a while since we met -- please get your agenda requests in...
Preference is given to already discussed drafts, things that need face
to face time, etc.



A very quick update on the DANE for IETF mail situation:
The IETF mail servers still do not do STARTTLS. AMS is short staffed
at the moment, and is prioritizing mission critical things first.
Hopefully they will manage to get this done in January -- once that is
done, adding the TLSA record (and updating the documentation!) should
be (hopefully) quick and easy...

W


wkumari:~$ dig +short +nocomment MX ietf.org
0 mail.ietf.org.
wkumari@vimes:~$ telnet mail.ietf.org 25
Trying 2001:1900:3001:11::2c...
Connected to mail.ietf.org.
Escape character is '^]'.
220 ietfa.amsl.com ESMTP Postfix
EHLO example.com
250-ietfa.amsl.com
250-PIPELINING
250-SIZE 67108864
250-ETRN
250-AUTH PLAIN LOGIN
250-AUTH=PLAIN LOGIN
250-ENHANCEDSTATUSCODES
250-8BITMIME
250 DSN
STARTTLS
502 5.5.1 Error: command not implemented
quit
221 2.0.0 Bye
Connection closed by foreign host.

From kent@bbn.com  Thu Jan 16 08:46:10 2014
Return-Path: 
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 CE2211AE1D0 for ; Thu, 16 Jan 2014 08:46:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.738
X-Spam-Level: 
X-Spam-Status: No, score=-4.738 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538, 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 ZK_cSVb9_CMQ for ; Thu, 16 Jan 2014 08:46:08 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6181AE0F7 for ; Thu, 16 Jan 2014 08:46:08 -0800 (PST)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54081) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W3q4p-000NOJ-Gj for dane@ietf.org; Thu, 16 Jan 2014 11:45:55 -0500
Message-ID: <52D80CC4.9020407@bbn.com>
Date: Thu, 16 Jan 2014 11:45:56 -0500
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dane@ietf.org
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp>
In-Reply-To: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp>
Content-Type: multipart/alternative; boundary="------------040300030206070105080302"
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
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: Thu, 16 Jan 2014 16:46:11 -0000

This is a multi-part message in MIME format.
--------------040300030206070105080302
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Martin is correct. This is not well-formed cert as per RFC 5280:

4.1.2.4.Issuer

The issuer field identifies the entity that has signed and issued the

certificate.The issuer field MUST contain a non-empty distinguished

name (DN)



4.1.2.6.Subject

The subject field identifies the entity associated with the public

carried in the subject field and/or the subjectAltName extension.

We issued 5280bis in part to accommodate DANE's use of ss certs. Please 
don't
provide examples that are obviously non-complaint relative to basic PKIX and
X.509 specs.

Steve

--------------040300030206070105080302
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit


  
    
  
  
    Martin is correct. This is not  well-formed cert as per RFC 5280:

    

    
    
4.1.2.4.  Issuer

    
 

    
   The issuer field
        identifies the entity that
        has signed and issued the

    
   certificate. 
        The issuer field MUST contain a non-empty distinguished

    
   name (DN)

      

     
    

      

    
    
4.1.2.6.  Subject

    
 

    
   The subject field
        identifies the entity
        associated with the public

        carried
        in the subject field and/or the subjectAltName extension.
      

    

    
    
    
    
    
    
    
    
    
    We issued 5280bis in
    part to accommodate DANE's use of ss certs. Please don't

    provide examples that are obviously non-complaint relative to basic
    PKIX and

    X.509 specs.

    

    Steve

  


--------------040300030206070105080302--

From stephen.nightingale@nist.gov  Thu Jan 16 09:36:22 2014
Return-Path: 
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 5B6871AE3FA for ; Thu, 16 Jan 2014 09:36:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.737
X-Spam-Level: 
X-Spam-Status: No, score=-4.737 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.538] 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 FtKADyoPWQDc for ; Thu, 16 Jan 2014 09:36:19 -0800 (PST)
Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 650741AE3B4 for ; Thu, 16 Jan 2014 09:36:19 -0800 (PST)
Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.174.1; Thu, 16 Jan 2014 12:35:26 -0500
Received: from postmark.nist.gov (129.6.16.94) by WSXGHUB1.xchange.nist.gov (129.6.18.96) with Microsoft SMTP Server (TLS) id 8.3.327.1; Thu, 16 Jan 2014 12:36:06 -0500
Received: from [127.0.0.1] (31-140.antd.nist.gov [129.6.140.31])	by postmark.nist.gov (8.13.8/8.13.1) with ESMTP id s0GHZqjp004063	for ; Thu, 16 Jan 2014 12:35:55 -0500
Message-ID: <52D81875.6050705@nist.gov>
Date: Thu, 16 Jan 2014 12:35:49 -0500
From: Stephen Nightingale 
Organization: NIST
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: 
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com>
In-Reply-To: <52D80CC4.9020407@bbn.com>
Content-Type: multipart/alternative; boundary="------------000105000405040102090108"
X-NIST-MailScanner-Information: 
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: night@nist.gov
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 17:36:22 -0000

--------------000105000405040102090108
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit


Granted the cert even for Cert Use DANE-EE(3) must be well-formed in 
order to see what's in it.
But I believe Victor's main point is that the only field *value* that 
matters for DANE-EE(3)
is the Public Key.  Issuer, Common Name and SubjectAltName are just 
deckchairs.

Stephen.


On 1/16/2014 11:45 AM, Stephen Kent wrote:
> Martin is correct. This is not  well-formed cert as per RFC 5280:
>
> 4.1.2.4.Issuer
>
> The issuer field identifies the entity that has signed and issued the
>
> certificate.The issuer field MUST contain a non-empty distinguished
>
>    name (DN)
>
>
>
> 4.1.2.6.Subject
>
> The subject field identifies the entity associated with the public
>
> carried in the subject field and/or the subjectAltName extension.
>
> We issued 5280bis in part to accommodate DANE's use of ss certs. 
> Please don't
> provide examples that are obviously non-complaint relative to basic 
> PKIX and
> X.509 specs.
>
> Steve
>
>
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane


--------------000105000405040102090108
Content-Type: text/html; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit


  
    
  
  
    


      Granted the cert even for Cert Use DANE-EE(3) must be well-formed
      in order to see what's in it.

      But I believe Victor's main point is that the only field *value*
      that matters for DANE-EE(3)

      is the Public Key.  Issuer, Common Name and SubjectAltName are
      just deckchairs.

      

      Stephen.

      

      

      On 1/16/2014 11:45 AM, Stephen Kent wrote:

    

    

      
      Martin is correct. This is not  well-formed cert as per RFC 5280:

      

      
      
4.1.2.4.  Issuer

      
 

      
   The issuer field
          identifies the entity that has signed and issued the

      
   certificate.  The issuer field MUST
          contain a non-empty distinguished

      
   name (DN)

        

        

        

      
      
4.1.2.6.  Subject

      
 

      
   The subject field
          identifies the entity associated with the public

          carried in the subject
          field and/or the subjectAltName extension. 

      

      
      
      
      
      
      
      
      
      We issued 5280bis in
      part to accommodate DANE's use of ss certs. Please don't

      provide examples that are obviously non-complaint relative to
      basic PKIX and

      X.509 specs.

      

      Steve

      

      

      

      
_______________________________________________
dane mailing list
dane@ietf.org
https://www.ietf.org/mailman/listinfo/dane


    

    

  


--------------000105000405040102090108--

From viktor1dane@dukhovni.org  Thu Jan 16 10:08:26 2014
Return-Path: 
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 3B5F11A1DFA for ; Thu, 16 Jan 2014 10:08:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 qAN4IkOskwQD for ; Thu, 16 Jan 2014 10:08:23 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 6BC281A16F0 for ; Thu, 16 Jan 2014 10:08:23 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 22BBE2AB21F; Thu, 16 Jan 2014 18:08:10 +0000 (UTC)
Date: Thu, 16 Jan 2014 18:08:10 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140116180810.GN2317@mournblade.imrryr.org>
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com> <52D81875.6050705@nist.gov>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52D81875.6050705@nist.gov>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 16 Jan 2014 18:08:26 -0000

On Thu, Jan 16, 2014 at 12:35:49PM -0500, Stephen Nightingale wrote:

> Granted the cert even for Cert Use DANE-EE(3) must be well-formed in
> order to see what's in it.
>
> But I believe Victor's main point is that the only field *value*
> that matters for DANE-EE(3) is the Public Key.  Issuer, Common Name
> and SubjectAltName are just deckchairs.

Correct, the point is that DANE verification makes no use of these values,
if however underlying libraries are likely to object, certificates like
this should perhaps be avoided.  Note however, that this means that a
certificate with an empty subject DN can never be self-signed.

I'll strive to avoid publishing examples that are likely to fail
interoperability tests.  For what it is worth, OpenSSL does not
mind empty subject and issuer DNs even without a SAN extension, if
the application layer does not object.  The DANE verification code
I wrote on top of OpenSSL likewise does not object with usage
DANE-EE(3).

So my instructions to users will have to suggest something like:

	openssl req ... -subj "/CN=?"

for self signed certificates that are intended solely for DANE-EE(3) use.

-- 
	Viktor.

From ogud@ogud.com  Thu Jan 16 12:46:14 2014
Return-Path: 
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 EE9D21ACCFA for ; Thu, 16 Jan 2014 12:46:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable
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 TQkLqeRpZsch for ; Thu, 16 Jan 2014 12:46:11 -0800 (PST)
Received: from smtp124.ord1c.emailsrvr.com (smtp124.ord1c.emailsrvr.com [108.166.43.124]) by ietfa.amsl.com (Postfix) with ESMTP id 959F61ABBB1 for ; Thu, 16 Jan 2014 12:46:11 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp8.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 521171A0278; Thu, 16 Jan 2014 15:45:59 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp8.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id D84A61A02D0;  Thu, 16 Jan 2014 15:45:58 -0500 (EST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_6FC5AE16-B863-46CE-8F49-E2D7CCFD7A92"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson 
In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA243CEC9A@AZ-FFEXMB04.global.avaya.com>
Date: Thu, 16 Jan 2014 15:45:58 -0500
Message-Id: <08A37247-FE33-4FC4-B56D-9925957D8920@ogud.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA243CEC9A@AZ-FFEXMB04.global.avaya.com>
To: "Romascanu, Dan (Dan)" 
X-Mailer: Apple Mail (2.1510)
Cc: "gen-art@ietf.org" , "draft-ietf-dane-registry-acronyms.all@tools.ietf.org" , "dane@ietf.org" 
Subject: Re: [dane] Gen-ART Review of draft-ietf-dane-registry-acronyms-03
X-BeenThere: dane@ietf.org
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: Thu, 16 Jan 2014 20:46:14 -0000

--Apple-Mail=_6FC5AE16-B863-46CE-8F49-E2D7CCFD7A92
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252


On Jan 15, 2014, at 10:11 AM, "Romascanu, Dan (Dan)" =
 wrote:

> I am the assigned Gen-ART reviewer for this draft. For background on =
Gen-ART, please see the FAQ at
> =20
> .
> =20
> Please resolve these comments along with any other Last Call comments =
you may receive.
> =20
> Document: =
http://www.ietf.org/id/draft-ietf-dane-registry-acronyms-03.txt
> Reviewer: Dan Romascanu
> Review Date: 1/15/2014
> IETF LC End Date: 1/23/2014
> IESG Telechat date:
> =20
> Summary:
> Ready with issues
> =20
> Major issues:
> None =96 it=92s a simple, clear and useful document.

thanks=20

> =20
> Minor issues:
> 1.       In Section 2.3 the I-D recommends that the values in =
reference column for SHA-256 and SHA-512 refer to [RFC 6698] while the =
IANA Considerations section in RFC 6698 recommends and the registry =
entries in the TLSA Matching Types table =
athttp://www.iana.org/assignments/dane-parameters/dane-parameters.xhtml  =
point to [RFC 6234].

Good Catch, fixed=20

> 2.       As this I-D updates the registries with a column for =
acronyms, it seems more accurate that the reference columns of all =
tables mention both  [RFC 6698] and [RFC XXXX] (this RFC)

I'm not sure if I agree, all this document does is to change the format =
of the registries it is not the definitions of any table entry.=20
But I think it would be good to change the reference for each of the =
registries to point to both RFC6698 and RFCXXXX=20

I propose adding to each registry sections the following text:=20
        "Update reference for this registry to include both [RFC6698] =
and [RFC-this-document]"

> =20
> Nits/editorial comments:
> In the Introduction section:
> =91This document updates the IANA registry definition for TLSA
>    record to add a column with acronym for each specified field=92
> s/acronym/an acronym/
> =20

Fixed=20

thanks=20

	Olafur


--Apple-Mail=_6FC5AE16-B863-46CE-8F49-E2D7CCFD7A92
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252



thanks <=
div>

Good Catch, =
fixed 

2. As this I-D updates the registries with a column for =
acronyms, it seems more accurate that the reference columns of all =
tables mention both  [RFC 6698] and [RFC XXXX] (this =
RFC)

I'm not sure if I =
agree, all this document does is to change the format of the registries =
it is not the definitions of any table entry. 
But I =
think it would be good to change the reference for each of the =
registries to point to both RFC6698 and =
RFCXXXX 

I propose adding to each registry =
sections the following text: 
      =
  "Update reference for this registry to include =
both [RFC6698] and =
[RFC-this-document]"

 
In the =
Introduction section:
=91This =
document updates the IANA registry definition for =
TLSA
   record to =
add a column with acronym for each specified =
field=92
	=
Olafur

=

--Apple-Mail=_6FC5AE16-B863-46CE-8F49-E2D7CCFD7A92--

From ogud@ogud.com  Thu Jan 16 12:49:57 2014
Return-Path: 
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 C4C2C1ABBB1 for ; Thu, 16 Jan 2014 12:49:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 WQ-cqc8o7lFH for ; Thu, 16 Jan 2014 12:49:56 -0800 (PST)
Received: from smtp76.ord1c.emailsrvr.com (smtp76.ord1c.emailsrvr.com [108.166.43.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3DA1A16F0 for ; Thu, 16 Jan 2014 12:49:56 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp2.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id EAB661E8447; Thu, 16 Jan 2014 15:49:43 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp2.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id A4B3C1E8431;  Thu, 16 Jan 2014 15:49:43 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson 
In-Reply-To: <52CDFE5C.7020200@cs.tcd.ie>
Date: Thu, 16 Jan 2014 15:49:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <1E3529DE-4611-4350-9982-74E7D2F9E023@ogud.com>
References: <20140106224541.29552.83393.idtracker@ietfa.amsl.com>  <52CDFE5C.7020200@cs.tcd.ie>
To: Stephen Farrell 
X-Mailer: Apple Mail (2.1510)
Cc: dane@ietf.org
Subject: Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-03.txt
X-BeenThere: dane@ietf.org
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: Thu, 16 Jan 2014 20:49:58 -0000

On Jan 8, 2014, at 8:41 PM, Stephen Farrell  =
wrote:

>=20
> Thanks for that. I've requested IETF last call as-is
> since I don't have a problem with the current acronyms
> nor a startlingly better alternative.
>=20
> I've a couple of nits, its fine to fix 'em anytime.
>=20
> section 1:
> - s/confused as what/confused as to what/
> - s/column with acronym/column with an acronym/
>=20
Fixed=20

> section 2:
> - maybe s/upper or lower/upper, mixed or lower/ ?

applied=20

thanks
	Olafur

>=20
> Cheers,
> S.
>=20
>=20
>=20
> On 01/06/2014 11:28 PM, Warren Kumari wrote:
>> On Mon, Jan 6, 2014 at 5:45 PM,   wrote:
>>>=20
>>> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
>>> This draft is a work item of the DNS-based Authentication of Named =
Entities Working Group of the IETF.
>>=20
>> This just adds a note to the abstract explaining that it updates the
>> format of the registry in RFC6698 (to keep the nitter happy...)
>> W
>>=20
>>>=20
>>>        Title           : Adding acronyms to simplify DANE =
conversations
>>>        Author          : Olafur Gudmundsson
>>>        Filename        : draft-ietf-dane-registry-acronyms-03.txt
>>>        Pages           : 5
>>>        Date            : 2014-01-06
>>>=20
>>> Abstract:
>>>   Experience has show that people get confused using the three =
numeric
>>>   fields the TLSA record.  This document specifies descriptive =
acronyms
>>>   for the three numeric fields in the TLSA records.  This document
>>>   updates the format of the IANA registry created by RFC6698.
>>>=20
>>>=20
>>> The IETF datatracker status page for this draft is:
>>> https://datatracker.ietf.org/doc/draft-ietf-dane-registry-acronyms/
>>>=20
>>> There's also a htmlized version available at:
>>> http://tools.ietf.org/html/draft-ietf-dane-registry-acronyms-03
>>>=20
>>> A diff from the previous version is available at:
>>> =
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-registry-acronyms-03
>>>=20
>>>=20
>>> Please note that it may take a couple of minutes from the time of =
submission
>>> until the htmlized version and diff are available at tools.ietf.org.
>>>=20
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>=20
>>> _______________________________________________
>>> dane mailing list
>>> dane@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dane
>> _______________________________________________
>> dane mailing list
>> dane@ietf.org
>> https://www.ietf.org/mailman/listinfo/dane
>>=20
>>=20
> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane


From viktor1dane@dukhovni.org  Thu Jan 16 16:04:19 2014
Return-Path: 
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 505F01AC4A3 for ; Thu, 16 Jan 2014 16:04:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 ZCpmHcg6pdPG for ; Thu, 16 Jan 2014 16:04:16 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 482771AC85E for ; Thu, 16 Jan 2014 16:04:15 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 175232AB191; Fri, 17 Jan 2014 00:04:02 +0000 (UTC)
Date: Fri, 17 Jan 2014 00:04:02 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140117000402.GU2317@mournblade.imrryr.org>
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Meeting at IETF89 (London).
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jan 2014 00:04:19 -0000

On Thu, Jan 16, 2014 at 10:58:16AM -0500, Warren Kumari wrote:

> Hopefully they will manage to get this done in January -- once that is
> done, adding the TLSA record (and updating the documentation!) should
> be (hopefully) quick and easy...
> 
> 220 ietfa.amsl.com ESMTP Postfix
> EHLO example.com
> 250-ietfa.amsl.com
> 250-PIPELINING
> 250-SIZE 67108864
> 250-ETRN
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN

Recommended reading for AMSL:

    http://www.postfix.org/TLS_README.html#server_tls
    http://www.postfix.org/FORWARD_SECRECY_README.html#quick-start

Postfix 2.11.0 has been released.  If they are in a position to
build their own package, they should consider going with that.
Otherwise, they can upgrade at a later date, when their O/S vendor
makes an updated package available.

With 2.11 they get TLS session ticket support in the Postfix
SMTP server and DANE support in the Postfix SMTP client.

Best-practice configuration:

Postfix configured for opportunistic TLS or opportunistic DANE TLS
if >= 2.11.0:

    /etc/postfix/main.cf:
	# Server TLS
	smtpd_tls_security_level = may
	smtpd_tls_loglevel = 1
	smtpd_tls_cert_file = ${config_directory}/smtpd-chain.pem
	smtpd_tls_key_file = ${config_directory}/smtpd-key.pem
	smtpd_tls_dh1024_param_file ${config_directory}/dh2048.pem
	smtpd_tls_dh512_param_file ${config_directory}/dh512.pem

	# Client TLS: Postfix < 2.11
	smtp_tls_security_level = may
	smtpd_tls_loglevel = 1
	# In most cases do not configure a client certificate
	smtp_tls_cert_file = 
	smtp_tls_key_file =

	# Client TLS additions/changes for Postfix >= 2.11
	smtp_dns_support_level = dnssec
	smtp_tls_security_level = dane

For DANE security, a DNSSEC-validating recursive resolver is required
on the MTA machine, as the sole entry in:

  /etc/resolv.conf:
	domain amsl.com
	nameserver 127.0.0.1

-- 
	Viktor.

From viktor1dane@dukhovni.org  Thu Jan 16 19:42:00 2014
Return-Path: 
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 CFA021ADF0F for ; Thu, 16 Jan 2014 19:42:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Bh9KBl1t16Jm for ; Thu, 16 Jan 2014 19:41:57 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3FDF51ADEDC for ; Thu, 16 Jan 2014 19:41:56 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 73F012AB219; Fri, 17 Jan 2014 03:41:43 +0000 (UTC)
Date: Fri, 17 Jan 2014 03:41:43 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140117034143.GW2317@mournblade.imrryr.org>
References: <20140106224541.29552.83393.idtracker@ietfa.amsl.com>  <52CDFE5C.7020200@cs.tcd.ie> <1E3529DE-4611-4350-9982-74E7D2F9E023@ogud.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1E3529DE-4611-4350-9982-74E7D2F9E023@ogud.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-03.txt
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jan 2014 03:42:01 -0000

On Thu, Jan 16, 2014 at 03:49:43PM -0500, Olafur Gudmundsson wrote:

> > - s/confused as what/confused as to what/
> > - s/column with acronym/column with an acronym/
> > 
> Fixed 

While you're still taking fixes of this sort:

diff --git a/draft-ietf-dane-registry-acronyms-03.xml b/draft-ietf-dane-registry-acronyms-03.xml
index b75515a..27d1d66 100644
--- a/draft-ietf-dane-registry-acronyms-03.xml
+++ b/draft-ietf-dane-registry-acronyms-03.xml
@@ -38,9 +38,9 @@
       DANE
       
       
-	Experience has show that people get confused using the three
-	numeric fields the TLSA record. This document specifies
-	descriptive acronyms for the three numeric fields in the TLSA
+	Experience has shown that people get confused using the three
+	numeric fields in the TLSA record. This document specifies
+	descriptive acronyms for the three numeric fields in TLSA
 	records. 
 	  This document updates the format of the IANA registry created by RFC6698.
 	 
@@ -50,11 +50,12 @@
   
     
 
        During discussions on how to add DANE  
-	technology to new protocols/services people repeatedly have
-	got confused as what the numeric values stand for and even 
-	the order of the fields of a TLSA record.
-	This document updates the IANA registry definition for TLSA
-	record to add a column with acronym for each specified field, in order to reduce confusion. 
+	technology to new protocols/services people have repeatedly
+	been confused as what the numeric values stand for and even 
+	the order of the fields in a TLSA record.
+	This document updates the IANA registry definition of the TLSA
+	record to add a column with an acronym for each specified field, so
+	as to reduce confusion. 
 	This document does not change the DANE protocol in any way. 
        
       It is expected that DANE parsers in applications and DNS
@@ -168,8 +169,8 @@
       
 
 	
 	  Protocol FOO only allows
-	TLSA records using PKIX-EE and DANE-EE, with selector SPKI and
-	using SHA2-512. 
+	TLSA records using PKIX-EE(1) and DANE-EE(3), with selector SPKI(1) and
+	using SHA2-512(2). 
 
@@ -185,7 +186,7 @@
   
 
       Scott Schmit offered real good suggestions to decrease the 
 	possibility of confusion. Viktor Dukhovni provided comments
-	from expert point of view. Jim Schaad, Wes Hardaker and Paul
+	from an implementor's viewpoint. Jim Schaad, Wes Hardaker and Paul
 	Hoffman provided feedback during WGLC. 
       
   
 

-- 
	Viktor.

From viktor1dane@dukhovni.org  Thu Jan 16 22:26:17 2014
Return-Path: 
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 C3F191ADF85 for ; Thu, 16 Jan 2014 22:26:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 XF7nG3q9AD4L for ; Thu, 16 Jan 2014 22:26:15 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1C81ADF83 for ; Thu, 16 Jan 2014 22:26:15 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id C7F332AABCE; Fri, 17 Jan 2014 06:26:01 +0000 (UTC)
Date: Fri, 17 Jan 2014 06:26:01 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140117062601.GX2317@mournblade.imrryr.org>
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com> <52D81875.6050705@nist.gov> <20140116180810.GN2317@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140116180810.GN2317@mournblade.imrryr.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jan 2014 06:26:18 -0000

On Thu, Jan 16, 2014 at 06:08:10PM +0000, Viktor Dukhovni wrote:

> I'll strive to avoid publishing examples that are likely to fail
> interoperability tests.  For what it is worth, OpenSSL does not
> mind empty subject and issuer DNs even without a SAN extension, if
> the application layer does not object.  The DANE verification code
> I wrote on top of OpenSSL likewise does not object with usage
> DANE-EE(3).

My updated code for essentially anonymous self-signed certificates
now generates certificates with subject and issuer set to "CN=*",
in the hope that this will encounter less friction from strict
parsers.  The extra 24 useless octets in the DER encoding of the
certificate are not prohibitive:

issuer= /CN=*
notBefore=Jan 17 05:29:38 2014 GMT
notAfter=Jan 16 05:29:38 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
MIIBBTCBq6ADAgECAgEBMAoGCCqGSM49BAMCMAwxCjAIBgNVBAMMASowHhcNMTQw
MTE3MDUyOTM4WhcNMTQwMTE2MDUyOTM4WjAMMQowCAYDVQQDDAEqMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAEa3wTPD7Pnc0r5Jq5pwWVtOJMpDOGjfhPe3Ger2hr
r9XTMJt8gKo+qPbvokID/sqEmqf1cwh/VJtdiEaEw8f2uDAKBggqhkjOPQQDAgNJ
ADBGAiEAjTtBubyqCqIoOFArwZ/imA483U4+zSKZEgEFMTqqS9MCIQClkwwlavTu
mjagje1TSlDYuScRRstmZc9wp2bsmA1Ljg==
-----END CERTIFICATE-----

Yes I know that one can't yet field only an EC certificate even
for SMTP.  Many pre-DANE opportunistic TLS clients will have older
TLS implementations that don't support EC, but insist on a compatible
(i.e. RSA with SHA1) certificate which they promptly ignore.  The
requisite RSA-2048 certificate is ~400 octets longer:

issuer= /CN=*
notBefore=Jan 17 06:18:09 2014 GMT
notAfter=Jan 16 06:18:09 2014 GMT
subject= /CN=*
-----BEGIN CERTIFICATE-----
MIICkTCCAXmgAwIBAgIBATANBgkqhkiG9w0BAQUFADAMMQowCAYDVQQDDAEqMB4X
DTE0MDExNzA2MTgwOVoXDTE0MDExNjA2MTgwOVowDDEKMAgGA1UEAwwBKjCCASIw
DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAM60J1M9a5M8SB5kGvWuWSHgI9GV
lcUmufkjhBnN7lUSEgCKjIPWolnH/4JhoIrmMyqtbLAXEbkt64LcvVE2QQxY625S
/om7JJTb/VO3OmY/ae8hWWtgkaBlprg5YDHSGPdCdMLqKb1cjyUYbWzjHZ/vXDGF
tWhA/oW1tEBOVXDvyNJITF22epk3U6SORqOCkKixWQ4W/yKc4wH1ybFtfpdZxPPy
rx+0arWHaw5fbf82D3f55Ox9f+a7AZDKkce32ONqEruGhyTG6m6DHlbzdiiEc6xc
Fklomr8xn+jyf/jyi5YpzylFPBZiF11GVHPMYIUEFscnbLXyvKA88Ud3h9cCAwEA
ATANBgkqhkiG9w0BAQUFAAOCAQEAVu8qwguTCyMQ2rIYVZQvQTY+XYJZxUkwI2RS
4RfTqyJVina9Bi+o2iueWA5dTAqthWMpt0n4XVCuZlrcg82ZP5sJYwIs2FUX9Syk
gRFMG3TtHfrRoFrxylD+qjNdb74vZb1JtLSo4eqnEFUUMpYm3YvocoCkuJJrfsyF
TD2Tjj9Kv/rYMiRUFUU/NwK1+i49OI70L+Lr5nOwE/jxSjLpHUzsdhPGt4Rw7cNs
Eo5yX33tSShARTGFHW8SHZicMBQjbOTEVFslaCFv+qFH10n8W8PZ5romFbyqx9DD
VLlFSW+/4dXJDIFG8F27xWV3kl6Hi+zn49IoTHV7tWB2YtDXkg==
-----END CERTIFICATE-----

With DANE it will finally be practical to field multiple certificates,
one an with an RSA key, for clients that don't support ECDSA, and
another with an ECDSA key for those that do.  The TLSA RRset can
then list both digests.

-- 
	Viktor.

From viktor1dane@dukhovni.org  Thu Jan 16 22:59:57 2014
Return-Path: 
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 DB2111ADF96 for ; Thu, 16 Jan 2014 22:59:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 Ijf2pVhuYwbF for ; Thu, 16 Jan 2014 22:59:56 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id E0E9B1ADF93 for ; Thu, 16 Jan 2014 22:59:55 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id A9DFE2AABCE; Fri, 17 Jan 2014 06:59:42 +0000 (UTC)
Date: Fri, 17 Jan 2014 06:59:42 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140117065942.GY2317@mournblade.imrryr.org>
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <52D80CC4.9020407@bbn.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jan 2014 06:59:58 -0000

On Thu, Jan 16, 2014 at 11:45:56AM -0500, Stephen Kent wrote:

> Martin is correct. This is not well-formed cert as per RFC 5280:
> 
> 4.1.2.4.Issuer
> The issuer field identifies the entity that has signed and issued the
> certificate.The issuer field MUST contain a non-empty distinguished
> name (DN)
>
> [...]
>
> We issued 5280bis in part to accommodate DANE's use of ss certs.
> Please don't provide examples that are obviously non-complaint relative
> to basic PKIX and X.509 specs.

Are you referring to RFC 6818?  If so, what is the impact of Section
2 of that document?

    2.  Update to RFC 5280, Section 3.2: "Certification Paths and Trust"

       Add the following paragraph to the end of RFC 5280, Section 3.2:

    | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
    | that use of self-issued certificates and self-signed certificates
    | issued by entities other than CAs are outside the scope of this
    | specification.  Thus, for example, a web server or client might
    | generate a self-signed certificate to identify itself.  These
    | certificates and how a relying party uses them to authenticate
    | asserted identities are both outside the scope of RFC 5280.

If a self-signed EE (i.e. not a CA) certificate is outside the
scope of 5280, it might seem that the issuer constraint of 5280
need not apply.

This does not mean that it is a good idea to push one's luck, but
I am curious as to whether the 5280 constraints in this thread are
or are not in scope for self-signed EE certificates?

It is perhaps the case that the question of whether a certificate
is self-issued or not is not well-formed when both the issuer and
subject fields are empty?

-- 
	Viktor.

From mrex@sap.com  Fri Jan 17 14:50:35 2014
Return-Path: 
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 9FE9F1AD7BE for ; Fri, 17 Jan 2014 14:50:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.952
X-Spam-Level: 
X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 lBOh9eEqUHsL for ; Fri, 17 Jan 2014 14:50:33 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5144A1AD6B9 for ; Fri, 17 Jan 2014 14:50:33 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0HMoJbI002767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 17 Jan 2014 23:50:19 +0100 (MET)
In-Reply-To: <20140117065942.GY2317@mournblade.imrryr.org>
To: dane@ietf.org
Date: Fri, 17 Jan 2014 23:50:19 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140117225019.5E33E1ABB3@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 17 Jan 2014 22:50:35 -0000

Viktor Dukhovni wrote:
> On Thu, Jan 16, 2014 at 11:45:56AM -0500, Stephen Kent wrote:
> 
> > Martin is correct. This is not well-formed cert as per RFC 5280:
> > 
> > 4.1.2.4.Issuer
> > The issuer field identifies the entity that has signed and issued the
> > certificate.The issuer field MUST contain a non-empty distinguished
> > name (DN)
> >
> > [...]
> >
> > We issued 5280bis in part to accommodate DANE's use of ss certs.
> > Please don't provide examples that are obviously non-complaint relative
> > to basic PKIX and X.509 specs.
> 
> Are you referring to RFC 6818?  If so, what is the impact of Section
> 2 of that document?
> 
>     2.  Update to RFC 5280, Section 3.2: "Certification Paths and Trust"
> 
>        Add the following paragraph to the end of RFC 5280, Section 3.2:
> 
>     | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
>     | that use of self-issued certificates and self-signed certificates
>     | issued by entities other than CAs are outside the scope of this
>     | specification.  Thus, for example, a web server or client might
>     | generate a self-signed certificate to identify itself.  These
>     | certificates and how a relying party uses them to authenticate
>     | asserted identities are both outside the scope of RFC 5280.
> 
> If a self-signed EE (i.e. not a CA) certificate is outside the
> scope of 5280, it might seem that the issuer constraint of 5280
> need not apply.

I think you're misinterpreting this.

TLS typically comes with an software module for processing X.509
certificates that is (supposed to) follow either ITU-T X.509 or PKIX or both,
and TLS is going to be used for processing PKIX-conforming certificates
and certification pathes for quite some time to come.

The idea of DANE's use of X.509 was not to come up with a different
and incompatible interpretation of what and what not is a well-formed
X.509 certificate.  The intention (at least for some of those involved)
of DANE was to standardize a use of X.509 certificate and
certificate path validation for authentication of communication peers
as an alternative to what X.509/PKIX specifies.

Historically, how X.509 certificates that are issued by an entity
other than a CA are used by relying parties to authenticate peer
is outside of the scope of PKIX (rfc5280) essentially means, that
the exact behaviour is implementation-defined.

But when you start feeding X.509 certificates to a PKIX implementation
that are non-compliant with X.509/PKIX at the PDU level, rather than
differing only in the semantics of how to verify authenticity of
the certificate or cerification path), then you are squarely in
territory of undefined behaviour.


> 
> This does not mean that it is a good idea to push one's luck, but
> I am curious as to whether the 5280 constraints in this thread are
> or are not in scope for self-signed EE certificates?
> 
> It is perhaps the case that the question of whether a certificate
> is self-issued or not is not well-formed when both the issuer and
> subject fields are empty?


Doing stuff that is in obvious conflict with X.509 and/or PKIX is
almost unconditionally a bad idea, because it may require
modifying existing code to tolerate bogus information, which may
create/open new vulnerabilities and will result in interop problems.

There are a number of things that PKIX/rfc5280 has declared out-of-scope
(i.e. left to implementations, resulting in implementation-defined
behaviour).  One example is the presence and honoring of attributes
beyond the public key and the associated name(s) in so called
"trust anchors", in case trust anchors are distributed as X.509
certificates with attributes in them.  Some PKIX implementations will
honor (enforce) the notbefore/notafter of TrustAnchors, some may
ignore it.  Neither is PKIX-incompliant.

Your example populated the "notbefore" and "notafter" members with
conflicting values (i.e. notafter>notbefore).  This may needlessly
create a problem with implementations that check notbefore/notafter
even for trust anchors.


If you at your example with empty issuer from a programmers/API perspective
there are other potential problems.  X.509 has traditionally guaranteed
that an X.509 certificate can be (uniquely) identified by the pair
(issuer-name/serial number).  So some APIs that manage stores for certs
may be using issuer&serial as a handle to store or retrieve certs,
and the lack of an issuer name may represent an invalid function parameter
to such an API.


My recommendation is to avoid using obviously bogus examples of X.509
certificates when illustrating the use of DANE, because that is going
to cause unnecessary pain and confusion among users and implementors.


-Martin

From mrex@sap.com  Fri Jan 17 16:14:41 2014
Return-Path: 
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 99EDD1AD8EF for ; Fri, 17 Jan 2014 16:14:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.552
X-Spam-Level: 
X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-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 J4rbCAAxlqxr for ; Fri, 17 Jan 2014 16:14:39 -0800 (PST)
Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 862BA1AD8ED for ; Fri, 17 Jan 2014 16:14:38 -0800 (PST)
Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id s0I0EPR3010001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sat, 18 Jan 2014 01:14:25 +0100 (MET)
In-Reply-To: <20140117225019.5E33E1ABB3@ld9781.wdf.sap.corp>
To: mrex@sap.com
Date: Sat, 18 Jan 2014 01:14:25 +0100 (CET)
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20140118001425.65FBF1ABB3@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
X-SAP: out
Cc: dane@ietf.org
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: mrex@sap.com
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jan 2014 00:14:41 -0000

Martin Rex wrote:
> 
> Your example populated the "notbefore" and "notafter" members with
> conflicting values (i.e. notafter>notbefore).  This may needlessly
> create a problem with implementations that check notbefore/notafter
> even for trust anchors.

Ooops, typo, I meant (notbefore>notafter) is bogus:

>
> issuer= /CN=*
> notBefore=Jan 17 06:18:09 2014 GMT
> notAfter=Jan 16 06:18:09 2014 GMT
> subject= /CN=*

When I've been creating self-signed certs in the past,
then with "notBefore" set to "now minus 24hours" and
"notAfter" set to Jan 1, 2038.  The latter to reduce potential
interop problems with older 32-bit PKIX implementations that may
try to convert the date into a 32-bit time_t value on ASN.1 decode.

One of these days I will have to change the code to use
a notafter "Dec 1, 2049" (so that it still encodes as UTCTime rather
than GeneralizedTime), and maybe in 10 years it will be safe to
use a value like "Dec 1, 2999".

-Martin

PS: if anyone is wondering why the "year 3000" avoidance:
    I'm just trying to be conservative in what I send out, and I've
    encountered one platform where the vendor decided that a C89
    program which passes a (64-bit) time_t that represents a date
    after 23:59:59, December 31, 3000 to some of the C89 time-related
    functions such as gmtime() should be crashed (i.e. fatally terminated)
    rather than see the behaviour described in the C89 specification.

From viktor1dane@dukhovni.org  Fri Jan 17 19:21:35 2014
Return-Path: 
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 8BF651AD83F for ; Fri, 17 Jan 2014 19:21:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 H3km93OADg0G for ; Fri, 17 Jan 2014 19:21:32 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id 7FB9B1AD791 for ; Fri, 17 Jan 2014 19:21:32 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5D1CD2AB21F; Sat, 18 Jan 2014 03:21:18 +0000 (UTC)
Date: Sat, 18 Jan 2014 03:21:18 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140118032118.GE2317@mournblade.imrryr.org>
References: <20140117225019.5E33E1ABB3@ld9781.wdf.sap.corp> <20140118001425.65FBF1ABB3@ld9781.wdf.sap.corp>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140118001425.65FBF1ABB3@ld9781.wdf.sap.corp>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 18 Jan 2014 03:21:35 -0000

On Sat, Jan 18, 2014 at 01:14:25AM +0100, Martin Rex wrote:

> Ooops, typo, I meant (notbefore>notafter) is bogus:

My example is not intended to suggest best-practice server certificate
settings, rather it is intended to emphasize DANE client requirements.
Servers should not push their luck, but, with usage DANE-EE(3),
clients should to the extent possible accept any certificate that
matches the TLSA record, regardless of certificate details.

Sometimes extreme settings that are not recommended in practice
can best serve to make a point.  So I don't disagree with you in
fact.  The certificate I posted makes my answer to original question
in this thread as clear as possible.

-- 
	Viktor.

From dromasca@avaya.com  Sun Jan 19 00:39:36 2014
Return-Path: 
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 940621AC404; Sun, 19 Jan 2014 00:39:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.137
X-Spam-Level: 
X-Spam-Status: No, score=-3.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.538] 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 QE-8s6JCaZih; Sun, 19 Jan 2014 00:39:34 -0800 (PST)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6831A1F7B; Sun, 19 Jan 2014 00:39:33 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AqUOAP+N21LGmAcV/2dsb2JhbABZgkcjIThWpigDjDqIUYEGFnSCJQEBAQEDEhtMEAIBBgINAQMDAQEBCx0HMhQJCAIEDgUIARmHYwEMi3WRMKZoF40OgUAgEQYBgySBFASZVIU9iymDLYIq
X-IronPort-AV: E=Sophos;i="4.95,684,1384318800"; d="scan'208,217";a="39547489"
Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Jan 2014 03:39:18 -0500
Received: from unknown (HELO AZ-FFEXHC04.global.avaya.com) ([135.64.58.14]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES128-SHA; 19 Jan 2014 03:29:21 -0500
Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC04.global.avaya.com ([135.64.58.14]) with mapi id 14.03.0158.001; Sun, 19 Jan 2014 09:39:15 +0100
From: "Romascanu, Dan (Dan)" 
To: Olafur Gudmundsson 
Thread-Topic: [dane] Gen-ART Review of draft-ietf-dane-registry-acronyms-03
Thread-Index: AQHPEvv5AiogVuwlM0a8So6zPE/EZZqLvbyw
Date: Sun, 19 Jan 2014 08:39:14 +0000
Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA243D0ED9@AZ-FFEXMB04.global.avaya.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA243CEC9A@AZ-FFEXMB04.global.avaya.com> <08A37247-FE33-4FC4-B56D-9925957D8920@ogud.com>
In-Reply-To: <08A37247-FE33-4FC4-B56D-9925957D8920@ogud.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [135.64.58.46]
Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA243D0ED9AZFFEXMB04globa_"
MIME-Version: 1.0
Cc: "gen-art@ietf.org" , "draft-ietf-dane-registry-acronyms.all@tools.ietf.org" , "dane@ietf.org" 
Subject: Re: [dane] Gen-ART Review of draft-ietf-dane-registry-acronyms-03
X-BeenThere: dane@ietf.org
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: Sun, 19 Jan 2014 08:39:36 -0000

--_000_9904FB1B0159DA42B0B887B7FA8119CA243D0ED9AZFFEXMB04globa_
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Looks good, thank you for addressing my comments.

Regards,

Dan


From: Olafur Gudmundsson [mailto:ogud@ogud.com]
Sent: =E9=E5=ED =E4 16 =E9=F0=E5=E0=F8 2014 22:46
To: Romascanu, Dan (Dan)
Cc: gen-art@ietf.org; draft-ietf-dane-registry-acronyms.all@tools.ietf.org;=
 dane@ietf.org
Subject: Re: [dane] Gen-ART Review of draft-ietf-dane-registry-acronyms-03


On Jan 15, 2014, at 10:11 AM, "Romascanu, Dan (Dan)" > wrote:


I am the assigned Gen-ART reviewer for this draft. For background on Gen-AR=
T, please see the FAQ at

.

Please resolve these comments along with any other Last Call comments you m=
ay receive.

Document: http://www.ietf.org/id/draft-ietf-dane-registry-acronyms-03.txt
Reviewer: Dan Romascanu
Review Date: 1/15/2014
IETF LC End Date: 1/23/2014
IESG Telechat date:

Summary:
Ready with issues

Major issues:
None =96 it=92s a simple, clear and useful document.

thanks



Minor issues:
1.       In Section 2.3 the I-D recommends that the values in reference col=
umn for SHA-256 and SHA-512 refer to [RFC 6698] while the IANA Consideratio=
ns section in RFC 6698 recommends and the registry entries in the TLSA Matc=
hing Types table athttp://www.iana.org/assignments/dane-parameters/dane-par=
ameters.xhtml  point to [RFC 6234].

Good Catch, fixed


2.       As this I-D updates the registries with a column for acronyms, it =
seems more accurate that the reference columns of all tables mention both  =
[RFC 6698] and [RFC XXXX] (this RFC)

I'm not sure if I agree, all this document does is to change the format of =
the registries it is not the definitions of any table entry.
But I think it would be good to change the reference for each of the regist=
ries to point to both RFC6698 and RFCXXXX

I propose adding to each registry sections the following text:
        "Update reference for this registry to include both [RFC6698] and [=
RFC-this-document]"


Nits/editorial comments:
In the Introduction section:

=91This document updates the IANA registry definition for TLSA
   record to add a column with acronym for each specified field=92
s/acronym/an acronym/


Fixed

thanks

          Olafur


--_000_9904FB1B0159DA42B0B887B7FA8119CA243D0ED9AZFFEXMB04globa_
Content-Type: text/html; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable











Looks good, thank you for=
 addressing my comments.



 <=
/p>

Regards,


 <=
/p>

Dan


 <=
/p>

 <=
/p>







From: Olafur G=
udmundsson [mailto:ogud@ogud.com]


Sent: =E9=E5=ED =E4 16
=E9=F0=E5=E0=F8 2014 22:46

To: Romascanu, Dan (Dan)

Cc: gen-art@ietf.org; draft-ietf-dane-registry-acronyms.all@tools.ie=
tf.org; dane@ietf.org

Subject: Re: [dane] Gen-ART Review of draft-ietf-dane-registry-acron=
yms-03






 


 






On Jan 15, 2014, at 10:11 AM, "Romascanu, Dan (=
Dan)" <dromasca@avaya.com=
> wrote:















I am the assigned Gen-ART reviewer for =
this draft. For background on Gen-ART, please see the FAQ at






 







 






Please resolve these comments along wit=
h any other Last Call comments you may receive.






 







Reviewer: Dan Romascanu






Review Date: 1/15/2014






IETF LC End Date: 1/23/2014<=
/span>






IESG Telechat date:





 






Summary:






Ready with issues






 






Major issues:






None =96 it=92s a simple, clear and use=
ful document.








 




thanks 

















 






Minor issues:






1.=
       In
 Section 2.3 the I-D recommends that the values in reference column for SHA=
-256 and SHA-512 refer to [RFC 6698] while the IANA Considerations section =
in RFC 6698 recommends and the registry entries in the TLSA Matching Types =
table athttp://www.iana.org/assignments=
/dane-parameters/dane-parameters.xhtml  point
 to [RFC 6234].








 




Good Catch, fixed 

















2.=
       As
 this I-D updates the registries with a column for acronyms, it seems more =
accurate that the reference columns of all tables mention both  [RFC 6=
698] and [RFC XXXX] (this RFC)








 




I'm not sure if I agree, all this document does is t=
o change the format of the registries it is not the definitions of any tabl=
e entry. 






But I think it would be good to change the reference=
 for each of the registries to point to both RFC6698 and RFCXXXX =







 






I propose adding to each registry sections the follo=
wing text: 








        "Update reference f=
or this registry to include both [RFC6698] and [RFC-this-document]&quo=
t;






 














 






Nits/editorial comments:






In the Introduction section:=





=91This document updates the IANA registry definition for TLSA




   record to add a column with acronym for=
 each specified field=92






s/acronym/an acronym/=







 










 




Fixed 






 






thanks 






 






   &nb=
sp;      Olafur






 










--_000_9904FB1B0159DA42B0B887B7FA8119CA243D0ED9AZFFEXMB04globa_--

From kent@bbn.com  Mon Jan 20 06:47:17 2014
Return-Path: 
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 7B6B81A0175 for ; Mon, 20 Jan 2014 06:47:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.036
X-Spam-Level: 
X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 5Eyn-Ju37lYx for ; Mon, 20 Jan 2014 06:47:15 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id C990B1A015C for ; Mon, 20 Jan 2014 06:47:15 -0800 (PST)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54452) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W5G8B-000NsC-Io for dane@ietf.org; Mon, 20 Jan 2014 09:47:15 -0500
Message-ID: <52DD36F5.9090608@bbn.com>
Date: Mon, 20 Jan 2014 09:47:17 -0500
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dane@ietf.org
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com> <52D81875.6050705@nist.gov> <20140116180810.GN2317@mournblade.imrryr.org>
In-Reply-To: <20140116180810.GN2317@mournblade.imrryr.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
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: Mon, 20 Jan 2014 14:47:17 -0000

Viktor,

> On Thu, Jan 16, 2014 at 12:35:49PM -0500, Stephen Nightingale wrote:
>
>> Granted the cert even for Cert Use DANE-EE(3) must be well-formed in
>> order to see what's in it.
>>
>> But I believe Victor's main point is that the only field *value*
>> that matters for DANE-EE(3) is the Public Key.  Issuer, Common Name
>> and SubjectAltName are just deckchairs.
> Correct, the point is that DANE verification makes no use of these values,
> if however underlying libraries are likely to object, certificates like
> this should perhaps be avoided.  Note however, that this means that a
> certificate with an empty subject DN can never be self-signed.
yep.
> I'll strive to avoid publishing examples that are likely to fail
> interoperability tests.  For what it is worth, OpenSSL does not
> mind empty subject and issuer DNs even without a SAN extension, if
> the application layer does not object.  The DANE verification code
> I wrote on top of OpenSSL likewise does not object with usage
> DANE-EE(3).
OpenSSL is a collection of libraries which do not represent a
reference implementation of 5280 or X.509 standards.
> So my instructions to users will have to suggest something like:
>
> 	openssl req ... -subj "/CN=?"
>
> for self signed certificates that are intended solely for DANE-EE(3) use.
>
Using the question mark seems OK, better than an asterisk, which might
be interpreted by some as a widlcard.

Steve

From kent@bbn.com  Mon Jan 20 06:51:06 2014
Return-Path: 
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 E40BC1A018B for ; Mon, 20 Jan 2014 06:51:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.036
X-Spam-Level: 
X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.535, 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 esOpH6r_Mw3D for ; Mon, 20 Jan 2014 06:51:05 -0800 (PST)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by ietfa.amsl.com (Postfix) with ESMTP id 47C2E1A0186 for ; Mon, 20 Jan 2014 06:51:05 -0800 (PST)
Received: from dhcp89-089-218.bbn.com ([128.89.89.218]:54454) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1W5GBt-000Nu1-Cn for dane@ietf.org; Mon, 20 Jan 2014 09:51:05 -0500
Message-ID: <52DD37DB.5050309@bbn.com>
Date: Mon, 20 Jan 2014 09:51:07 -0500
From: Stephen Kent 
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: dane@ietf.org
References: <20140116151959.4AA021ABB0@ld9781.wdf.sap.corp> <52D80CC4.9020407@bbn.com> <20140117065942.GY2317@mournblade.imrryr.org>
In-Reply-To: <20140117065942.GY2317@mournblade.imrryr.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] "Name Checks are not appropriate for CU=3"
X-BeenThere: dane@ietf.org
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: Mon, 20 Jan 2014 14:51:07 -0000

Viktor,

> On Thu, Jan 16, 2014 at 11:45:56AM -0500, Stephen Kent wrote:
>
>> Martin is correct. This is not well-formed cert as per RFC 5280:
>>
>> 4.1.2.4.Issuer
>> The issuer field identifies the entity that has signed and issued the
>> certificate.The issuer field MUST contain a non-empty distinguished
>> name (DN)
>>
>> [...]
>>
>> We issued 5280bis in part to accommodate DANE's use of ss certs.
>> Please don't provide examples that are obviously non-complaint relative
>> to basic PKIX and X.509 specs.
> Are you referring to RFC 6818?  If so, what is the impact of Section
> 2 of that document?
>
>      2.  Update to RFC 5280, Section 3.2: "Certification Paths and Trust"
>
>         Add the following paragraph to the end of RFC 5280, Section 3.2:
>
>      | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509], we note
>      | that use of self-issued certificates and self-signed certificates
>      | issued by entities other than CAs are outside the scope of this
>      | specification.  Thus, for example, a web server or client might
>      | generate a self-signed certificate to identify itself.  These
>      | certificates and how a relying party uses them to authenticate
>      | asserted identities are both outside the scope of RFC 5280.
>
> If a self-signed EE (i.e. not a CA) certificate is outside the
> scope of 5280, it might seem that the issuer constraint of 5280
> need not apply.
The wording here was a carefully crafted compromise to deal with the
reality of ss certs vs. the X.509 and 5280 rejection of them. You could
interpret the text to say that anything goes, but violating the basic
format requirements of 5280 and its predecessors) and X.509 strikes me
as a bad mashup.
> This does not mean that it is a good idea to push one's luck, but
> I am curious as to whether the 5280 constraints in this thread are
> or are not in scope for self-signed EE certificates?
>
> It is perhaps the case that the question of whether a certificate
> is self-issued or not is not well-formed when both the issuer and
> subject fields are empty?
Self-issued is not the same same self signed, although the fine
distinction is probably not worth the list's attention.

Steve


From ogud@ogud.com  Tue Jan 21 16:56:43 2014
Return-Path: 
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 779F91A0229 for ; Tue, 21 Jan 2014 16:56:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 uLlkyGi0PoaC for ; Tue, 21 Jan 2014 16:56:41 -0800 (PST)
Received: from smtp68.ord1c.emailsrvr.com (smtp68.ord1c.emailsrvr.com [108.166.43.68]) by ietfa.amsl.com (Postfix) with ESMTP id 63DEA1A01BC for ; Tue, 21 Jan 2014 16:56:40 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id 3EAF3148971 for ; Tue, 21 Jan 2014 19:56:40 -0500 (EST)
X-Virus-Scanned: OK
Received: by smtp1.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 0B92B1489D3 for ; Tue, 21 Jan 2014 19:56:39 -0500 (EST)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Olafur Gudmundsson 
In-Reply-To: <20140117034143.GW2317@mournblade.imrryr.org>
Date: Tue, 21 Jan 2014 19:56:43 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <044CFABE-DD7A-4E82-A62D-580C0F49A8F2@ogud.com>
References: <20140106224541.29552.83393.idtracker@ietfa.amsl.com>  <52CDFE5C.7020200@cs.tcd.ie> <1E3529DE-4611-4350-9982-74E7D2F9E023@ogud.com> <20140117034143.GW2317@mournblade.imrryr.org>
To: dane@ietf.org
X-Mailer: Apple Mail (2.1510)
Subject: Re: [dane] I-D Action: draft-ietf-dane-registry-acronyms-03.txt
X-BeenThere: dane@ietf.org
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, 22 Jan 2014 00:56:43 -0000

Viktor,=20

On Jan 16, 2014, at 10:41 PM, Viktor Dukhovni  =
wrote:

> On Thu, Jan 16, 2014 at 03:49:43PM -0500, Olafur Gudmundsson wrote:
>=20
>>> - s/confused as what/confused as to what/
>>> - s/column with acronym/column with an acronym/
>>>=20
>> Fixed=20
>=20
> While you're still taking fixes of this sort:
>=20
> diff --git a/draft-ietf-dane-registry-acronyms-03.xml =
b/draft-ietf-dane-registry-acronyms-03.xml
> index b75515a..27d1d66 100644
> --- a/draft-ietf-dane-registry-acronyms-03.xml
> +++ b/draft-ietf-dane-registry-acronyms-03.xml
> @@ -38,9 +38,9 @@
>       DANE
>=20
>       
> -	Experience has show that people get confused using the three
> -	numeric fields the TLSA record. This document specifies
> -	descriptive acronyms for the three numeric fields in the TLSA
> +	Experience has shown that people get confused using the three
> +	numeric fields in the TLSA record. This document specifies
> +	descriptive acronyms for the three numeric fields in TLSA
> 	records.=20
> 	  This document updates the format of the IANA registry created =
by RFC6698.
> 	=20

This looks good I will propose that we apply it, before the document =
pops out as an RFC.=20

> @@ -50,11 +50,12 @@
>   
>     
=20
>        During discussions on how to add DANE =20
> -	technology to new protocols/services people repeatedly have
> -	got confused as what the numeric values stand for and even=20
> -	the order of the fields of a TLSA record.
> -	This document updates the IANA registry definition for TLSA
> -	record to add a column with acronym for each specified field, in =
order to reduce confusion.=20
> +	technology to new protocols/services people have repeatedly
> +	been confused as what the numeric values stand for and even=20
> +	the order of the fields in a TLSA record.
> +	This document updates the IANA registry definition of the TLSA
> +	record to add a column with an acronym for each specified field, =
so
> +	as to reduce confusion.=20
> 	This document does not change the DANE protocol in any way.=20
>       =20
>       It is expected that DANE parsers in applications and DNS

Same here,=20

> @@ -168,8 +169,8 @@
>       
=20
> 	
> 	  Protocol FOO only allows
> -	TLSA records using PKIX-EE and DANE-EE, with selector SPKI and
> -	using SHA2-512. 
> +	TLSA records using PKIX-EE(1) and DANE-EE(3), with selector =
SPKI(1) and
> +	using SHA2-512(2). 
> 

Much better=20
> @@ -185,7 +186,7 @@
>   
=20
>       Scott Schmit offered real good suggestions to decrease the=20
> 	possibility of confusion. Viktor Dukhovni provided comments
> -	from expert point of view. Jim Schaad, Wes Hardaker and Paul
> +	from an implementor's viewpoint. Jim Schaad, Wes Hardaker and =
Paul
> 	Hoffman provided feedback during WGLC.=20
>       
>   
=20
> --=20


Same here=20
> 	Viktor.

Thanks for suggestions.=20

	Olafur

> _______________________________________________
> dane mailing list
> dane@ietf.org
> https://www.ietf.org/mailman/listinfo/dane


From warren@kumari.net  Wed Jan 22 11:26:31 2014
Return-Path: 
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 7E0BA1A02C5 for ; Wed, 22 Jan 2014 11:26:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level: 
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 lLU2IttOr4r6 for ; Wed, 22 Jan 2014 11:26:29 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2FB1A02B4 for ; Wed, 22 Jan 2014 11:26:28 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id hr1so1024433wib.12 for ; Wed, 22 Jan 2014 11:26:28 -0800 (PST)
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:content-type; bh=zmgPkfkzSAY9tWsAb7yJcxixENrn6QBIfWRTp8Zb1so=; b=NQGoGi31QxGR2RA44ShTJBkxo8AlEhIC5vW868nyTmXwqWSkbr2hpsqUEzXvwAbWDs ldaIHeQ+n8gMP3ad6265jqP5FX+1QHg0wGVOyoHOjXdnD72f9l+Xg2dxnRcUerHu9pC2 GaQZm6fQaVpVoW4Yhy5knBp3bEb7LwU9MAGGsMwMIhYWdmBpwSZq3Y+nV26KoduMyf9u lruxdqGE+EYrPoDkpSewz1P67yG5hZSsumtAKC+JwRQyKw3xyB31zREWyawBBSVXAYIi WHH0RF+PukTA4Y2ftBuJ3NdAvlYv7VV9H0yoh7kt8gQF5ReuQisTZ3HX28IQfk2QCNLf hEnA==
X-Gm-Message-State: ALoCoQkPJq70c5u5eeZ1dqGdZ5HY4BqKCxxQT86KqkXWtxs7jBShLQ8kevfVj/+9RBvQbQ071A2B
MIME-Version: 1.0
X-Received: by 10.180.207.10 with SMTP id ls10mr21421396wic.52.1390418787931;  Wed, 22 Jan 2014 11:26:27 -0800 (PST)
Received: by 10.194.54.167 with HTTP; Wed, 22 Jan 2014 11:26:27 -0800 (PST)
X-Originating-IP: [98.244.98.35]
In-Reply-To: 
References: 
Date: Wed, 22 Jan 2014 14:26:27 -0500
Message-ID: 
From: Warren Kumari 
To: dane@ietf.org
Content-Type: text/plain; charset=ISO-8859-1
Subject: Re: [dane] Meeting at IETF89 (London).
X-BeenThere: dane@ietf.org
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, 22 Jan 2014 19:26:31 -0000

And more than a quarter of our slot is already spoken for -- please
remember to ask early if you'd like some agenda time.

W


On Thu, Jan 16, 2014 at 10:58 AM, Warren Kumari  wrote:
> Hi all,
>
> We have requested a 2 hour DNAE session in London.
>
> It has been a while since we met -- please get your agenda requests in...
> Preference is given to already discussed drafts, things that need face
> to face time, etc.
>
>
>
> A very quick update on the DANE for IETF mail situation:
> The IETF mail servers still do not do STARTTLS. AMS is short staffed
> at the moment, and is prioritizing mission critical things first.
> Hopefully they will manage to get this done in January -- once that is
> done, adding the TLSA record (and updating the documentation!) should
> be (hopefully) quick and easy...
>
> W
>
>
> wkumari:~$ dig +short +nocomment MX ietf.org
> 0 mail.ietf.org.
> wkumari@vimes:~$ telnet mail.ietf.org 25
> Trying 2001:1900:3001:11::2c...
> Connected to mail.ietf.org.
> Escape character is '^]'.
> 220 ietfa.amsl.com ESMTP Postfix
> EHLO example.com
> 250-ietfa.amsl.com
> 250-PIPELINING
> 250-SIZE 67108864
> 250-ETRN
> 250-AUTH PLAIN LOGIN
> 250-AUTH=PLAIN LOGIN
> 250-ENHANCEDSTATUSCODES
> 250-8BITMIME
> 250 DSN
> STARTTLS
> 502 5.5.1 Error: command not implemented
> quit
> 221 2.0.0 Bye
> Connection closed by foreign host.

From stpeter@stpeter.im  Wed Jan 22 11:44:27 2014
Return-Path: 
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 3CA621A03B6 for ; Wed, 22 Jan 2014 11:44:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.437
X-Spam-Level: 
X-Spam-Status: No, score=-2.437 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535, SPF_HELO_PASS=-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 hSRPY9o8V_g0 for ; Wed, 22 Jan 2014 11:44:24 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 6393A1A0159 for ; Wed, 22 Jan 2014 11:43:44 -0800 (PST)
Received: from [192.168.1.6] (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 9571740067; Wed, 22 Jan 2014 12:43:43 -0700 (MST)
Message-ID: <52E01F6E.7000400@stpeter.im>
Date: Wed, 22 Jan 2014 12:43:42 -0700
From: Peter Saint-Andre 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0
MIME-Version: 1.0
To: dane@ietf.org
References:  
In-Reply-To: 
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [dane] Meeting at IETF89 (London).
X-BeenThere: dane@ietf.org
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, 22 Jan 2014 19:44:27 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Although Matt Miller and I haven't had much time to work on the SRV
I-D of late, it would be good to spend perhaps 10-15 minutes to
discuss it at the London session. We'll sure have an update by then.

On 01/22/2014 12:26 PM, Warren Kumari wrote:
> And more than a quarter of our slot is already spoken for --
> please remember to ask early if you'd like some agenda time.
> 
> W
> 
> 
> On Thu, Jan 16, 2014 at 10:58 AM, Warren Kumari 
> wrote:
>> Hi all,
>> 
>> We have requested a 2 hour DNAE session in London.
>> 
>> It has been a while since we met -- please get your agenda
>> requests in... Preference is given to already discussed drafts,
>> things that need face to face time, etc.
>> 
>> 
>> 
>> A very quick update on the DANE for IETF mail situation: The IETF
>> mail servers still do not do STARTTLS. AMS is short staffed at
>> the moment, and is prioritizing mission critical things first. 
>> Hopefully they will manage to get this done in January -- once
>> that is done, adding the TLSA record (and updating the
>> documentation!) should be (hopefully) quick and easy...
>> 
>> W
>> 
>> 
>> wkumari:~$ dig +short +nocomment MX ietf.org 0 mail.ietf.org. 
>> wkumari@vimes:~$ telnet mail.ietf.org 25 Trying
>> 2001:1900:3001:11::2c... Connected to mail.ietf.org. Escape
>> character is '^]'. 220 ietfa.amsl.com ESMTP Postfix EHLO
>> example.com 250-ietfa.amsl.com 250-PIPELINING 250-SIZE 67108864 
>> 250-ETRN 250-AUTH PLAIN LOGIN 250-AUTH=PLAIN LOGIN 
>> 250-ENHANCEDSTATUSCODES 250-8BITMIME 250 DSN STARTTLS 502 5.5.1
>> Error: command not implemented quit 221 2.0.0 Bye Connection
>> closed by foreign host.
> _______________________________________________ dane mailing list 
> dane@ietf.org https://www.ietf.org/mailman/listinfo/dane
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJS4B9uAAoJEOoGpJErxa2pBVQP/A1aZTD7qu0Ri01jlo2IPIso
yN/Cp0BO2jH8nJnXFQZjfUTsaj2dmcsYO+v59IZl4e6uBr+9S/GtC9KL8cKvePHp
aGX3c0DYuQ+I4FHlqddyed0B3sWfIKXc0flSDiNujDz3wa/o2wGGTAEahJ/SlRI9
n5dU1o1ItCTA3vdEPhBa6BHNBDA9YnMrvTD9MXTGJv7n6LgbdjrcG+wdCNnIHk6M
APgGhlwr3BDhCfgjZV8hLbLGXoJ91X9XJwn5vZBwpcNb/mRAh4uqfTatkhK9z4tX
JwD0Ybg2UkwFIT9CLzfuGtskiQdLIBbkwGB5Xqwt7ctqtoUmzNIU96CaH17Cmwtk
1CLel6mFROJUVcORB88i2SczpAnXiF6SV69h4N/4l7svbMBE1rkIjABkGN+jHYJ3
BZoHt9FFT9q5WAE8Hlf4SavyYzSOa7/SaJ3kxWoHgeJ/zqwV3RXdbzgVlMBBpKrJ
k1eycu5Ey0/+uih1cYLFwoRQL0Vx4MYXcjdlUOSthXmmj6k+MGaBji7qOgXCH24x
AEDmDlt5bVLiN+8YQGWjdY322A0NIkuP9OkY/r3ivWR1RtzR0iKaG5yE2dtzuzNW
MXMjHFo5P0c6dQYyUwEdpUVdpYCnFiQPvvLrXzDJax/T1aYRBPoZxnQWwSkM+frt
0zJ/nvc6Cr2Jjtiy6r7o
=Lu2x
-----END PGP SIGNATURE-----

From olaf@NLnetLabs.nl  Wed Jan 22 12:00:21 2014
Return-Path: 
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 F16CB1A047D for ; Wed, 22 Jan 2014 12:00:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.441
X-Spam-Level: 
X-Spam-Status: No, score=-100.441 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=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 11o-_18FcQJs for ; Wed, 22 Jan 2014 12:00:19 -0800 (PST)
Received: from open.nlnetlabs.nl (open.nlnetlabs.nl [IPv6:2001:7b8:206:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CF4EC1A046E for ; Wed, 22 Jan 2014 12:00:16 -0800 (PST)
Received: from [192.168.178.23] (peer.kolkman.org [82.95.132.144]) (authenticated bits=0) by open.nlnetlabs.nl (8.14.7/8.14.4) with ESMTP id s0MK09MP005808 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 22 Jan 2014 21:00:11 +0100 (CET) (envelope-from olaf@NLnetLabs.nl)
Authentication-Results: open.nlnetlabs.nl; dmarc=none header.from=NLnetLabs.nl
DKIM-Filter: OpenDKIM Filter v2.8.3 open.nlnetlabs.nl s0MK09MP005808
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nlnetlabs.nl; s=default; t=1390420815; bh=ST4g0qGP24DqpL3c+Bpmj8i9KlGTDmrcGrkGI6sBWR0=; h=From:Subject:Date:References:To:In-Reply-To; b=xiPoiAYlsMl5KoLaDyEVYgoGSHm+Hzr9eP2KBWUbGCs3ayYDn5BIkIqXmIfItI4OV 3AJdQl1JU1ZOVokJDq9/QqVqGQcudlwtAi2kbKgk4mAVSWJHApAiK3KUKYTxIrL2iO wMGHsay9DGCsR31pfLz3eWqe4O4Kg7w3ak3Je/Rw=
X-Authentication-Warning: open.nlnetlabs.nl: Host peer.kolkman.org [82.95.132.144] claimed to be [192.168.178.23]
From: Olaf Kolkman 
Content-Type: multipart/signed; boundary="Apple-Mail=_BDEDAB47-9FD9-48CB-99A2-23F7310430A1"; protocol="application/pgp-signature"; micalg=pgp-sha1
Message-Id: <1D16821E-8200-4937-BDFF-2099B7D20C3B@NLnetLabs.nl>
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
Date: Wed, 22 Jan 2014 21:00:08 +0100
References:  <20140117000402.GU2317@mournblade.imrryr.org>
To: dane@ietf.org
In-Reply-To: <20140117000402.GU2317@mournblade.imrryr.org>
X-Mailer: Apple Mail (2.1827)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (open.nlnetlabs.nl [213.154.224.1]); Wed, 22 Jan 2014 21:00:11 +0100 (CET)
Subject: Re: [dane] Meeting at IETF89 (London).
X-BeenThere: dane@ietf.org
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, 22 Jan 2014 20:00:21 -0000

--Apple-Mail=_BDEDAB47-9FD9-48CB-99A2-23F7310430A1
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252



[shameless plug ahead]

On 17 jan. 2014, at 01:04, Viktor Dukhovni  =
wrote:

>   /etc/postfix/main.cf:
> 	# Server TLS
> 	smtpd_tls_security_level =3D may
> 	smtpd_tls_loglevel =3D 1
> 	smtpd_tls_cert_file =3D ${config_directory}/smtpd-chain.pem
> 	smtpd_tls_key_file =3D ${config_directory}/smtpd-key.pem
> 	smtpd_tls_dh1024_param_file ${config_directory}/dh2048.pem
> 	smtpd_tls_dh512_param_file ${config_directory}/dh512.pem


Of course one should publish the TLSA RR once the server bit has been =
configured. Easy generation:

ldns-dane -c ${config_directory}/smtpd-chain.pem create  =
25 domain-issued full

e.g.

$ ldns-dane -c /usr/local/etc/postfix/postfix-cert.pem create =
mx.secret-wg.org 25 domain-issued full
_25._tcp.mx.secret-wg.org.	3600	IN	TLSA	3 0 1 =
3830c1286a6e1982d76b08ad04d681b5d870d8ad4374821b778b6aab462da96c



See http://www.nlnetlabs.nl/projects/ldns/ for ldns-dane (lives in most =
repos)

=97Olaf



--Apple-Mail=_BDEDAB47-9FD9-48CB-99A2-23F7310430A1
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: Signature creating using GPG Tools.

iQIcBAEBAgAGBQJS4CNIAAoJEFRqER47aqpkcr8QAIfWbRTmn8oFlRbK8Xf/xI96
NkhL7GpzzageVq/k1r3uun33ZGf+CLtfk9yYZmC1g8gUP4Um7j9Aqo7//A4wtifD
4FPRt4FVO/RAcNEQ2j+cXUrMqLroSH4nAyCit+JxUJoAv6z6db/209EoXYbkjs9d
MnF7eE8ZDr59DZNsG5P+wAm7CpZ+1bVYMvYYzdwWJj8bbsGSQ13CiFqh2G7KMtGq
hmD08RzI8922fIjzif3DRfqYEJ4X9Y+k4RgcS60xzVfSoLuc3CYxWqqBkAhM3wVJ
gzzca9olGrCqjxcrZgwppKmroIQI4D61nBBpYl9lipv1Id9nw87O/snimc6MpvtD
TNyJjhgd8kD8in78mE9S8MmJhrcg2BTKQ5FVywjlCRruZG+DfftXHsF+JGi7HFsH
oMiwQ7yymlEqNKzJQf/KyKZJRkIigFWaQ4ze5EgedyEgcZmPKf1gX8PQu/PG+akr
chsdNK8knpEo8T3ED7KxtCCuQxDeaNLhP7HO9s3flIrD5kzHiBIrmkuxJ/Np8kBT
r0pwuG90QWRVjAKmpCJVKH1NcnittYqH9okCjXEuone+zQtfuPAc8D2FjGhK5ToO
Rdes3V4MKR9zDypzEbo9GvxTQgA3pBCkY6C505UppJ4hK+mIoWs9cMeWDr0s36pA
t1/7/lSsu5d/HCzgCwII
=f2b+
-----END PGP SIGNATURE-----

--Apple-Mail=_BDEDAB47-9FD9-48CB-99A2-23F7310430A1--

From viktor1dane@dukhovni.org  Wed Jan 22 12:19:32 2014
Return-Path: 
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 9727B1A0455 for ; Wed, 22 Jan 2014 12:19:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 3tVZ6qoHW0ZM for ; Wed, 22 Jan 2014 12:19:30 -0800 (PST)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) by ietfa.amsl.com (Postfix) with ESMTP id CDD9B1A0138 for ; Wed, 22 Jan 2014 12:19:29 -0800 (PST)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9761A2AB219; Wed, 22 Jan 2014 20:19:28 +0000 (UTC)
Date: Wed, 22 Jan 2014 20:19:28 +0000
From: Viktor Dukhovni 
To: dane@ietf.org
Message-ID: <20140122201928.GT2317@mournblade.imrryr.org>
References:  <20140117000402.GU2317@mournblade.imrryr.org> <1D16821E-8200-4937-BDFF-2099B7D20C3B@NLnetLabs.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1D16821E-8200-4937-BDFF-2099B7D20C3B@NLnetLabs.nl>
User-Agent: Mutt/1.5.21 (2010-09-15)
Subject: Re: [dane] Meeting at IETF89 (London).
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dane@ietf.org
List-Id: DNS-based Authentication of Named Entities 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 22 Jan 2014 20:19:32 -0000

On Wed, Jan 22, 2014 at 09:00:08PM +0100, Olaf Kolkman wrote:

> [shameless plug ahead]
> 
> On 17 jan. 2014, at 01:04, Viktor Dukhovni  wrote:
> 
> >   /etc/postfix/main.cf:
> > 	# Server TLS
> > 	smtpd_tls_security_level = may
> > 	smtpd_tls_loglevel = 1
> > 	smtpd_tls_cert_file = ${config_directory}/smtpd-chain.pem
> > 	smtpd_tls_key_file = ${config_directory}/smtpd-key.pem
> > 	smtpd_tls_dh1024_param_file ${config_directory}/dh2048.pem
> > 	smtpd_tls_dh512_param_file ${config_directory}/dh512.pem
> 
> 
> Of course one should publish the TLSA RR once the server bit has
> been configured. Easy generation:

Yes, of course.

> ldns-dane -c ${config_directory}/smtpd-chain.pem create \
>	 25 domain-issued full

Or the short shell script below my signature, provided OpenSSL is
installed and the version is >= 1.0.0.

    $ tlsagen /usr/pkg/etc/mail-cert.pem mail.example.com:25 dane-ee spki sha2-256
    _25._tcp.mail.example.com. IN TLSA 3 1 1 89EF5B500559318251538FB1DA0BD309D38BD021EB0311A3227BE7B331B05BAC

-- 
	Viktor.

#! /bin/sh

extract() {
  case "$4" in
  0) openssl x509 -in "$1" -outform DER;;
  1) openssl x509 -in "$1" -noout -pubkey | openssl pkey -pubin -outform DER;;
  esac
}
digest() {
  case "$5" in
  0) cat;;
  1) openssl dgst -sha256 -binary;;
  2) openssl dgst -sha512 -binary;;
  esac
}
encode() {
  perl -e '
    ($cert, $hostport, $u, $s, $m) = @ARGV;
    ($host, $port) = split(":", $hostport); $port ||= 25;
    $/=undef;
    ($a=) =~ s/(.)/sprintf("%02X", ord($1))/egs;
    printf "_%d._tcp.%s. IN TLSA %d %d %d %s\n",
      $port, $host, $u, $s, $m, $a;
  ' "$@"
}

error() { echo "$1" 1>&2; exit 1; }
usage() { error "Usage: $0 cert.pem host[:port] usage selector mtype"; }
if [ $# -ne 5 ]; then usage; fi

case "$(echo $3 | tr '[A-Z]' '[a-z]')" in
0|pkix-[ct]a)	usage=0;;
1|pkix-ee)	usage=1;;
2|dane-[ct]a)	usage=2;;
3|dane-ee)	usage=3;;
*)		error "Invalid certificate usage: $3";;
esac

case "$(echo $4 | tr '[A-Z]' '[a-z]')" in
0|cert)		selector=0;;
1|spki|pkey)	selector=1;;
*) 		error "Invalid selector: $4";;
esac

case "$(echo $5 | tr '[A-Z]' '[a-z]')" in
0|full) 			mtype=0;;
1|sha2-256|sha256|sha-256) 	mtype=1;;
2|sha2-512|sha512|sha-512) 	mtype=2;;
*)				error "Invalid matching type: $5";;
esac

set -- "$1" "$2" "$usage" "$selector" "$mtype"
extract "$@" | digest "$@" | encode "$@"

From wjhns1@hardakers.net  Wed Jan 29 14:40:50 2014
Return-Path: 
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 61FD51A03AA for ; Wed, 29 Jan 2014 14:40:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.135
X-Spam-Level: 
X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 a2n_9PZpt5vH for ; Wed, 29 Jan 2014 14:40:49 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.236.43]) by ietfa.amsl.com (Postfix) with ESMTP id 3D8C71A034E for ; Wed, 29 Jan 2014 14:40:49 -0800 (PST)
Received: from localhost (50-1-19-226.dsl.dynamic.sonic.net [50.1.19.226]) by mail.hardakers.net (Postfix) with ESMTPSA id 6D1C32D848; Wed, 29 Jan 2014 14:40:44 -0800 (PST)
From: Wes Hardaker 
To: Warren Kumari 
References:  
Date: Wed, 29 Jan 2014 14:40:44 -0800
In-Reply-To:  (Warren Kumari's message of "Wed, 22 Jan 2014 14:26:27 -0500")
Message-ID: <0lr47qtnrn.fsf@wjh.hardakers.net>
User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Cc: dane@ietf.org
Subject: Re: [dane] Meeting at IETF89 (London).
X-BeenThere: dane@ietf.org
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, 29 Jan 2014 22:40:50 -0000

Warren Kumari  writes:

> And more than a quarter of our slot is already spoken for -- please
> remember to ask early if you'd like some agenda time.

DANE-smtp and likely DANE-opts both need discussion time.  Especially
the SMTP one.  On the upside I think we'll be ready for last call before
or shortly after the meeting.  I hope.
-- 
Wes Hardaker
Parsons