[dane] draft-ietf-dane-openpgpkey-00 comments
Petr Spacek <pspacek@redhat.com> Tue, 22 April 2014 08:43 UTC
Return-Path: <pspacek@redhat.com>
X-Original-To: dane@ietfa.amsl.com
Delivered-To: dane@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 973AD1A0152 for <dane@ietfa.amsl.com>; Tue, 22 Apr 2014 01:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.275
X-Spam-Level:
X-Spam-Status: No, score=-5.275 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.272, 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 CY6dXvLOoi3j for <dane@ietfa.amsl.com>; Tue, 22 Apr 2014 01:43:26 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 7A6F61A0167 for <dane@ietf.org>; Tue, 22 Apr 2014 01:43:25 -0700 (PDT)
Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s3M8hK4q015201 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <dane@ietf.org>; Tue, 22 Apr 2014 04:43:20 -0400
Received: from pspacek.brq.redhat.com (pspacek.brq.redhat.com [10.34.4.156]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s3M8hIcX023183 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for <dane@ietf.org>; Tue, 22 Apr 2014 04:43:19 -0400
Message-ID: <53562BA6.6010808@redhat.com>
Date: Tue, 22 Apr 2014 10:43:18 +0200
From: Petr Spacek <pspacek@redhat.com>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0
MIME-Version: 1.0
To: dane@ietf.org
References: <20140410175623.1767.25701.idtracker@ietfa.amsl.com>
In-Reply-To: <20140410175623.1767.25701.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.12
Archived-At: http://mailarchive.ietf.org/arch/msg/dane/6kiymeC-Cj3lJ--fv4W2fsXIAls
Subject: [dane] draft-ietf-dane-openpgpkey-00 comments
X-BeenThere: dane@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DNS-based Authentication of Named Entities <dane.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dane>, <mailto:dane-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dane/>
List-Post: <mailto:dane@ietf.org>
List-Help: <mailto:dane-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dane>, <mailto:dane-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Apr 2014 08:43:30 -0000
Hello! I would like to comment on > http://tools.ietf.org/html/draft-ietf-dane-openpgpkey-00 > 3. Location of the OpenPGPKEY record > > Email addresses are mapped into DNS using the following method: > > 1. The user name (the "left-hand side" of the email address, called > the "local-part" in the mail message format definition [RFC2822] > and the "local part" in the specification for internationalized > email [RFC6530]), is hashed using the SHA2-224 [RFC5754] > algorithm to become the left-most label in the prepared domain > name. This does not include the at symbol ("@") that separates > the left and right sides of the email address. > > 2. The DNS does not allow the use of all characters that are > supported in "local-part" of email addresses as defined in > [RFC2822] and [RFC6530] . The SHA2-224 hashing of the user name > ensures that none of these characters would need to be placed > directly in the DNS. 1) SHA-224 result representation: IMHO this section should state that SHA2-224 result has to be encoded to hexadecimal representation. I know that hexadecimal is a common representation for user interfaces but please keep in mind that SHA2-224 produces 224 bites of "noise" and hexadecimal representation is not the only possible. 2) Multiple OPENPGPKEY records for one owner name: I didn't see a note if OPENPGPKEY is supposed to be singleton or not (and how it should be processed if it isn't singleton). I'm sorry if I missed the note. 3) Algorithm agility: It is clear to me that SHA2-224 hashing is there "just" for privacy and nothing else. Still, I think it would be beneficial to have algorithm agility built-in. What about 8d[..]b7.sha224._openpgpkey.example.com. IN OPENPGPKEY <base64 public key> ? Of course, the client need to know where to look for keys. I can see two approaches: - "Dumb" clients will try all supported algorithms starting with the strongest. - List of available algorithms can be published under _openpgpkey.example.com. Note that I'm perfectly fine with defining only SHA-224 for now. Basically this is the same situation as with SSHFP fingerprint types. They started with SHA-1 only but with the alg. agility built-in. Maybe we could have yet another IANA registry for this... A new registry would allow us to do fancy things in future. E.g. to define "salted-sha-224" algorithm and store salt under ssha224._openpgpkey.example.com. That still allows you to share _openphpkey sub-tree between domains... Or to define "clear" algorithm if deemed. Or to define a clever way how to cut hash into several labels if we need to do so ... Have a nice day! -- Petr^2 Spacek
- [dane] I-D Action: draft-ietf-dane-openpgpkey-00.… internet-drafts
- [dane] draft-ietf-dane-openpgpkey-00 comments Petr Spacek
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments Petr Spacek
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments Viktor Dukhovni
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments Petr Spacek
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments James Cloos
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments Paul Wouters
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments Mark Andrews
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments Paul Wouters
- Re: [dane] draft-ietf-dane-openpgpkey-00 comments Mark Andrews