From nobody Sun Feb 5 16:09:09 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3B2129550 for ; Sun, 5 Feb 2017 16:09:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.786 X-Spam-Level: X-Spam-Status: No, score=-3.786 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZvWDkAOjew8g for ; Sun, 5 Feb 2017 16:09:06 -0800 (PST) Received: from smtp84.ord1c.emailsrvr.com (smtp84.ord1c.emailsrvr.com [108.166.43.84]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B415126D73 for ; Sun, 5 Feb 2017 16:09:05 -0800 (PST) Received: from smtp3.relay.ord1c.emailsrvr.com (localhost [127.0.0.1]) by smtp3.relay.ord1c.emailsrvr.com (SMTP Server) with ESMTP id E5040A0167; Sun, 5 Feb 2017 19:09:00 -0500 (EST) X-Auth-ID: ogud@ogud.com Received: by smtp3.relay.ord1c.emailsrvr.com (Authenticated sender: ogud-AT-ogud.com) with ESMTPSA id 824C4A013D; Sun, 5 Feb 2017 19:08:53 -0500 (EST) X-Sender-Id: ogud@ogud.com Received: from [10.20.30.43] (pool-71-191-33-181.washdc.fios.verizon.net [71.191.33.181]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Sun, 05 Feb 2017 19:09:00 -0500 From: Olafur Gudmundsson Content-Type: multipart/alternative; boundary="Apple-Mail=_8E00540C-2A79-4B74-B596-88D7FA3C9BDE" Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Message-Id: <592BF95B-36A1-4E1B-B746-AF880A2E4689@ogud.com> Date: Sun, 5 Feb 2017 19:08:54 -0500 To: ietf-secretariat@ietf.org X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dane WG list Subject: [dane] Publication request: draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 00:09:08 -0000 --Apple-Mail=_8E00540C-2A79-4B74-B596-88D7FA3C9BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 The draft passed WGLC, and all identified issues have been addressed.=20 Writeup included below.=20 Thanks Olafur=20 As required by RFC 4858, this is the current template for the Document = Shepherd Write-Up. Changes are expected over time. This version is dated 24 February 2012. (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header?=20 Experimental is requested, and indicated in the header.=20 (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections:=20 Technical Summary: This document proposes a method to publish and "locate" S/MIME keys via DNS. The goal of this approach is to make it easier to find S/MIME keys for email addresses. The document reuses a "method" from = RFC7929 to convert email-address into a special normal form. that is limited but is expected to cover many cases. The S/MIME DNS record specified has=20 been allocated by an Expert Review. =20 While the method inherited from RFC7929 has some detractors, this is an = experimental document, and that should not block the publication.=20 Working Group Summary: The main issues that the WG has discussed are=20 a) is it a good idea to publish email addresses in DNSSEC signed zone?=20= b) is the role of the normalization from strictly a normalization or an obfuscation as well?=20 The consensus of the WG is that as the publication is by the zone owner it is an opt-in policy, there is no requirement for adoption thus the issue need to be addressed in the light of each organizations polices, i.e this is not a protocol issue.=20 =20 There is working group consensus to advance this document.=20 Document Quality: This document is of high quality, and editors have been real good at = making the document better.=20 This document stands on the shoulders of RFC 7929 Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Document Sheperd is Olafur Gudmundsson=20 Responsible AD is : Stephen Farrell,=20 (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.=20 Document Shepherd has read every version of the document, and worked = with the editors in addressing issues. A extensive working group last = call was conducted, along with with a session at a DANE meeting where people from the email community had a frank discussion about the issues and scope of the document. This document has advanced as far as it can inside the WG and punishing as Experimental is the the desire of the WG.=20 (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? Not really.=20 (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place.=20 Number of respected members of the email community have commented on the = document.=20 (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here.=20 There are are two issues that have been raised over and over again.=20 A. Do not publish email addresses in the DNS.=20 B. You are not guaranteed to find the key of the actual person you want to send signed/encrypted email to.=20 Both of these issues have been refuted and as publication is optional A. does not really apply. For B. there conversion technique is has got extensive input and improved based on that. There is not much more we can do at this point to address it, and the document is basically a copy = of RFC7929 (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why?=20 Two IPR=E2=80=99s have been filed both for the same patent=20 https://datatracker.ietf.org/ipr/2468/ (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.=20 Not sure as in my day job I=E2=80=99m not allowed to read patents.=20 (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it?=20 Strong enough (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.)=20 No=20 (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ = and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.=20 None=20 (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.=20 Yes the document was reviewed by DNS RR type Registry experts.=20 (13) Have all references within this document been identified as either normative or informative? Yes (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion?=20 No=20 (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.=20 No (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.=20 No (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226).=20 Only IANA action requested is to update a reference upon publication of this document.=20 (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries.=20 Done (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc.=20 ID-nits=20 None.= --Apple-Mail=_8E00540C-2A79-4B74-B596-88D7FA3C9BDE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8


The draft passed WGLC, and all = identified issues have been addressed. 
Writeup included = below. 
Thanks
Olafur 

As = required by RFC 4858, this is the current template for the Document = Shepherd Write-Up.

Changes are expected over time. This version is dated 24 = February 2012.

(1) What type of RFC is being requested (BCP, Proposed = Standard,
Internet = Standard, Informational, Experimental, or Historic)? Why = is
this the proper type of RFC? Is = this type of RFC indicated in the
title page header? 

Experimental is requested, and = indicated in the header. 

(2) The IESG approval = announcement includes a Document Announcement
Write-Up. Please provide such a = Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for = approved
documents. The = approval announcement contains the following = sections: 

Technical Summary:
This document proposes a method to publish and "locate" = S/MIME keys
via DNS. The = goal of this approach is to make it easier to find
S/MIME keys for email = addresses.  The document reuses  a "method" from RFC7929 = to
convert email-address into a = special normal form. that is limited but
is expected to cover many cases. The S/MIME DNS record = specified has 
been = allocated by an Expert Review.  

While the method inherited from = RFC7929 has some detractors, this is an experimental document, and that = should not block the publication. 

Working Group = Summary:

The main issues that the WG has discussed = are 
a) is it a good = idea to publish email addresses in DNSSEC signed = zone? 
b) is the role = of the normalization from strictly a normalization or = an
obfuscation as = well? 
The consensus = of the WG is that as the publication is by the zone = owner
it is an opt-in = policy, there is no requirement for adoption thus the
issue need to be addressed in = the light of each organizations
polices, i.e this is not a protocol = issue. 

 

There is working group consensus = to advance this document. 

Document = Quality:

This document is of high quality, and editors have been real = good at making the document better. 

This document stands on the = shoulders of RFC 7929

Personnel:

Who is the Document Shepherd? Who is the Responsible Area = Director?
Document = Sheperd is Olafur Gudmundsson 
Responsible AD is : Stephen Farrell, 

(3) Briefly describe the review = of this document that was performed by
the Document Shepherd. If this version of the document is not = ready
for = publication, please explain why the document is being forwarded = to
the = IESG. 

Document Shepherd has read every version of the document, and = worked with the editors in addressing issues. A extensive working group = last call was
conducted, = along with with a session at a DANE meeting where = people
from the email = community had a frank discussion about the issues and
scope of the document. This = document has advanced as far as it can
inside the WG and punishing as Experimental is the the desire = of
the WG. 

(4) Does the document Shepherd = have any concerns about the depth or
breadth of the reviews that have been = performed?

Not really. 

(5) Do portions of the document = need review from a particular or from
broader perspective, e.g., security, operational complexity, = AAA, DNS,
DHCP, XML, or = internationalization? If so, describe the review that
took = place. 

Number of respected members of the email community have = commented on the document. 

(6) Describe any specific = concerns or issues that the Document
Shepherd has with this document that the Responsible Area = Director
and/or the IESG = should be aware of? For example, perhaps he or she is
uncomfortable with certain parts = of the document, or has concerns
whether there really is a need for it. In any event, if the = WG has
discussed those = issues and has indicated that it still wishes to
advance the document, detail = those concerns here. 

There are are two issues that = have been raised over and over again. 
A. Do not publish email = addresses in the DNS. 
B. You are not guaranteed to find the key of the actual = person you
want to send = signed/encrypted email to. 

Both of these issues have been = refuted and as publication is optional
A. does not really apply. For B. there conversion technique = is has got
extensive input = and improved based on that. There is not much more we
can do at this point to address = it, and the document is basically a copy of RFC7929


(7) Has each author confirmed = that any and all appropriate IPR
disclosures required for full conformance with the provisions = of BCP
78 and BCP 79 = have already been filed. If not, explain why? 

Two IPR=E2=80=99s have been = filed both for the same patent 
https://datatracker.ietf.org/ipr/2468/

(8) Has an IPR disclosure been = filed that references this document? If
so, summarize any WG discussion and conclusion regarding the = IPR
disclosures. 

Not sure as in my day job I=E2=80=99= m not allowed to read patents. 

(9) How solid is the WG = consensus behind this document? Does it
represent the strong concurrence of a few individuals, with = others
being silent, = or does the WG as a whole understand and agree with = it? 

Strong enough

(10) Has anyone threatened an = appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in = separate
email messages = to the Responsible Area Director. (It should be in a
separate email because this = questionnaire is publicly available.) 

No 

(11) Identify any ID nits the = Document Shepherd has found in this
document. (See http://www.ietf.org/tools/idnits/ and = the
Internet-Drafts Checklist). = Boilerplate checks are not enough; this
check needs to be thorough. 

None 

(12) Describe how the document = meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type = reviews. 

Yes the document was reviewed by DNS RR type Registry = experts. 

(13) Have all references within this document been identified = as
either normative or = informative?

Yes

(14) Are there normative references to documents that are not = ready
for advancement = or are otherwise in an unclear state? If such
normative references exist, what = is the plan for their completion? 

No 

(15) Are there downward = normative references references (see RFC
3967)? If so, list these downward references to support the = Area
Director in the = Last Call procedure. 

No

(16) Will publication of this = document change the status of any
existing RFCs? Are those RFCs listed on the title page = header, listed
in the = abstract, and discussed in the introduction? If the RFCs = are
not listed in the Abstract and = Introduction, explain why, and point to
the part of the document where the relationship of this = document to
the other RFCs = is discussed. If this information is not in the
document, explain why the WG = considers it unnecessary. 

No

(17) Describe the Document = Shepherd's review of the IANA
considerations section, especially with regard to its = consistency with
the body of the = document. Confirm that all protocol extensions that
the document makes are = associated with the appropriate reservations in
IANA registries. Confirm that = any referenced IANA registries have been
clearly identified. Confirm that newly created IANA = registries include
a = detailed specification of the initial contents for the = registry,
that = allocations procedures for future registrations are defined, = and
a reasonable name for the new = registry has been suggested (see RFC
5226). 

Only IANA action requested is to = update a reference upon publication of
this document. 

(18) List any new IANA = registries that require Expert Review for
future allocations. Provide any = public guidance that the IESG would
find useful in selecting the IANA Experts for these new = registries. 

Done

(19) Describe reviews and automated checks performed by the = Document
Shepherd to = validate sections of the document written in a formal
language, such as XML code, BNF = rules, MIB definitions, etc. 

ID-nits 

None.
= --Apple-Mail=_8E00540C-2A79-4B74-B596-88D7FA3C9BDE-- From nobody Tue Feb 7 08:13:07 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F63B129CFD for ; Tue, 7 Feb 2017 08:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 uQkpT3mSUqcP for ; Tue, 7 Feb 2017 08:13:04 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F28129D07 for ; Tue, 7 Feb 2017 08:13:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3DD80BE56 for ; Tue, 7 Feb 2017 16:13:00 +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 2nGIg-aFxNhE for ; Tue, 7 Feb 2017 16:12:58 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 433BEBE53 for ; Tue, 7 Feb 2017 16:12:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486483978; bh=hqX8itqGlRV+vs952aqYSROvuICRvLIWB2C2saQxmxM=; h=To:From:Subject:Date:From; b=zPePful6Ejr/Kc034cvqegvtU1H7SLsRaRk4QYP0g9tH1Qyj98fhSgJl0FvSTttFu PmO4aVNO1dVaGQiPpXqmitDDiuyalP3IBqGgAGZ/iPp/JdkRB0mo6xf3HSZJHTPMv8 4f4Y++814YtXv2uEEl2wjBSCYc19Kb8SZckj7aw0= To: dane From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie> Date: Tue, 7 Feb 2017 16:12:57 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090302080509070104080403" Archived-At: Subject: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 16:13:06 -0000 This is a cryptographically signed message in MIME format. --------------ms090302080509070104080403 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, I've done my AD review of this draft. My own comments on the content are below (the one I'd most like to see fixed is the "escrow" stuff) and are ok to be handled along with other IETF LC comments. However, before I start IETF LC I would like to be sure that the WG are ok with the IPR declaration [1] filed in 2014 that said "Licensing Declaration to be Provided Later." I think 2017 is "later" enough to ask whether that the WG (via the chairs) explicitly declare that they are ok that this has yet to be clarified. Cheers, S. [1] https://datatracker.ietf.org/ipr/2468/ - abstract: Someone will want DANE expanded. Better to avoid the acronym maybe. - intro: "Some people want..." is odd - that is not a technical justification and the entire paragraph is not that convincing. I'd say deleting that para would be better. Or add a real justification for the experiment which I think relates more to attempting to mitigate the difficulty of finding certs from outside the enterprise than anything else. - intro: I'd suggest adding a sentence about how this is similar to RFC7929. As a reader, I'd find it odd to only find that out later. - section 3: This is the same idea as in RFC 7929 right? (Other than _smimecert I mean,) If so then saying so is right as it'll help with IETF LC and IESG review and for developers. If those differ, then saying how and why I think would be needed. - section 4: Please check whether this is all fine when also considering draft-ietf-lamps-eai-addresses (also in IETF LC). That check may need to wait a little bit until we're done with the LC comment handling for the LAMPS deraft. - Section 9: the discussion of an MTA doing the outbound encryption seems a bit theoretical - I don't recall that being dnoe in reality except maybe in very special cases like nested smime, or military messaging. Am I wrong about that? - section 9: I think the text about escrow would be better after the current last para (where you call out the danger of bad public keys being put in the DNS), and this (escrow) ought be described as a special case of that attack, where the attacker is the organisation itself. (While there are cases where the organisation doing this is not intended as an attack, were it done for most DNS names, it would mostly be an attack, and is not distinguishable from an attack for the sender, so therefore it ought IMO be considered an attack.) - section 9: s/MUST not/MUST NOT/ or I-D nits complains - section 11: I-D nits complains, maybe calling this "normative references" would help, but in any case, please consider/fix this. --------------ms090302080509070104080403 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDcx NjEyNTdaMC8GCSqGSIb3DQEJBDEiBCCMCC+NA6yXPAvr6hy+yvOxXkzrHcwQhCY3EUjFlA6d AzBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCnvOo41pFDL0gAL3LsLfsVwQXj6Kc5qqPd+MkoswdKTv45lAd6CpYR ZYRCFLagBUWvC/gOnRpGSQqwy+Zq8S0DeltletGXAoD5zT4K0T//wGyMEmZwdJTrwSvdHBtk gROakspQqvavn3gAwEm7AorVXL21xKW2pf/HmD8ljk4EVUkw5hQhZysa8P0QfvqzSha4xlBp 3j22G1p7S1xv9Val+dFzREWLaWxDctoFzmXUJ1tGizsXAJhUbfqdwLm22SJGUE79R5+AyBWk KacimI3re4tv+LYDt35mvPJGtT4kIRV+E/+bdctbPMGn3rY6kYKHhp3zt+YptxaE3rG1Y50q AAAAAAAA --------------ms090302080509070104080403-- From nobody Wed Feb 8 06:22:23 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9110F129B19 for ; Wed, 8 Feb 2017 06:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 rBQCAfKXzEv9 for ; Wed, 8 Feb 2017 06:22:20 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 090B6129AE7 for ; Wed, 8 Feb 2017 06:22:20 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vJNh858rvz3L9; Wed, 8 Feb 2017 15:22:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1486563736; bh=4VeSCCLpua3z8iQRGujje6tsZ+UbZYxk9AI35UQJPCA=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=RN3TEVOP/DoTwV2xQ8qheAqZQhdcN1tCZTAgX5WG7yWGUl9ogK2SlT+gSCqatKDbb vOxFVm89BZWaF97E80xIq+zUeuV4BIkAXLS1LoReBK9/on6Q0DnEGfyZs4Tm61FbtR a788TbfHmerMiiNcx0+fVROn+lM4rdWhy+hAbZP0= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id zyQnE1N3-P3e; Wed, 8 Feb 2017 15:22:14 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 8 Feb 2017 15:22:13 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C14F455A559; Wed, 8 Feb 2017 09:22:12 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C14F455A559 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AD9C041DA5AF; Wed, 8 Feb 2017 09:22:12 -0500 (EST) Date: Wed, 8 Feb 2017 09:22:12 -0500 (EST) From: Paul Wouters To: Stephen Farrell In-Reply-To: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie> Message-ID: References: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dane Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 14:22:22 -0000 On Tue, 7 Feb 2017, Stephen Farrell wrote: > However, before I start IETF LC I would like to be > sure that the WG are ok with the IPR declaration [1] > filed in 2014 that said "Licensing Declaration to > be Provided Later." I think 2017 is "later" enough > to ask whether that the WG (via the chairs) explicitly > declare that they are ok that this has yet to be > clarified. > [1] https://datatracker.ietf.org/ipr/2468/ The patent is dated 11-27-2013. The first openpgpkey draft is dated July 15, 2013. https://tools.ietf.org/html/draft-wouters-dane-openpgp-00 The patent is also completely unrelated to email, and instead mumbles about using DNSSEC to publish policy for public consumption. Fortunately, we have the whole origin of DNSSEC and the FreeS/WAN team with John Gilmore and Hugh Daniel predating that idea to about 1995 and earlier. In fact, half the people working on DNSSEC 25 years ago had as _goal_ to use DNSSEC as a PKI to publish policy and I'm sure the heated namedroppers archive will show that this patent application is absolute bullshit and Verisign and the authors should be ashamed of such lame attempts at "inventing". And the worst is, they weren't even the first to do this. There are also the patents of Thierry Moreau of Connotech who threatened me back in 2007 with lawsuits when he warned IETF he had similar broad patents of having invented using DNSSEC for something non-DNS. So yeah, I think the WG can safely ignore this nonsense, and if anyone is ever approached by Verisign for illegal use of their patent, do contact me to provide you with an expert witness statement. Paul From nobody Wed Feb 8 07:03:51 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C73F7129B93 for ; Wed, 8 Feb 2017 07:03:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id exZfPqEqqy20 for ; Wed, 8 Feb 2017 07:03:44 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AFF129B81 for ; Wed, 8 Feb 2017 07:03:44 -0800 (PST) Received: (qmail 86959 invoked from network); 8 Feb 2017 15:03:42 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 8 Feb 2017 15:03:42 -0000 Date: 8 Feb 2017 15:03:20 -0000 Message-ID: <20170208150320.14692.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul@nohats.ca Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 15:03:49 -0000 >The patent is dated 11-27-2013. It's not a patent, it's a patent application, and if you read the first page of the application, it claims priority from a provisional application dated March 15, 2013, which is earlier than July. >The first openpgpkey draft is dated July 15, 2013. >https://tools.ietf.org/html/draft-wouters-dane-openpgp-00 >The patent is also completely unrelated to email, and instead mumbles >about using DNSSEC to publish policy for public consumption. You might want to reread the application. If you say that a S/MIME certificate expresses policies, which is not much of a stretch in patent-ese, then this applies directly to publishing a bunch of DNSSEC signed certificates. I agree that the application is pretty weak, and there is probably lots of prior art, but I'd also note that an e-mail message from long ago saying that one wanted to do something is not necessarily prior art if you can't show that someone actually did it. I would also note that it is an application, not a patent, and many, perhaps most, applications never turn into patents. But it's definitely relevant. FYI, there are also patent applications pending in Europe and China. R's, John From nobody Wed Feb 8 07:25:50 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D86F7127058 for ; Wed, 8 Feb 2017 07:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 WwCtgD5ln1Tr for ; Wed, 8 Feb 2017 07:25:46 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2530C120724 for ; Wed, 8 Feb 2017 07:25:46 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vJQ5L5bWBz27r; Wed, 8 Feb 2017 16:25:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1486567542; bh=EM0C6zEnZHuFGUQ+lMwWkGTzKz5NLS92ku0KZvGKmaU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OSYXxnhUR08+pbe4uWENcxUb+EykirDLY7F9Ec/1zlw4TS3tiUKaFX95kX7ikgm0I r6RYi6obyPPnlZOt17Fn3v1odfn0BlsUYSUwex80LgAybJM1NRaazRqqQBDhwv8r7R PvxULL1WrRwC6iRim1BD3XFzldwaVp8+2m/xLzQI= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id usAjDT24H2Fo; Wed, 8 Feb 2017 16:25:41 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 8 Feb 2017 16:25:40 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4411055A559; Wed, 8 Feb 2017 10:25:39 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 4411055A559 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3C69941D927F; Wed, 8 Feb 2017 10:25:39 -0500 (EST) Date: Wed, 8 Feb 2017 10:25:39 -0500 (EST) From: Paul Wouters To: dane WG list In-Reply-To: <20170208150320.14692.qmail@ary.lan> Message-ID: References: <20170208150320.14692.qmail@ary.lan> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 15:25:49 -0000 On Wed, 8 Feb 2017, John Levine wrote: > It's not a patent, it's a patent application, and if you read the > first page of the application, it claims priority from a provisional > application dated March 15, 2013, which is earlier than July. https://www.mail-archive.com/dane@ietf.org/msg00272.html Nov 2012. https://tools.ietf.org/html/draft-fanf-dane-mua-00 June 27, 2012. > You might want to reread the application. If you say that a S/MIME > certificate expresses policies, which is not much of a stretch in > patent-ese, then this applies directly to publishing a bunch of DNSSEC > signed certificates. We seem to agree the patent application is not specific to email and thus only affects the smime draft based on its very generic concept. > I agree that the application is pretty weak, and there is probably > lots of prior art, but I'd also note that an e-mail message from long > ago saying that one wanted to do something is not necessarily prior > art if you can't show that someone actually did it. I would also note > that it is an application, not a patent, and many, perhaps most, > applications never turn into patents. But it's definitely relevant. https://tools.ietf.org/html/draft-ietf-ipseckey-rr-00 Published March 30, 2003 Although the implementation predates even that: http://www.freeswan.org/oldnews.html 2001/06/22 We would like to announce that the Linux FreeS/WAN project has now released version 1.91 of our IPSEC system. The BIG news for the 1.91 release is that you can now begin to use Opportunistic Encryption! > FYI, there are also patent applications pending in Europe and China. Still not impressed. This whole exercise is a waste of everyone's time and Verisign should just put a stop to it. Paul From nobody Wed Feb 8 12:40:10 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BA05129437 for ; Wed, 8 Feb 2017 12:40:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 Cs6Rh0gJBf2W for ; Wed, 8 Feb 2017 12:40:06 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423EE12941A for ; Wed, 8 Feb 2017 12:40:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 05111BE50; Wed, 8 Feb 2017 20:40:04 +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 vKWmYKioLFIc; Wed, 8 Feb 2017 20:40:02 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 02109BE3E; Wed, 8 Feb 2017 20:40:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486586402; bh=kl+n1Kq//BkaVxalzbY5hv0BOzzEGKrkSgHdNZAc0d4=; h=Subject:To:References:From:Date:In-Reply-To:From; b=JKDEUhbra7h0ZArQINCYA705adL40cYnzyXfH/2yCw7A5geEaA+bQ1L61FIdt1Cqt gFxJOVYOQfUqFjybtLj4Z1B5XdUCrLQsIkM/duUFlxMeH+s9/605PCQYyGaqWs0YrB 8DbdyPA8g2qqzdUS7fZ2alDN7WR24wtnFA12LI4Y= To: Paul Wouters , dane WG list References: <20170208150320.14692.qmail@ary.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 8 Feb 2017 20:40:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms040507060104050006050304" Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 20:40:08 -0000 This is a cryptographically signed message in MIME format. --------------ms040507060104050006050304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 08/02/17 15:25, Paul Wouters wrote: > Still not impressed. While I may well agree, that doesn't answer my question, which doesn't relate to the application itself but to the IPR declaration's statement that licensing information will be provided "later." Cheers, S. --------------ms040507060104050006050304 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDgy MDQwMDFaMC8GCSqGSIb3DQEJBDEiBCBJnJTREYDcS+s26HFgLzWYuvnBlG/1JiDdO1ZjCnJh QjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQA0wUyZ0obTkZYt3Pr9EhHapXCqzrtfY52Nb4DmpHea/TtYp/2rZoA+ xRWYdho/PKm+9/dBlhEvZl3s9vwlV/aLbQiPPcTOMl+FqsprNInvFu7GtPcuyfEhDt1eN4lW frlt1eJFbKXXze9CWHUviGlvDDoa6WBgGDxm+X0yG6CbuYqi+BBhcy5V2MeoHjNWUyDSfkQU bVoQaxonkwWu9yUCvUzlRLPnsmVUc/O79iqQTI63uxHV8w4fYwSucT8F8vMp8KzTYrycUPm7 B0EUpmALK19Y5Y9Q0zsfXUlKL3GrKzMdthB+bLflyGCntxqrRbkhoedOHUXVWyFewY1YLFGp AAAAAAAA --------------ms040507060104050006050304-- From nobody Wed Feb 8 20:18:05 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5460A129EF2 for ; Wed, 8 Feb 2017 20:18:04 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dCpqhEfjaHOh for ; Wed, 8 Feb 2017 20:18:03 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECB16129EF0 for ; Wed, 8 Feb 2017 20:18:02 -0800 (PST) Received: (qmail 96683 invoked from network); 9 Feb 2017 04:18:01 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 9 Feb 2017 04:18:01 -0000 Date: 9 Feb 2017 04:17:39 -0000 Message-ID: <20170209041739.17865.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 04:18:04 -0000 >the IPR declaration's statement that licensing information >will be provided "later." I agree with Paul that it's a lousy application, and I think that more likely than not it'll be abandoned with no patents granted. But if any of the three applications (US, EU, China) turned into actual patents, and Verisign were to require a license that cost money, or that was otherwise incompatible with open source implementations, that would be a problem. I see that Verisign has offered a free-unless-you-sue-us license for other patent applications, like this one, dunno why they do for some but not others: https://datatracker.ietf.org/ipr/2703/ In any event, you alrady know what my suggested solution is. R's, John From nobody Fri Feb 10 06:28:12 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18FDF129986 for ; Fri, 10 Feb 2017 06:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sidn.nl 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 TFceJIBdfY9Q for ; Fri, 10 Feb 2017 06:28:10 -0800 (PST) Received: from arn2-kamx.sidn.nl (kamx.sidn.nl [IPv6:2a00:d78:0:147:94:198:152:69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5887129965 for ; Fri, 10 Feb 2017 06:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=sidn.nl; s=sidn-nl; c=relaxed/relaxed; h=from:to:subject:thread-topic:thread-index:date:message-id:references:in-reply-to:accept-language:content-language:x-ms-has-attach:x-ms-tnef-correlator:user-agent:x-ms-exchange-messagesentrepresentingtype:x-ms-exchange-transport-fromentityheader:x-originating-ip:content-type:content-id:content-transfer-encoding:mime-version; bh=NgKKmdDBJVa2dPmjctEgy2fPlbA3+mgP9hV1BPs/BRw=; b=hift+1KlalWQGlef3dcurGK7E2DPOxeC0NF23V2mUR2vDTkdJ6fD5Li16q3tdD8iASnHXtMLUcm281H4V1Ww9lSXJACWxGP5/GD5qlmgzBrMzwdB93a6pIRlFkY+dFdwY4Z3TbB5+g5EBVlQZsO7hDdakkm2QJoHOlBwAyQ3LKmLY2fbk/KQtUTLRjhteV4aarJSlbkz+ewyf240y18EWLNst3cWWbdOk6bL+sqbHUIHlHdTsJaYSuiQDLEt9uh2rIPU8s/95nawrP1jlheD22rO3XZajvuzq3ZWZMbYGiDu/ege/EelfQDTXJej8xxiGx8H/JWxUCIkQER4mDkrhw== Received: from ka-mbx01.SIDN.local ([192.168.2.177]) by arn2-kamx.sidn.nl with ESMTP id v1AES6SQ025881-v1AES6SS025881 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=CAFAIL) for ; Fri, 10 Feb 2017 15:28:06 +0100 Received: from ka-mbx01.SIDN.local (192.168.2.177) by ka-mbx01.SIDN.local (192.168.2.177) with Microsoft SMTP Server (TLS) id 15.0.1130.7; Fri, 10 Feb 2017 15:28:06 +0100 Received: from ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d]) by ka-mbx01.SIDN.local ([fe80::e051:e184:7a9f:b09d%13]) with mapi id 15.00.1130.005; Fri, 10 Feb 2017 15:28:06 +0100 From: Marc Groeneweg To: "dane@ietf.org" Thread-Topic: [dane] AD review of draft-ietf-dane-smime-14 Thread-Index: AQHSgV0a6tSlviWnpUuxsck/2YCYI6FfGfwAgAALfgCAAAY8gIAAV9WAgAB/3YCAAk2nAA== Date: Fri, 10 Feb 2017 14:28:06 +0000 Message-ID: <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> References: <20170209041739.17865.qmail@ary.lan> In-Reply-To: <20170209041739.17865.qmail@ary.lan> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1f.0.170207 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.168.7.67] Content-Type: text/plain; charset="utf-8" Content-ID: <1F3C88F5A2B2A6448CD528C5243FDDF3@sidn.nl> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 14:28:12 -0000 Pj50aGUgSVBSIGRlY2xhcmF0aW9uJ3Mgc3RhdGVtZW50IHRoYXQgbGljZW5zaW5nIGluZm9ybWF0 aW9uDQo+PndpbGwgYmUgcHJvdmlkZWQgImxhdGVyLiINCkFzIHdlIGhhZCB3aXRoIHRoZSBrZXly ZWxheSBkcmFmdCBpbiByZWdleHQgKGFuZCB0aGUgZHJhZnQgb2YgUGV0ZXIgS29jaCB3aXRoIERO U1NFQyB0cmFuc2ZlcnMpLg0KICAgIA0KPFNOQVAvPg0KICAgIA0KPiBJIHNlZSB0aGF0IFZlcmlz aWduIGhhcyBvZmZlcmVkIGEgZnJlZS11bmxlc3MteW91LXN1ZS11cyBsaWNlbnNlIGZvcg0KPiBv dGhlciBwYXRlbnQgYXBwbGljYXRpb25zLCBsaWtlIHRoaXMgb25lLCBkdW5ubyB3aHkgdGhleSBk byBmb3Igc29tZQ0KPiBidXQgbm90IG90aGVyczoNCj4gICAgDQo+ICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvaXByLzI3MDMvDQpPdGhlciB0aGFuIHRoYXQgdGhlIHN1Z2dlc3RlZCBk cmFmdCBpcyBhbHNvIGJ5IFZlcmlzaWduIHRoZW1zZWx2ZXM/DQoNCj4gSW4gYW55IGV2ZW50LCB5 b3UgYWxyYWR5IGtub3cgd2hhdCBteSBzdWdnZXN0ZWQgc29sdXRpb24gaXMuDQoNClJlZ2FyZHMs DQpNYXJjDQoNCg== From nobody Sun Feb 12 14:27:36 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8041127076 for ; Sun, 12 Feb 2017 14:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l5UhOg1OFY4S for ; Sun, 12 Feb 2017 14:27:32 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A198120725 for ; Sun, 12 Feb 2017 14:27:32 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id u25so79967072qki.2 for ; Sun, 12 Feb 2017 14:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IbCTzwDWc+nTopimx7seoV0vCcbWx0eijeFP4bkKlZU=; b=Cgsd5Ugr8ymLGG4OQEvbWSTBGLZJoGRBSyrtZBQvODQkjcIq1Yiu3zgSL0R99Ne03C 4/UaMBXEHbYilhid6Dz20EbltWa+Hw1+0Dtqu+Xq5OH8pHFLX0pJAs2l2fpcLB6kD/0N cdMj91qzVBaW0/DC1xD6lhQcInwa6sGql9nYJvGIFj2Bck63FQPqCjkLjZQejJTOjPB7 npr9dfU5P7asWqFeCpVcmvFDWuVn91L4yunNHdj3EdxsUjJaxsi+KSaa+xk/GWAuI1Ry 5SacJjNxI6TBdqAHrUVxYwGU3YyjBXybrJpB6Ztaz+47MS8Kki/eZEanE2Nr3rpBouLN ETWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IbCTzwDWc+nTopimx7seoV0vCcbWx0eijeFP4bkKlZU=; b=sHqCp4oTAKV1SgtijRKb1xATllpKVAelLGeTP2lKGmt7BUWCwcQW4vSyBOJjAv3Uqq +73Hct27Pcj1Q4vE+2qVDQZYv8z9vChTBPTrmWwH4XwVgFTJ3JJJGt06X37Qh6AXSzRS J6i5OS4tCwmJXU/a9UPDHx7hIs8s7x5OOkJeiHk74uvm5cmwdjLZ6qGbiHAbMBfv+7kJ vYJn6AfraKoqHh/79pahgP3nWF8TyjTDuRMErl8gU+hM3u7G4GgznpgsSEcsilLZTp9S aGZmWAXAYIaCXJZDhCrRKGFtn4WZhPaebXAv10/2YdWlMz531fI05ktjcH0LBm+owFFy 6BGg== X-Gm-Message-State: AMke39nfDY9AjBQUs58EQJjDzNgsyW8TaXwnm99gfh36yuzX9jsk3JSiXA1ea7+9vFXwWHIfX5QMLf4SIiHoN3iY X-Received: by 10.55.78.67 with SMTP id c64mr20626729qkb.251.1486938451265; Sun, 12 Feb 2017 14:27:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Sun, 12 Feb 2017 14:27:00 -0800 (PST) In-Reply-To: <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> From: Warren Kumari Date: Sun, 12 Feb 2017 17:27:00 -0500 Message-ID: To: Marc Groeneweg Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 22:27:34 -0000 On Fri, Feb 10, 2017 at 9:28 AM, Marc Groeneweg wrote: >>>the IPR declaration's statement that licensing information >>>will be provided "later." > As we had with the keyrelay draft in regext (and the draft of Peter Koch with DNSSEC transfers). Can you remind us what ended up happening with those two? I vaguely remember some discussion about it being hard to get a commitment, and that "later" seemed like a DoS on the process, but was there ever a resolution? Is the WG OK with this, or do you feel that we need to try and get the IPR statement updated? (Remembering that, AFAIK, we cannot do anything other than ask nicely...) W > > > >> I see that Verisign has offered a free-unless-you-sue-us license for >> other patent applications, like this one, dunno why they do for some >> but not others: >> >> https://datatracker.ietf.org/ipr/2703/ > Other than that the suggested draft is also by Verisign themselves? > >> In any event, you alrady know what my suggested solution is. > > Regards, > Marc > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Feb 12 14:31:26 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66881128824 for ; Sun, 12 Feb 2017 14:31:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 wvafHxuGmOkZ for ; Sun, 12 Feb 2017 14:31:22 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89009120725 for ; Sun, 12 Feb 2017 14:31:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 36171BE5B; Sun, 12 Feb 2017 22:31:20 +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 altdHU2DxlTL; Sun, 12 Feb 2017 22:31:19 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A204BBE56; Sun, 12 Feb 2017 22:31:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486938679; bh=crMQv+VhfmYc6RVcuaAFYGkJEn8wjQsS5VTMi3tGdzo=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=WDmZ5dqpoqWFzKuU8IjbbnMpGNR8mVDw+qcuBVeNev/Bf5N2ehQ+ULfZZaEM1Oa0+ AcGrMnm6N+hrP8uYDMi8wFR7OdCzHHR1LSiDlI65SIe0RaIVisHOx1hsmeFOyr1jaU mTRVezWeD8D4wsTMMX6LIOgtXPXJyuTLhJ8mvkEA= To: Warren Kumari , Marc Groeneweg References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <03eebf14-be00-911d-a388-8e18438a4ecd@cs.tcd.ie> Date: Sun, 12 Feb 2017 22:31:17 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AIBeSWbv17cdPHIKEcA0N5FRBwl3rN8kc" Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 22:31:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AIBeSWbv17cdPHIKEcA0N5FRBwl3rN8kc Content-Type: multipart/mixed; boundary="QjFV7IDVINMBWW1jAqlQLvMmcWUUN4EmU"; protected-headers="v1" From: Stephen Farrell To: Warren Kumari , Marc Groeneweg Cc: "dane@ietf.org" Message-ID: <03eebf14-be00-911d-a388-8e18438a4ecd@cs.tcd.ie> Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> In-Reply-To: --QjFV7IDVINMBWW1jAqlQLvMmcWUUN4EmU Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 12/02/17 22:27, Warren Kumari wrote: > do you feel that we need to try and get the > IPR statement updated?=20 I not sure but if that question is addressed at me, then I am not trying to insist that the IPR declaration be updated, but just want to check that the WG are ok with that "later" statement, despite it now being "much later." > (Remembering that, AFAIK, we cannot do anything > other than ask nicely...) Yep. We can't force anyone to update a declaration and as noted there was at least one other case where a year went by with folks asking and not seeing any update happen in a quite similar case involving the same entity. S. --QjFV7IDVINMBWW1jAqlQLvMmcWUUN4EmU-- --AIBeSWbv17cdPHIKEcA0N5FRBwl3rN8kc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYoOI2AAoJEC88hzaAX42i+eQH/2KVgn6OsiUeX/D1cgy7oFcs IotaVgE87HV6kvXiGGfoi7TN/aU9/LD+3Bcl6VDdR6/auvqdLM61nUJt0WtUOY/M 6yCVb2rYgo5AqcthA2qGWEy7OpuIFpZ2D62fHFpeDiQczz3PsxTi6qKJKpHSHB70 iJA7+O4BZbEUpSpZZ9l06z2HczAP5HyUD+S0mdwSiZpJsXAII/2xS6/cbNhDP4XM VWTizV47OjSV3SWbAa41KU67dSTkD6XrKgbq30LyxreVdxFeAO4DDkGArCmjPnOZ ozPTBoI+TyNFodvJSmedMFIrovKNV6BQFyrNpFFwfZ3xMRuTqK2FzjJf4DUf8nM= =5A7C -----END PGP SIGNATURE----- --AIBeSWbv17cdPHIKEcA0N5FRBwl3rN8kc-- From nobody Sun Feb 12 17:50:49 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3225129482 for ; Sun, 12 Feb 2017 17:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hBwvVPgTSbdg for ; Sun, 12 Feb 2017 17:50:47 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7CA512946C for ; Sun, 12 Feb 2017 17:50:46 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id x49so73051633qtc.2 for ; Sun, 12 Feb 2017 17:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I+xG3QFH3feC3DOiV850GIwFOF3T8Qzf+xjCxRq0ci4=; b=aAGZVin5X0bEeG0ukAzm6C7mCRSCc7NGIA57ZHuYSjhpmP0lJFl2VEIoPHOa9Dj8+V 9x9VJUdxMQcRXXCM5vkLFNWhcl/tkKJNCM+6Svmf53/aaAVdwWkj00SGd5kLrk32qn7M 4CYZQq3mar4tIzStna05Fc5HaiwUNbkTE9HNRqvfUEPNU9gkCuMmfIIF5A+OH8M9JmfQ xbTT0V1EsHqH/pzhCLQ+z38Un+yHv8v/8C9jKLouyJi9Ap0JZqe7q2O6lBofh5zVH2Ft agtXyiPMc3k5SK3ZAaDWiDCFQ7FstayXtkYA8J178EerryyMlYHwSqU7JkbhfyjTlUuK Yp0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I+xG3QFH3feC3DOiV850GIwFOF3T8Qzf+xjCxRq0ci4=; b=iEVvLCanWT1jTbx5DmS4s/XtS/xIrIltIePqVuufm99gN6UwkQRXjT7mssJ5/Wh1ip QjOYeRa7X+whymo7DZBg85UzCd+esz6rOeAPGsl9kX8DgKEgLGT8nP8EhmwZP4+CmPLm 8MGNrHxj0SaId/O3S5h5GJA/o0pxWQHb4qY7KkkVCtDorS3Wk26zq8TkSijRonOdOOfe 9KmyltgtjnWGpuM4fzlPX/pWOkvQZcSsJQ1yzSE+Tgzy3k/AqwYhs+KIF57NUwCy+Se7 OOJcuw10L+9ZKhmGutMGKl+4sp0+mfGY7AGBkFE8PPhj7Vax6KNlsJTOUq/XNx/mxpMv 3rKw== X-Gm-Message-State: AMke39luUY77RGii8RrkEiNvwbme0fgEIjeV8UGenZueNSz+E1qLp9CjIE/69oyzs5VoM9C2c5xV9DYjOhj7geGR X-Received: by 10.237.63.28 with SMTP id p28mr18818644qtf.263.1486950645871; Sun, 12 Feb 2017 17:50:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Sun, 12 Feb 2017 17:50:15 -0800 (PST) In-Reply-To: <03eebf14-be00-911d-a388-8e18438a4ecd@cs.tcd.ie> References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> <03eebf14-be00-911d-a388-8e18438a4ecd@cs.tcd.ie> From: Warren Kumari Date: Sun, 12 Feb 2017 20:50:15 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 01:50:48 -0000 On Sun, Feb 12, 2017 at 5:31 PM, Stephen Farrell wrote: > > Hiya, > > On 12/02/17 22:27, Warren Kumari wrote: >> do you feel that we need to try and get the >> IPR statement updated? > > I not sure but if that question is addressed at me, then I > am not trying to insist that the IPR declaration be updated, > but just want to check that the WG are ok with that "later" > statement, despite it now being "much later." Sorry, nope, that was directed at the WG... I personally think that this is "OK" -- not great, but.... > >> (Remembering that, AFAIK, we cannot do anything >> other than ask nicely...) > > Yep. We can't force anyone to update a declaration and as > noted there was at least one other case where a year went > by with folks asking and not seeing any update happen in > a quite similar case involving the same entity. Yup. W > > S. > > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Sun Feb 12 18:04:18 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F40912948D for ; Sun, 12 Feb 2017 18:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r8CpLlGSkXan for ; Sun, 12 Feb 2017 18:04:15 -0800 (PST) Received: from pv35p14im-ztdg05061101.me.com (pv35p14im-ztdg05061101.me.com [17.133.187.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44CF612946C for ; Sun, 12 Feb 2017 18:04:15 -0800 (PST) Received: from process-dkim-sign-daemon.pv35p14im-ztdg05061101.me.com by pv35p14im-ztdg05061101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OLA00500IULK000@pv35p14im-ztdg05061101.me.com> for dane@ietf.org; Mon, 13 Feb 2017 02:04:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1486951454; bh=TDtiPU6f0c4ltu3W/LulHt6PlfCYrG28Iw7ixQqkHqo=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=cAkCLTzuf0NrbycXw1dCwRv3A0cWqvpZNZLG3ydpeYpJ8cRe6Le6b+JWvYHux/1Tt BdFSuUMLU4XcHa/ovZOIAEZgqzRlPcQPrHm9g3nZpNvTKywc75uFEggiEdoNg7IbeH xuh4VRFE+7g+CcrVGxwLV40g4+RUzHbC0ZaDkfYDSLWEugjE6pnrx5cXi9SxBlo23F v6NgY8QNCT8asnytG40gI9HbKPwsKgHFST/hDNWVUjjccFKzb3SZVRrxazE4RsBbJb uVQoXhf0EMvw7CuNqwCpnheJpxbYWNpuB/Y60YNaU1HKsVcR23EhYXgJ3fXXSO+y/u caKr3uDYVgeAg== Received: from icloud.com ([127.0.0.1]) by pv35p14im-ztdg05061101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OLA00KZOJ1CUT50@pv35p14im-ztdg05061101.me.com>; Mon, 13 Feb 2017 02:04:14 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-12_19:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702130019 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: D S Misell In-reply-to: Date: Mon, 13 Feb 2017 02:04:13 +0000 Content-transfer-encoding: 7bit Message-id: <97965805-D3CF-409A-BF00-C028832ED086@icloud.com> References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> <03eebf14-be00-911d-a388-8e18438a4ecd@cs.tcd.ie> To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dane@ietf.org" Subject: [dane] free wasRe: AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 02:04:16 -0000 warren, Mire give the same problem surely Yours Faithfully, David S. Misell MIET MBCS CISSP Skype misell.dave +44(0)7710380044 0207 7239135 Http://linkedin.com/in/misell Box https://db.tt/ncfgMm3J From nobody Sun Feb 12 18:10:27 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA8E12943E for ; Sun, 12 Feb 2017 18:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.587 X-Spam-Level: X-Spam-Status: No, score=-4.587 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=icloud.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKuDT3vTSz4f for ; Sun, 12 Feb 2017 18:10:25 -0800 (PST) Received: from pv35p14im-ztdg05061101.me.com (pv35p14im-ztdg05061101.me.com [17.133.187.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0ADE51288B8 for ; Sun, 12 Feb 2017 18:10:25 -0800 (PST) Received: from process-dkim-sign-daemon.pv35p14im-ztdg05061101.me.com by pv35p14im-ztdg05061101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) id <0OLA00B00J642P00@pv35p14im-ztdg05061101.me.com> for dane@ietf.org; Mon, 13 Feb 2017 02:10:24 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=4d515a; t=1486951824; bh=YvXHcEuha73SwehsvSudDKNYqaz0aI5Y/7a2ccuxgxc=; h=Content-type:MIME-version:Subject:From:Date:Message-id:To; b=fch0z3QWeDawwrvK6rPVcTuXe5M05984oLdN22RC+L9IIr2qDYsrrO6Hyh6EIEwYm TK1bl66FjwJwCAMFUWChUc9gIlKPZMRi4/Nwxk3E7DMV5M15SXiQUsJbIY++5I9X9X jWrwsuUI1T3T6TTRjPlfLFhnj1ClbsDZd4ypQEXbeTCEa0PKppssIGLFAsIju9iFuA IkPOXBt1qhipue5ysNH6k+Aq9v3oLuvciZdHObEG0XyWucqi2tZ33t64t/YR6HgvwZ rngG8Quf4Rz1R+mcy7je+E6XH1eDQ5iQC9byMpsHBUTAqGsRNxJWYQZuNt+u21Z8vR w9ZyzN5LwTkBA== Received: from icloud.com ([127.0.0.1]) by pv35p14im-ztdg05061101.me.com (Oracle Communications Messaging Server 7.0.5.38.0 64bit (built Feb 26 2016)) with ESMTPSA id <0OLA007RYJD9PD00@pv35p14im-ztdg05061101.me.com>; Mon, 13 Feb 2017 02:10:24 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-02-12_19:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1034 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1603290000 definitions=main-1702130020 Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: D S Misell In-reply-to: Date: Mon, 13 Feb 2017 02:10:21 +0000 Content-transfer-encoding: 7bit Message-id: References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> <03eebf14-be00-911d-a388-8e18438a4ecd@cs.tcd.ie> To: Warren Kumari X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dane@ietf.org" Subject: [dane] free for use was Re: AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 02:10:26 -0000 warren, Mitre give the same problem surely. Yours Faithfully, David S. Misell MIET MBCS CISSP Skype misell.dave +44(0)7710380044 0207 7239135 Http://linkedin.com/in/misell Box https://db.tt/ncfgMm3J From nobody Mon Feb 13 09:33:21 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F52B128B38 for ; Mon, 13 Feb 2017 09:33:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvbU1usxv0rH for ; Mon, 13 Feb 2017 09:33:15 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FEEE129559 for ; Mon, 13 Feb 2017 09:33:15 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id p22so8335194qka.0 for ; Mon, 13 Feb 2017 09:33:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=GiXYs9E+1Gb7503KqZ5lCZJgapIxR3OQsCttdeiU+JE=; b=hUgjXqE/NaeMzdzyMYWtBAkTIwqb5KIyIAjUS+7mnbse/nkYh2nJtrh70JvTJTNg0r Jn2GmBJf0mUQ1swjuSUi6KNCboOYwqW+JrGe/V1DKxwUWQ/vg6xCBpdtuijs5NnBMKRd xU/8h8onAHw0R3nlRfQpEx7OxlP4zGVi5u/YNRREdBlTg+D72VrCYFcR6Q+S0tx+LKBJ H4szzT8jh6uKARHdlhITC3IrXwURXRHrc9W+NI+poJ0j1Cf0LrZaN46hpi2z1XX9GdJM lnZ2EBRjJ1mUtwVrMty7zh4lpmk3EtALhOZbAXJdQkXCrNPwbecnvoUodb9kV80OeaxV V9IQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=GiXYs9E+1Gb7503KqZ5lCZJgapIxR3OQsCttdeiU+JE=; b=kkL4VSm9QwjEJf4eNK+ZzgAtPwD05aPnV/KJYaJAqvuFvMnKMrSSLwxjworzObCCY/ RQ4022HnYt+LSjQeBeV8LjQjbEQhDCFbWw3ms1pU7vjnXXz1l2w/7pXHxwrJGrcLMZzJ 1VaEvh2S62MGTKqRaSCCTctYQJu98ra/xgC699LRoLtFXXFnO8dEw81zZwqoj8HhbouN HCAMSAyFd5FIXCQCn2zMbk2OvwbnOPxcAxutked2qdQsgya+22XsLaGm/WwLtIEMYRs1 jcVpS1Vdh2ZeT+BMTr/PiRhMw1S2fEtnEvXoNzuydHpaS5nPyb4Er6H6kuc9OgFTJBiX IOOw== X-Gm-Message-State: AMke39nwiOmLEXNU6g3CEkV3teqMPrSVCyzSe0NkiyUtptcUg0/c9O09xGeetoG5fRH+bIdx6nm8YQ8g+a/pqYiI X-Received: by 10.233.239.17 with SMTP id d17mr21856185qkg.13.1487007194424; Mon, 13 Feb 2017 09:33:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Mon, 13 Feb 2017 09:32:44 -0800 (PST) In-Reply-To: References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> From: Warren Kumari Date: Mon, 13 Feb 2017 12:32:44 -0500 Message-ID: To: "dane@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 17:33:17 -0000 Dear WG. Unless you explicitly let us know that you are NOT OK with the current IPR declaration ( https://datatracker.ietf.org/ipr/2468/ ) by Thursday, we will be progressing the document. Personally I'm not thrilled with the situation, but I don't really think there is anything we can do about it... On Sun, Feb 12, 2017 at 5:27 PM, Warren Kumari wrote: > On Fri, Feb 10, 2017 at 9:28 AM, Marc Groeneweg wrote: >>>>the IPR declaration's statement that licensing information >>>>will be provided "later." >> As we had with the keyrelay draft in regext (and the draft of Peter Koch with DNSSEC transfers). > > Can you remind us what ended up happening with those two? I vaguely > remember some discussion about it being hard to get a commitment, and > that "later" seemed like a DoS on the process, but was there ever a > resolution? > > Is the WG OK with this, or do you feel that we need to try and get the > IPR statement updated? (Remembering that, AFAIK, we cannot do anything > other than ask nicely...) > > W > > >> >> >> >>> I see that Verisign has offered a free-unless-you-sue-us license for >>> other patent applications, like this one, dunno why they do for some >>> but not others: >>> >>> https://datatracker.ietf.org/ipr/2703/ >> Other than that the suggested draft is also by Verisign themselves? >> >>> In any event, you alrady know what my suggested solution is. >> >> Regards, >> Marc >> >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > > > -- > I don't think the execution is relevant when it was obviously a bad > idea in the first place. > This is like putting rabid weasels in your pants, and later expressing > regret at having chosen those particular rabid weasels and that pair > of pants. > ---maf -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Mon Feb 13 17:28:08 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9555A129506; Mon, 13 Feb 2017 17:28:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148703568260.22177.970542642891050862.idtracker@ietfa.amsl.com> Date: Mon, 13 Feb 2017 17:28:02 -0800 Archived-At: Cc: dane@ietf.org Subject: [dane] I-D Action: draft-ietf-dane-smime-15.txt X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 01:28:02 -0000 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 of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-15.txt Pages : 11 Date : 2017-02-13 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 DNS-Based Authentication of Named Entities (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: https://tools.ietf.org/html/draft-ietf-dane-smime-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-15 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 nobody Mon Feb 13 17:29:59 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6F129789 for ; Mon, 13 Feb 2017 17:29:58 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 81N4eQJFUaJd for ; Mon, 13 Feb 2017 17:29:57 -0800 (PST) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CF021294CF for ; Mon, 13 Feb 2017 17:29:57 -0800 (PST) Received: from [10.32.60.18] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v1E1SX8M042868 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 13 Feb 2017 18:28:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.18] From: "Paul Hoffman" To: "Stephen Farrell" Date: Mon, 13 Feb 2017 17:29:49 -0800 Message-ID: <4B111454-4663-466A-8AE1-7310CFC1BE4B@vpnc.org> In-Reply-To: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie> References: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5344) Archived-At: Cc: dane Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 01:29:59 -0000 On 7 Feb 2017, at 8:12, Stephen Farrell wrote: > I've done my AD review of this draft. My own comments > on the content are below (the one I'd most like to > see fixed is the "escrow" stuff) and are ok to be > handled along with other IETF LC comments. We decided to take these on now, before the IETF LC. > However, before I start IETF LC I would like to be > sure that the WG are ok with the IPR declaration [1] > filed in 2014 that said "Licensing Declaration to > be Provided Later." I think 2017 is "later" enough > to ask whether that the WG (via the chairs) explicitly > declare that they are ok that this has yet to be > clarified. Warren has stated the question explicitly, and we await the response. --Paul and Jakob ====================================================================== 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 of the IETF. Title : Using Secure DNS to Associate Certificates with Domain Names For S/MIME Authors : Paul Hoffman Jakob Schlyter Filename : draft-ietf-dane-smime-15.txt Pages : 11 Date : 2017-02-13 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 DNS-Based Authentication of Named Entities (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: https://tools.ietf.org/html/draft-ietf-dane-smime-15 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dane-smime-15 ====================================================================== > - abstract: Someone will want DANE expanded. Better to avoid > the acronym maybe. Done. > - intro: "Some people want..." is odd - that is not a > technical justification and the entire paragraph is not that > convincing. I'd say deleting that para would be better. Or > add a real justification for the experiment which I think > relates more to attempting to mitigate the difficulty of > finding certs from outside the enterprise than anything else. Many people here liked the justification, but we agree that your justification is a good one as well. Added. > - intro: I'd suggest adding a sentence about how this is > similar to RFC7929. As a reader, I'd find it odd to only find > that out later. Done. > - section 3: This is the same idea as in RFC 7929 right? > (Other than _smimecert I mean,) If so then saying so is right > as it'll help with IETF LC and IESG review and for > developers. If those differ, then saying how and why I think > would be needed. Done. > - section 4: Please check whether this is all fine when also > considering draft-ietf-lamps-eai-addresses (also in IETF LC). > That check may need to wait a little bit until we're done > with the LC comment handling for the LAMPS deraft. The current text is "all fine" with the LAMPS draft. > - Section 9: the discussion of an MTA doing the outbound > encryption seems a bit theoretical - I don't recall that > being dnoe in reality except maybe in very special cases like > nested smime, or military messaging. Am I wrong about that? Yes, you are. There have been products doing this for many years (possibly more than a decade). Having said that... > - section 9: I think the text about escrow would be better > after the current last para (where you call out the danger of > bad public keys being put in the DNS), and this (escrow) > ought be described as a special case of that attack, where > the attacker is the organisation itself. (While there are > cases where the organisation doing this is not intended as an > attack, were it done for most DNS names, it would mostly be > an attack, and is not distinguishable from an attack for the > sender, so therefore it ought IMO be considered an attack.) Yes, good call. Done. > - section 9: s/MUST not/MUST NOT/ or I-D nits complains And we must keep the tool happy, mustn't we? Done. > - section 11: I-D nits complains, maybe calling this > "normative references" would help, but in any case, please > consider/fix this. The tool is wrong, but we can fix it easily anyhow. Done. From nobody Mon Feb 13 17:34:09 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D23F12996F for ; Mon, 13 Feb 2017 17:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.302 X-Spam-Level: X-Spam-Status: No, score=-4.302 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 x-VjfU03kk-M for ; Mon, 13 Feb 2017 17:34:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E52FC129462 for ; Mon, 13 Feb 2017 17:34:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A5325BE7B; Tue, 14 Feb 2017 01:34:02 +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 Z0ipvC-RxF5E; Tue, 14 Feb 2017 01:34:01 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 87D68BE79; Tue, 14 Feb 2017 01:34:00 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487036041; bh=vAIbN6TDAdBSQgbWdPJWBlzjmQvpPHlCigMI4c8U/Eg=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=PLjup2RtEykmHi/JZZoZNmxxmNNnl68EM9ORpmxy4mLnOHqS5gXzZx8DfaVdWxCK2 m2KvJ12SdjV51zzot2ErNdQQedcc0h8d4lg00jD4ip4KommjTNBk/N4CHD8/MPMeUl /q5z/CC2etNARnxRq90YUltc7Jz8psL/uFmJDDz8= To: Paul Hoffman References: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie> <4B111454-4663-466A-8AE1-7310CFC1BE4B@vpnc.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Tue, 14 Feb 2017 01:33:59 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <4B111454-4663-466A-8AE1-7310CFC1BE4B@vpnc.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0gPnPA9tXPEjVfCjdJjRcp1XgL7WhK4Dv" Archived-At: Cc: dane Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 01:34:07 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0gPnPA9tXPEjVfCjdJjRcp1XgL7WhK4Dv Content-Type: multipart/mixed; boundary="uhBg6Ar2qpvvnCtKgCH7a2cOe0c6hU8eA"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman Cc: dane Message-ID: Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 References: <88918ddd-35c5-6759-5311-0f3e8f45be33@cs.tcd.ie> <4B111454-4663-466A-8AE1-7310CFC1BE4B@vpnc.org> In-Reply-To: <4B111454-4663-466A-8AE1-7310CFC1BE4B@vpnc.org> --uhBg6Ar2qpvvnCtKgCH7a2cOe0c6hU8eA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/02/17 01:29, Paul Hoffman wrote: > On 7 Feb 2017, at 8:12, Stephen Farrell wrote: >=20 >> I've done my AD review of this draft. My own comments >> on the content are below (the one I'd most like to >> see fixed is the "escrow" stuff) and are ok to be >> handled along with other IETF LC comments. >=20 > We decided to take these on now, before the IETF LC. And for the record, I'm fine with those changes. (Though a grammar fix may be needed, that can be done later.) Thanks, S. >=20 >> However, before I start IETF LC I would like to be >> sure that the WG are ok with the IPR declaration [1] >> filed in 2014 that said "Licensing Declaration to >> be Provided Later." I think 2017 is "later" enough >> to ask whether that the WG (via the chairs) explicitly >> declare that they are ok that this has yet to be >> clarified. >=20 > Warren has stated the question explicitly, and we await the response. >=20 > --Paul and Jakob >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >=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 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-15.txt > Pages : 11 > Date : 2017-02-13 >=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 DNS-Based Authentication of Named Entities (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: > https://tools.ietf.org/html/draft-ietf-dane-smime-15 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dane-smime-15 >=20 >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 >> - abstract: Someone will want DANE expanded. Better to avoid >> the acronym maybe. >=20 > Done. >=20 >> - intro: "Some people want..." is odd - that is not a >> technical justification and the entire paragraph is not that >> convincing. I'd say deleting that para would be better. Or >> add a real justification for the experiment which I think >> relates more to attempting to mitigate the difficulty of >> finding certs from outside the enterprise than anything else. >=20 > Many people here liked the justification, but we agree that your > justification is a good one as well. Added. >=20 >> - intro: I'd suggest adding a sentence about how this is >> similar to RFC7929. As a reader, I'd find it odd to only find >> that out later. >=20 > Done. >=20 >> - section 3: This is the same idea as in RFC 7929 right? >> (Other than _smimecert I mean,) If so then saying so is right >> as it'll help with IETF LC and IESG review and for >> developers. If those differ, then saying how and why I think >> would be needed. >=20 > Done. >=20 >> - section 4: Please check whether this is all fine when also >> considering draft-ietf-lamps-eai-addresses (also in IETF LC). >> That check may need to wait a little bit until we're done >> with the LC comment handling for the LAMPS deraft. >=20 > The current text is "all fine" with the LAMPS draft. >=20 >> - Section 9: the discussion of an MTA doing the outbound >> encryption seems a bit theoretical - I don't recall that >> being dnoe in reality except maybe in very special cases like >> nested smime, or military messaging. Am I wrong about that? >=20 > Yes, you are. There have been products doing this for many years > (possibly more than a decade). Having said that... >=20 >> - section 9: I think the text about escrow would be better >> after the current last para (where you call out the danger of >> bad public keys being put in the DNS), and this (escrow) >> ought be described as a special case of that attack, where >> the attacker is the organisation itself. (While there are >> cases where the organisation doing this is not intended as an >> attack, were it done for most DNS names, it would mostly be >> an attack, and is not distinguishable from an attack for the >> sender, so therefore it ought IMO be considered an attack.) >=20 > Yes, good call. Done. >=20 >> - section 9: s/MUST not/MUST NOT/ or I-D nits complains >=20 > And we must keep the tool happy, mustn't we? Done. >=20 >> - section 11: I-D nits complains, maybe calling this >> "normative references" would help, but in any case, please >> consider/fix this. >=20 > The tool is wrong, but we can fix it easily anyhow. Done. >=20 >=20 --uhBg6Ar2qpvvnCtKgCH7a2cOe0c6hU8eA-- --0gPnPA9tXPEjVfCjdJjRcp1XgL7WhK4Dv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYol6IAAoJEC88hzaAX42iO/IH/06dAewP29mJ4K0uZArUtGUi RMIMxWS0G5uFIZZlnV0CxUd6dskZkJ2bWHN6QL71GRT2g05qFjIo2mpYGMc1ZtRg /NtZShaLhmGu84ou5KpFtcVaaqLv7cOV2Z++04Ev19Wn5L7ll5u74M2CkMdi06EF 676BKkGlPsngKuOpWl3XP3/dssZHTbtu3SmYYMjOUceBXCTyOmG7KOuqZQ1LZcy9 fILRyuyXIt7YmRM7umdaeZ2mVRtNl+z/1vzarvCLSV6Xd0p/ZgI1Myo05eiZPV7n pTg0TV2zGLuo4bnmIGl+mkuUvFL/tQRoLanu8XMuvv215Lnm3mwXpAyUBruy6/4= =hW3z -----END PGP SIGNATURE----- --0gPnPA9tXPEjVfCjdJjRcp1XgL7WhK4Dv-- From nobody Fri Feb 17 09:02:29 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8541D1294FB for ; Fri, 17 Feb 2017 09:02:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 AN86KEHQIBbz for ; Fri, 17 Feb 2017 09:02:25 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5715E1293F9 for ; Fri, 17 Feb 2017 09:02:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 10CA0BE77; Fri, 17 Feb 2017 17:02:24 +0000 (GMT) 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 bRZ2-oJipNA7; Fri, 17 Feb 2017 17:02:23 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 8092BBE51; Fri, 17 Feb 2017 17:02:23 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1487350943; bh=mA9Jx7np0PYbZlY6oULh8Qsjayq5KP9mKtwgQ9ZeEzI=; h=Subject:To:References:From:Date:In-Reply-To:From; b=tpqWlsd5WO86Goc8Ch/DVpIJhKkJm7cvAaKTRgOhBGMo4Tid4C9lwf0lS5eaHHvS+ Qxwe+7SfPTRsjxGcJ2vTFGbCMppBF7F6pcUQRmmgfTxtF/OihgOSSo/LMUQof5JQvy s2uCkl5EWuXM9rpNi6SmYY7lLJ7nGG+yMRigm1yU= To: Warren Kumari , "dane@ietf.org" References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <0ed626d2-42dd-211e-8ea0-122555103a00@cs.tcd.ie> Date: Fri, 17 Feb 2017 17:02:23 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="QahSUfhWjbF5lxJ7hJDvv5LEkPVH6mTJC" Archived-At: Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 17:02:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QahSUfhWjbF5lxJ7hJDvv5LEkPVH6mTJC Content-Type: multipart/mixed; boundary="GqO3qXTuuDPOKvJj7n2qckfntCPsXWP6n"; protected-headers="v1" From: Stephen Farrell To: Warren Kumari , "dane@ietf.org" Message-ID: <0ed626d2-42dd-211e-8ea0-122555103a00@cs.tcd.ie> Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> In-Reply-To: --GqO3qXTuuDPOKvJj7n2qckfntCPsXWP6n Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, Thanks for checking. As I didn't see any objections, I've asked for IETF LC to be started. Cheers, S. On 13/02/17 17:32, Warren Kumari wrote: > Dear WG. >=20 > Unless you explicitly let us know that you are NOT OK with the current > IPR declaration ( https://datatracker.ietf.org/ipr/2468/ ) by > Thursday, we will be progressing the document. > Personally I'm not thrilled with the situation, but I don't really > think there is anything we can do about it... >=20 > On Sun, Feb 12, 2017 at 5:27 PM, Warren Kumari wrot= e: >> On Fri, Feb 10, 2017 at 9:28 AM, Marc Groeneweg wrote: >>>>> the IPR declaration's statement that licensing information >>>>> will be provided "later." >>> As we had with the keyrelay draft in regext (and the draft of Peter K= och with DNSSEC transfers). >> >> Can you remind us what ended up happening with those two? I vaguely >> remember some discussion about it being hard to get a commitment, and >> that "later" seemed like a DoS on the process, but was there ever a >> resolution? >> >> Is the WG OK with this, or do you feel that we need to try and get the= >> IPR statement updated? (Remembering that, AFAIK, we cannot do anything= >> other than ask nicely...) >> >> W >> >> >>> >>> >>> >>>> I see that Verisign has offered a free-unless-you-sue-us license for= >>>> other patent applications, like this one, dunno why they do for some= >>>> but not others: >>>> >>>> https://datatracker.ietf.org/ipr/2703/ >>> Other than that the suggested draft is also by Verisign themselves? >>> >>>> In any event, you alrady know what my suggested solution is. >>> >>> Regards, >>> Marc >>> >>> _______________________________________________ >>> dane mailing list >>> dane@ietf.org >>> https://www.ietf.org/mailman/listinfo/dane >> >> >> >> -- >> I don't think the execution is relevant when it was obviously a bad >> idea in the first place. >> This is like putting rabid weasels in your pants, and later expressing= >> regret at having chosen those particular rabid weasels and that pair >> of pants. >> ---maf >=20 >=20 >=20 --GqO3qXTuuDPOKvJj7n2qckfntCPsXWP6n-- --QahSUfhWjbF5lxJ7hJDvv5LEkPVH6mTJC Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYpyyfAAoJEC88hzaAX42ioR4IAKo/pkJ4J7KGWcxES5cs6Tgr hPNySOYwNa8FafGymYv3PU/T4oz3DI2ZFPjGM2eEJ10BDhJ8w/qLxHsz6np760xs FyTsi4ycGceo1IefEqoWBfOq7sNpSUAJR59gM7wyuLc6hGMjN5+bxgS6pGxWpgvW t8zmdfmMMnvDOsLYIHSSq2HS/lvs+xFgDW6EESW9eDHiAjzwXXVE0CbSrpWfGo6c jZ2dgaLUwl76sfRX3/3Xp8EUEaNlXZt4B6o/NZ/gs5TWXtUdK8H+WuQgN0arZLsg DsegkZrVhRq1uFne9BxeWwROryN7PheyZ7Vm2MBYGq2vzkAgfA2RNpF729V/Lao= =2LdE -----END PGP SIGNATURE----- --QahSUfhWjbF5lxJ7hJDvv5LEkPVH6mTJC-- From nobody Fri Feb 17 09:03:51 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C5E12951D for ; Fri, 17 Feb 2017 09:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ukXlfEWwuUyq for ; Fri, 17 Feb 2017 09:03:48 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C801293F9 for ; Fri, 17 Feb 2017 09:03:48 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id k15so45461607qtg.3 for ; Fri, 17 Feb 2017 09:03:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HbnCgCrXWM30buYAvhQtbbnrVntxu1hOLA64zQstGQg=; b=k/Wy/1TPLSznSOcz2+S6ZIPk2Xn/hpPj9na7jcATNLdPSSTv/FGQpYKh3RtYh8pJtN TEpGqNuU9xbvthMPwUVIRsQgD5dLdLji4Qi9E1NxZONeNT/0IPJS7gMEJB10xQ/6T1c5 o+I9HE60N9UD2h+dI1Q7lQScE5jp0Jd+r5S26Q5jgWY2gLBzgHFlK1TCS8NPy+vc5F96 sNzaCcEeiIskqHETx9sShKeToq9u1fuYWuZ3m9jfi07wfRETxPJsvQ8rJiFazYrWBBMQ glLf9+3rnb+k2BPEcKp++rG3vN8IxWP5orULOlb0O9XE8By5+1msswTBBcBhx3xzFiZ5 w1Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HbnCgCrXWM30buYAvhQtbbnrVntxu1hOLA64zQstGQg=; b=c9RZ0K1syrBoGfdLuHeYQUFxOb3xsJMlRkKXb+/K3U4fxnrvld17jD43PDEJLZsk7P ltuvCEpomxvJLVyTwkJHriRIMFS/1ZAKwS0hmgLRsvDvyCZOBjoWyJz0IEvtgE16ctyU kCr0j1uLyiAbzp7StT4yyIhHOQR5nm6YCC9FmdzAiMukfp0ydwvw+t1r508YEan/kg1A a5yRysm2LGZleaso6Y57iUhrh8vgWZczD/P6JAawIOKx+EjlD12a5nQCTpqLClmVXtet fzPSmOi9L3ChwfDNhjOl18MiEdRXWfeodpaN7GRAauE8DiSMvEOcV0HRFf9jwBo6yG4U 7DvQ== X-Gm-Message-State: AMke39lCkwF8TPSGH4XSXalpi2iS5TXZlulPX3+KsMjqhRNavigRiVtQ3g0FKm/Gbnqh95ycGidTilwOlKlWYjPb X-Received: by 10.200.36.41 with SMTP id c38mr8873510qtc.57.1487351027290; Fri, 17 Feb 2017 09:03:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.179.19 with HTTP; Fri, 17 Feb 2017 09:03:16 -0800 (PST) In-Reply-To: <0ed626d2-42dd-211e-8ea0-122555103a00@cs.tcd.ie> References: <20170209041739.17865.qmail@ary.lan> <22938E71-2963-4C6B-BE94-16C7E30FBFD0@sidn.nl> <0ed626d2-42dd-211e-8ea0-122555103a00@cs.tcd.ie> From: Warren Kumari Date: Fri, 17 Feb 2017 12:03:16 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] AD review of draft-ietf-dane-smime-14 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 17 Feb 2017 17:03:50 -0000 Thank you. W On Fri, Feb 17, 2017 at 12:02 PM, Stephen Farrell wrote: > > Hiya, > > Thanks for checking. As I didn't see any objections, I've > asked for IETF LC to be started. > > Cheers, > S. > > On 13/02/17 17:32, Warren Kumari wrote: >> Dear WG. >> >> Unless you explicitly let us know that you are NOT OK with the current >> IPR declaration ( https://datatracker.ietf.org/ipr/2468/ ) by >> Thursday, we will be progressing the document. >> Personally I'm not thrilled with the situation, but I don't really >> think there is anything we can do about it... >> >> On Sun, Feb 12, 2017 at 5:27 PM, Warren Kumari wrote: >>> On Fri, Feb 10, 2017 at 9:28 AM, Marc Groeneweg wrote: >>>>>> the IPR declaration's statement that licensing information >>>>>> will be provided "later." >>>> As we had with the keyrelay draft in regext (and the draft of Peter Koch with DNSSEC transfers). >>> >>> Can you remind us what ended up happening with those two? I vaguely >>> remember some discussion about it being hard to get a commitment, and >>> that "later" seemed like a DoS on the process, but was there ever a >>> resolution? >>> >>> Is the WG OK with this, or do you feel that we need to try and get the >>> IPR statement updated? (Remembering that, AFAIK, we cannot do anything >>> other than ask nicely...) >>> >>> W >>> >>> >>>> >>>> >>>> >>>>> I see that Verisign has offered a free-unless-you-sue-us license for >>>>> other patent applications, like this one, dunno why they do for some >>>>> but not others: >>>>> >>>>> https://datatracker.ietf.org/ipr/2703/ >>>> Other than that the suggested draft is also by Verisign themselves? >>>> >>>>> In any event, you alrady know what my suggested solution is. >>>> >>>> Regards, >>>> Marc >>>> >>>> _______________________________________________ >>>> dane mailing list >>>> dane@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dane >>> >>> >>> >>> -- >>> I don't think the execution is relevant when it was obviously a bad >>> idea in the first place. >>> This is like putting rabid weasels in your pants, and later expressing >>> regret at having chosen those particular rabid weasels and that pair >>> of pants. >>> ---maf >> >> >> > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Fri Feb 17 09:09:17 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E9284129A36; Fri, 17 Feb 2017 09:09:16 -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: 6.44.0 Auto-Submitted: auto-generated Precedence: bulk Sender: Message-ID: <148735135694.19996.10639905917399706253.idtracker@ietfa.amsl.com> Date: Fri, 17 Feb 2017 09:09:16 -0800 Archived-At: Cc: dane-chairs@ietf.org, draft-ietf-dane-smime@ietf.org, dane@ietf.org Subject: [dane] Last Call: (Using Secure DNS to Associate Certificates with Domain Names For S/MIME) to Experimental RFC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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: Fri, 17 Feb 2017 17:09:17 -0000 The IESG has received a request from the DNS-based Authentication of Named Entities WG (dane) to consider the following document: - 'Using Secure DNS to Associate Certificates with Domain Names For S/MIME' as Experimental RFC 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 2017-03-03. 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 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 DNS-Based Authentication of Named Entities (DANE), RFC 6698, does for TLS. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2468/ https://datatracker.ietf.org/ipr/2446/ From nobody Mon Feb 20 14:08:32 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E32C11293DC for ; Mon, 20 Feb 2017 14:08:30 -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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ILUVYIw9-uUy for ; Mon, 20 Feb 2017 14:08:29 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EA4B12706D for ; Mon, 20 Feb 2017 14:08:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 3FAEB30042F for ; Mon, 20 Feb 2017 17:08:28 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id kwED7pm91xDs for ; Mon, 20 Feb 2017 17:08:27 -0500 (EST) Received: from russhousleymbp.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 1E63C3002B9; Mon, 20 Feb 2017 17:08:27 -0500 (EST) From: Russ Housley Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_F480C90B-B149-4041-AD77-D53539ED048C"; protocol="application/pkcs7-signature"; micalg=sha1 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Date: Mon, 20 Feb 2017 17:08:26 -0500 In-Reply-To: <148735135694.19996.10639905917399706253.idtracker@ietfa.amsl.com> To: IETF References: <148735135694.19996.10639905917399706253.idtracker@ietfa.amsl.com> X-Mailer: Apple Mail (2.3259) Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Last Call: (Using Secure DNS to Associate Certificates with Domain Names For S/MIME) to Experimental RFC X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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 Feb 2017 22:08:31 -0000 --Apple-Mail=_F480C90B-B149-4041-AD77-D53539ED048C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I just took a look at this document, and I think it is ready for = publication as an Experimental RFC. Russ > On Feb 17, 2017, at 12:09 PM, The IESG = wrote: >=20 >=20 > The IESG has received a request from the DNS-based Authentication of > Named Entities WG (dane) to consider the following document: > - 'Using Secure DNS to Associate Certificates with Domain Names For > S/MIME' > as Experimental RFC >=20 > 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 2017-03-03. 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. >=20 > Abstract >=20 >=20 > 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 DNS-Based Authentication of Named Entities (DANE), RFC 6698, > does for TLS. >=20 >=20 >=20 >=20 > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ >=20 > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dane-smime/ballot/ >=20 > The following IPR Declarations may be related to this I-D: >=20 > https://datatracker.ietf.org/ipr/2468/ > https://datatracker.ietf.org/ipr/2446/ >=20 >=20 >=20 >=20 >=20 --Apple-Mail=_F480C90B-B149-4041-AD77-D53539ED048C Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJ9zCCBK8w ggOXoAMCAQICEQDgI8sVEoNTia1hbnpUZ2shMA0GCSqGSIb3DQEBCwUAMG8xCzAJBgNVBAYTAlNF MRQwEgYDVQQKEwtBZGRUcnVzdCBBQjEmMCQGA1UECxMdQWRkVHJ1c3QgRXh0ZXJuYWwgVFRQIE5l dHdvcmsxIjAgBgNVBAMTGUFkZFRydXN0IEV4dGVybmFsIENBIFJvb3QwHhcNMTQxMjIyMDAwMDAw WhcNMjAwNTMwMTA0ODM4WjCBmzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hl c3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNV BAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWls IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAibEN2npTGU5wUh28VqYGJre4SeCW 51Gr8fBaE0kVo7SMG2C8elFCp3mMpCLfF2FOkdV2IwoU00oCf7YdCYBupQQ92bq7Fv6hh6kuQ1JD FnyvMlDIpk9a6QjYz5MlnHuI6DBk5qT4VoD9KiQUMxeZrETlaYujRgZLwjPU6UCfBrCxrJNAubUI kzqcKlOjENs9IGE8VQOO2U52JQIhKfqjfHF2T+7hX4Hp+1SA28N7NVK3hN4iPSwwLTF/Wb1SN7Az aS1D6/rWpfGXd2dRjNnuJ+u8pQc4doykqTj/34z1A6xJvsr3c5k6DzKrnJU6Ez0ORjpXdGFQvsZA P8vk4p+iIQIDAQABo4IBFzCCARMwHwYDVR0jBBgwFoAUrb2YejS0Jvf6xCZU7wO94CTLVBowHQYD VR0OBBYEFJJha4LhoqCqT+xn8cKj97SAAMHsMA4GA1UdDwEB/wQEAwIBhjASBgNVHRMBAf8ECDAG AQH/AgEAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBgNVHSAECjAIMAYGBFUdIAAw RAYDVR0fBD0wOzA5oDegNYYzaHR0cDovL2NybC51c2VydHJ1c3QuY29tL0FkZFRydXN0RXh0ZXJu YWxDQVJvb3QuY3JsMDUGCCsGAQUFBwEBBCkwJzAlBggrBgEFBQcwAYYZaHR0cDovL29jc3AudXNl cnRydXN0LmNvbTANBgkqhkiG9w0BAQsFAAOCAQEAGypurFXBOquIxdjtzVXzqmthK8AJECOZD8Vm am+x9bS1d14PAmEA330F/hKzpICAAPz7HVtqcgIKQbwFusFY1SbC6tVNhPv+gpjPWBvjImOcUvi7 BTarfVil3qs7Y+Xa1XPv7OD7e+Kj//BCI5zKto1NPuRLGAOyqC3U2LtCS5BphRDbpjc06HvgARCl nMo6x59PiDRuimXQGoq7qdzKyjbR9PzCZCk1r9axp3ER0gNDsY8+muyeMlP0dpLKhjQHuSzK5hxK 2JkNwYbikJL7WkJqIyEQ6WXH9dW7fuqMhSACYurROgcsWcWZM/I4ieW26RZ6H3kU9koQGib6fIr7 mzCCBUAwggQooAMCAQICEQCzIsUuKpsHVq2Oiy2wXwvCMA0GCSqGSIb3DQEBCwUAMIGbMQswCQYD VQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxmb3JkMRow GAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UEAxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50 IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwgQ0EwHhcNMTYwMzMxMDAwMDAwWhcNMTcw MzMxMjM1OTU5WjAlMSMwIQYJKoZIhvcNAQkBFhRob3VzbGV5QHZpZ2lsc2VjLmNvbTCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAOQwBbNVXhmLbyClWrRBX0GdNQFhVHEpbzM4tr5pdd0q rPp8i+6qqNa4dAbJT6kodJ/LgsBi5EN3li4MJOIlf3rCsK1/VXepRwqUoc1cZfLRGdEj/4zgwrNZ ULvOFiDIvYkAYDWRlYnEXulWr3KriOApHpfzbQvHStU1YsV762AIHVbZUW5tlTC9LfI8r+PIBFzv Y5ujoUnSAgKgeE8gDK9yAxemrQ6wzDpwaf5PxEVnw0gOC2jtDojdzhoQfz57MFrL9pA1QyMbnItV zCYfc5J7EfeCGupcFqwXytbJHSYPfLfM1/3omGgCGD/DZk4z4SUVC19k02iGxAIVDsWJ5oMCAwEA AaOCAfIwggHuMB8GA1UdIwQYMBaAFJJha4LhoqCqT+xn8cKj97SAAMHsMB0GA1UdDgQWBBTrsV85 Y7qY6oVPF5xRd+wqIu3VJTAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAX BggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYM KwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BT MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0NPTU9ET1NIQTI1NkNs aWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5jcmwwgZAGCCsGAQUFBwEBBIGDMIGA MFgGCCsGAQUFBzAChkxodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9DT01PRE9TSEEyNTZDbGllbnRB dXRoZW50aWNhdGlvbmFuZFNlY3VyZUVtYWlsQ0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2Nz cC5jb21vZG9jYS5jb20wHwYDVR0RBBgwFoEUaG91c2xleUB2aWdpbHNlYy5jb20wDQYJKoZIhvcN AQELBQADggEBACgHw+/VeC7LgLJs19KZ6Ds2cW+jLSPjA3AIqSxiQ+uyDFwe6FujBUqRCXfla0qg MzbhJ+1uSxcaktsS5idpB5Dfp8SVEGLcjtSJwWVlEofjaRrx6pi2mzazQwfKklY/epvsgnCoY8KW FeSGkpbQXu5WrIL18EFqMCHqDiu5/P49PcZnJRv2xHTi5CkIsI7XgOw4FazS3xuJMVQ5TVtIUeMW OqRlNJaeTiBsOVauS3FE/zRejsAYhHp3EV1PZFhV6hdcK/8qKrqRBtZtsEIm2FNWNsk8p/3RmUQl 4n4qN/NvapmXyYqfHZiuxf2g8H/WHF8IlVDzljLy90Uy0X7Qp0gxggPGMIIDwgIBATCBsTCBmzEL MAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8L wjAJBgUrDgMCGgUAoIIB6TAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xNzAyMjAyMjA4MjZaMCMGCSqGSIb3DQEJBDEWBBRsZtaYQUsp2afd3Q+P2K1wLaH96zCBwgYJ KwYBBAGCNxAEMYG0MIGxMIGbMQswCQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVz dGVyMRAwDgYDVQQHEwdTYWxmb3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDFBMD8GA1UE AxM4Q09NT0RPIFNIQS0yNTYgQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUgRW1haWwg Q0ECEQCzIsUuKpsHVq2Oiy2wXwvCMIHEBgsqhkiG9w0BCRACCzGBtKCBsTCBmzELMAkGA1UEBhMC R0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxQTA/BgNVBAMTOENPTU9ETyBTSEEtMjU2IENsaWVudCBBdXRo ZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhEAsyLFLiqbB1atjostsF8LwjANBgkqhkiG 9w0BAQEFAASCAQAbS20DETc4esaiJaDMRA33jpg1Lc9cYoKxmgKAd1A17tGDBZQana3Q2boje7j7 0JpSb9h1+aUPRQC23S4HmD7F7QRK0HHkakh98P5Lhk3zM/eIFB+PLd5xLSHxpE3HEjQiT1HuPcpM 6i8lBGLfgJJn+ohKDCEbv05rxWue1gMLYH33xfeXgqpExTEBc0tiq1XUJX27MqJJRe+beGu6joq1 dtca8Q4a3LyHG1xuTu+PmLbzj0PS77Y1FIwDFWNs8BJEGJmEKVx2XlDaBQTPDrLcC4UgON/kHG1j XwOc8H+bQu+BcXNPBS8CShX+9/MiUiyCMg3E6OuIYzakBgXbE6DGAAAAAAAA --Apple-Mail=_F480C90B-B149-4041-AD77-D53539ED048C-- From nobody Sun Feb 26 06:10:51 2017 Return-Path: X-Original-To: dane@ietf.org Delivered-To: dane@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DDBFC129960; Sun, 26 Feb 2017 06:10:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Dale Worley To: X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> Date: Sun, 26 Feb 2017 06:10:47 -0800 Archived-At: Cc: draft-ietf-dane-smime.all@ietf.org, ietf@ietf.org, dane@ietf.org Subject: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 26 Feb 2017 14:10:48 -0000 Reviewer: Dale Worley Review result: Ready with Nits I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at . Document: draft-ietf-dane-smime-15 Reviewer: Dale R. Worley Review Date: 2017-02-26 IETF LC End Date: 2017-03-03 IESG Telechat date: 2017-03-16 Summary: This draft is basically ready for publication, but has nits that should be fixed before publication. * Technical points 1. I assume that in parallel with RFC 6698, DNAME records must be followed during SMIMEA resolution. It's not clear to me whether CNAME records must also be followed or how, given that SNAMEA records are not for host names, but their grandparent node is a host name. 2. Presumably it was deliberate not to have the first label for an SNAMEA record be the canonical UTF-8 string for the local-part, even though the DNS architecture (RFC 1035) seems to admit binary labels. 3. Presumably it was deliberate to hash using SHA2-256 truncated to 224 bits rather than use SHA-224. 4. Is it worth suggesting that some mechanism might be devised for annotating an e-mail message with the canonical form of the sender's local-part that is intended to be used to authenticate the message? The last sentence of the 1st paragraph of section 1 suggests that this is deliberately out of scope for this document, but it might be worth suggesting experimentation regarding this in section 4, which seems to be entirely about further experimentation. * Editorial/Nits Should there be an explicit statement that the resolver must follow CNAME and DNAME records? That seems to be required by RFC 6698 section A.2.1, but that requirement is buried rather deeply. Also, is CNAME following required? My vague understanding is that CNAME can only be used to alias host names, and SMIMEA records are not for host names (contrasting with the DANE records for TLS) -- though the grandparent node of any SNAMEA is a host name. Also, some adjustments of the resolution process of RFC 6698 re CNAME records were made in RFC 7671, but this draft only mentions 7671 in passing, in the introduction. It seems that it should be noted that 7671 contains a lot of operational information about DANE. 1. Introduction There are other requirements on the MUA, such as associating the identity in the certificate with that of the message, that are out of scope for this document. "that of the message" isn't quite right, as "that" is parallel to "the identity", and the message doesn't itself have an identity. More accurate would be "the purported sender of the message", as was used in 3rd sentence of the paragraph. 2. The SMIMEA Resource Record ... the semantics are also the same except where RFC 6698 talks about TLS at the target protocol for the certificate information. s/TLS at/TLS as/ 3. Location of the SMIMEA Record The DNS does not allow the use of all characters that are supported in the "local-part" of email addresses as defined in [RFC5322] and [RFC6530]. I don't have the full background on this. My memory ends at RFC 1035: Although labels can contain any 8 bit values in octets that make up a label, it is strongly recommended that labels follow the preferred syntax described elsewhere in this memo, which is compatible with existing host naming conventions. I suspect there is by now a defined way to have "UTF-8 labels". Given that this draft doesn't use such a mechanism, there's probably a discussion out there why just using a UTF-8 string as a label doesn't work. It would be helpful to put a reference to that discussion here, because the mechanism in the draft is doing a lot of work to avoid the seemingly obvious mechanism. 2. The local-part is first canonicalized using the following rules. If the local-part is unquoted, any whitespace (CFWS) around dots (".") is removed. Any enclosing double quotes are removed. Any literal quoting is removed. I think this could be more exactly expressed along the following lines. Given the costs of not having this implemented exactly the same way in all implementations, it's probably worth the extra words. 2. The local-part is first canonicalized using the following rules. If the local-part is unquoted, any whitespace (CFWS) around dots (".") is removed. If the local-part is quoted, the enclosing double quotes, contained FWS, and the initial backslashes of quoted-pairs are removed. (The obsolete local-part format obs-local-part is canonicalized similarly: CFWS around dots is removed and any word component that is a quoted-string is canonicalized as if it was a separate local-part.) -- 4. The local-part is hashed using the SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets and represented in its hexadecimal representation, to become the left-most label in the prepared domain name. Why use "SHA2-256 [RFC5754] algorithm, with the hash truncated to 28 octets" rather than "SHA2-224 [RFC5754]"? (The two aren't the same, because SHA-224 has a different IV than SHA2-256, but they seem to have the same security properties.) Is this because implementations will already implement SHA2-256 (for matching type 1)? You probably want to specify hexadecimal case here. DNS is considered to be case-insensitive, but it's probably unwise to depend on that fact. (Or is this known not to be a problem in DNS?) 7. Certificate Size and DNS The algorithm type and key size of certificates should not be modified to accommodate this section. The term "algorithm type" is not defined; what is meant here? Also, "of certificates" seems awkward; the encryption/signing algorithms and keys exist prior to the certificate which vouches for them. Perhaps: A user's S/MIME encryption/signing algorithms and keys should not be changed solely to reduce DNS RR sizes. 9. Security Considerations If an obtained S/MIME certificate is revoked or expired, that certificate MUST NOT be used, even if that would result in sending a message in plaintext. Shouldn't this be moved to section 6? This seems to be a specification, but it is not contained in the definition of the semantics. The "security considerations" section is where you would see the explanation of the reason for this specification. [END] From worley@alum.mit.edu Sun Feb 26 16:44:44 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89FDA1294E1 for ; Sun, 26 Feb 2017 16:44:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.933 X-Spam-Level: X-Spam-Status: No, score=-1.933 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvxpqXIHzZAr for ; Sun, 26 Feb 2017 16:44:44 -0800 (PST) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E30F5129A2A for ; Sun, 26 Feb 2017 16:44:42 -0800 (PST) Received: from resomta-po-15v.sys.comcast.net ([96.114.154.239]) by resqmta-po-07v.sys.comcast.net with SMTP id i9QgcW9AEO8Emi9Qgcftu7; Mon, 27 Feb 2017 00:44:42 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-15v.sys.comcast.net with SMTP id i9QecmVNWPFGLi9QfcMk9q; Mon, 27 Feb 2017 00:44:42 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1R0iedr001364; Sun, 26 Feb 2017 19:44:40 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1R0idYL001361; Sun, 26 Feb 2017 19:44:39 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: gen-art@ietf.org, draft-ietf-dane-smime.all@ietf.org, ietf@ietf.org, dane@ietf.org In-Reply-To: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Sun, 26 Feb 2017 19:44:39 -0500 Message-ID: <87innwmphk.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfJAil5laMlQoI7AP1qZuHwqg5jLsSsUL1K2Ow0SNFoDlRfczxl73mYvnFRc/cOJfaQhysCFkoVkD/YJI/Z2KT5sg0NDFI1nWUOA/kx8dRm/MOAPe2JRL FSgRBac5rdEJDzqILr3mola625uX/msiC2/GFhkRmX66pt4O8WVRka6WSm3ZL7uC/LY7IFtn9tKlIfnFd3a95tzi2QLilR9Js1++xL1/gLLLKUoEdmo9/k7p dY/0mshlajXHLI3/LO5t5A== Archived-At: Subject: Re: [dane] [Gen-art] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 19:20:14 -0000 Dale Worley in his review: > 2. Presumably it was deliberate not to have the first label for an > SNAMEA record be the canonical UTF-8 string for the local-part, even > though the DNS architecture (RFC 1035) seems to admit binary labels. > 3. Location of the SMIMEA Record > > The DNS does not allow the use of all characters that are supported > in the "local-part" of email addresses as defined in [RFC5322] and > [RFC6530]. > > I don't have the full background on this. My memory ends at RFC > 1035: > > Although labels can contain any 8 bit values in octets that make up a > label, it is strongly recommended that labels follow the preferred > syntax described elsewhere in this memo, which is compatible with > existing host naming conventions. > > I suspect there is by now a defined way to have "UTF-8 labels". Given > that this draft doesn't use such a mechanism, there's probably a > discussion out there why just using a UTF-8 string as a label doesn't > work. It would be helpful to put a reference to that discussion here, > because the mechanism in the draft is doing a lot of work to avoid the > seemingly obvious mechanism. >From draft-ietf-dane-smime-15: > 9.2. Email Address Information Leak > > The hashing of the local-part in this document is not a security > feature. Publishing SMIMEA records will create a list of hashes of > valid email addresses, which could simplify obtaining a list of valid > email addresses for a particular domain. It is desirable to not ease > the harvesting of email addresses where possible. > > The domain name part of the email address is not used as part of the > hash so that hashes can be used in multiple zones deployed using > DNAME [RFC6672]. This makes it slightly easier and cheaper to brute- > force the SHA2-256 hashes into common and short local-parts, as > single rainbow tables [Rainbow] can be re-used across domains. This > can be somewhat countered by using NSEC3. After thinking about this more, it seems to me that the draft is suffering from conflicting requirements. On one hand, it wants to not have the SMIMEA records provide a complete list of local-parts for the domain name. On the other hand, simply hashing the local-parts does not provide enough protection of the local-parts because one dictionary can be used to attack every domain that uses SMIMEA. And hashing the local-parts with the domain name makes it impossible to present the same set of SMIMEA records for several domain names (that are e-mail equivalent) using DNAME records. This, I think, leads to justifying using hashes as labels for the RRs even though the local-parts are encoded in UTF-8, and could be used as labels themselves. It seems to me the way out of this conflict is to salt the hashes of the local-parts. That is, each domain has a salt value of e.g. 128 bits (16 octets) which is hashed with the local-part to produce the label for the RR. The natural way to distribute the salt is in an RR attached to the _smimecert domain (which ensures that several domains can use DNAME to redirect to one tree of SMIMEA records), and it seems that an easy way to do that is to use an SMIMEA RR with another "certificate usage" value (presumably 4) to specify that the "certificate association data" field holds the salt value: $origin example.com. ; salt _smimecert IN SMIMEA 4 0 0 0f215f3ab4a8bd21b831c8316379d5b0 ; hugh@example.com 51dfb169b7e8f5eeb4c853bf2cc2d9481cb6e9f3bd156afeb3b1cf42._smimecert ( IN SMIMEA 0 0 1 d2abde240d7cd3ee6b4b28c54df034b97983a1d16e8a410e4561cb106618e971 ) It would even be upward-compatible from the current system if we defined that if there was no SMIMEA record for the _smimecert domain, then the hash is unsalted. Dale From nobody Mon Feb 27 11:26:30 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC23312A2FB for ; Mon, 27 Feb 2017 11:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 2WHEuZoLD0nv for ; Mon, 27 Feb 2017 11:26:22 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 277DB12A2FC for ; Mon, 27 Feb 2017 11:26:22 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vXBXB12dcz1rV; Mon, 27 Feb 2017 20:26:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488223578; bh=dbl4gTVd9uFSJGrs3Bc2W8B16pbj0TThPw0hG+qW8lM=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=djoHRvr5UC/zjaVlN/TYh/ck7Wxh3DGCXNowycNEHPWcHHgZtD6zQ2JW5CUnU8QSW eeMM4BVr0wu0N8OYESupzWIjiLKA456S20M82qbwvzZ1AqhT9C0agDeZJriEjDAizt qurQ8Cf1i0d3RETcYjwWaEgGoL6sWnU4xpaC0I/A= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id IpdW0w2MHADp; Mon, 27 Feb 2017 20:26:15 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Mon, 27 Feb 2017 20:26:15 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 45FDE3F2854; Mon, 27 Feb 2017 14:26:14 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 45FDE3F2854 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 30FFB4168D4D; Mon, 27 Feb 2017 14:26:14 -0500 (EST) Date: Mon, 27 Feb 2017 14:26:13 -0500 (EST) From: Paul Wouters To: Dale Worley In-Reply-To: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> Message-ID: References: <148811824790.2888.13003369227902377285.idtracker@ietfa.amsl.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dane WG list Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 27 Feb 2017 19:26:28 -0000 On Sun, 26 Feb 2017, Dale Worley wrote: I'm not an author but I am the author of the similar OPENPGPKEY RFC-7929 which actually went through all the discussion on the same matters you raise. The smime draft waited for that discussion to finish and for 7929 to be published so it could re-use the same text and methods. > 1. I assume that in parallel with RFC 6698, DNAME records must be > followed during SMIMEA resolution. It's not clear to me whether > CNAME > records must also be followed or how, given that SNAMEA records are > not for host names, but their grandparent node is a host name. Regular processing rules for CNAME and DNAME apply - I don't think it requires additional text. > 2. Presumably it was deliberate not to have the first label for an > SNAMEA record be the canonical UTF-8 string for the local-part, even > though the DNS architecture (RFC 1035) seems to admit binary labels. Yes, you can find 100+ messages in the archive or you can listen to a few hours of heated debate at some of the previous DANE IETF meetings. (So heated in fact, that I'm not even comfortable giving you a 1 line summary) > 3. Presumably it was deliberate to hash using SHA2-256 truncated to > 224 > bits rather than use SHA-224. Yes, the Microsoft crypto api lacks support for SHA-224. We did want the shorter length so SHA256 truncated was chosen. > 4. Is it worth suggesting that some mechanism might be devised for > annotating an e-mail message with the canonical form of the sender's > local-part that is intended to be used to authenticate the message? The SMTP people raised strong objections about interpreting anything as this is forbidden by the SMTP specifications. You will also find dozens of messags and recordings of meetings in the archive that lead to the current compromise text (which was also used in OPENPGPKEY, RFC-7929) > The last sentence of the 1st paragraph of section 1 suggests that > this > is deliberately out of scope for this document, but it might be worth > suggesting experimentation regarding this in section 4, which seems > to be entirely about further experimentation. I don't think you will find anyone willing to restart that battle. > * Editorial/Nits > > Should there be an explicit statement that the resolver must follow > CNAME and DNAME records? That seems to be required by RFC 6698 > section A.2.1, but that requirement is buried rather deeply. Also, > is > CNAME following required? My vague understanding is that CNAME can > only be used to alias host names, and SMIMEA records are not for host > names (contrasting with the DANE records for TLS) -- though the > grandparent node of any SNAMEA is a host name. CNAMEs can be used for most RRTYPEs (excluding NS, SOA, CNAMEs) and it might be that people will have multiple email addresses where they want to prevent duplicating long blobs of certificates in a zonefile. So CNAMEs are very useful. > Also, some adjustments of the resolution process of RFC 6698 re CNAME > records were made in RFC 7671, but this draft only mentions 7671 in > passing, in the introduction. It seems that it should be noted that > 7671 contains a lot of operational information about DANE. The bulk of that relates to the TLSA record, which doesn't apply here. Paul From nobody Tue Feb 28 12:33:50 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0FB1296D7 for ; Tue, 28 Feb 2017 12:33:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGGcV4qwFRRT for ; Tue, 28 Feb 2017 12:33:48 -0800 (PST) Received: from resqmta-po-05v.sys.comcast.net (resqmta-po-05v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E77D1296D6 for ; Tue, 28 Feb 2017 12:33:48 -0800 (PST) Received: from resomta-po-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-05v.sys.comcast.net with SMTP id ioR3clNY9y20uioSwceipr; Tue, 28 Feb 2017 20:33:46 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-14v.sys.comcast.net with SMTP id ioStcATmlBKYlioSucYtyh; Tue, 28 Feb 2017 20:33:45 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1SKXhnq010454; Tue, 28 Feb 2017 15:33:43 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1SKXghb010451; Tue, 28 Feb 2017 15:33:42 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: Paul Wouters In-Reply-To: (paul@nohats.ca) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 28 Feb 2017 15:33:42 -0500 Message-ID: <87r32ijbrt.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfEiDJWThwBXJnBSSjWxTABaorMi0S8bt98FNrjMSs6zkkIh0uxIMDbVYmOC1mC4qn4cl4hd6sD9HiAUTyesinFG4UPpYXSZt1RsnrSWdwifqcymqog2h 90+KdWBC5Ty+tTIfkhuTm33c6qT7e8orhT36uzpM6xGX0csLRYgLtRYh2U/HKRaSsxXFHAHCzrugzQ== Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 20:33:49 -0000 Paul Wouters writes: > Regular processing rules for CNAME and DNAME apply - I don't think it > requires additional text. OK, I've used CNAME records but wasn't that familiar with the specifications. After reading in the RFCs, it looks like resolvers are requied to follow CNAME and DNAME records, so those are invisible at the application level. >> 2. Presumably it was deliberate not to have the first label for an >> SNAMEA record be the canonical UTF-8 string for the local-part, even >> though the DNS architecture (RFC 1035) seems to admit binary labels. > > Yes, you can find 100+ messages in the archive or you can listen to > a few hours of heated debate at some of the previous DANE IETF > meetings. (So heated in fact, that I'm not even comfortable giving > you a 1 line summary) "Here be dragons." Well enough. Actually, I thought about this issue some more, and that led to my followup e-mail. I think there is a real desire to not have the DNS provide a direct catalog of valid e-mail addresses, but it conflicts with the weak security of non-salted hashes. As I said in that e-mail, I think this could be improved by providing a hash in a DNS record, which would mean that hashes would be well-justified as providing substantially more privacy/security than direct UTF-8 (or base64 or anything reversible). >> 3. Presumably it was deliberate to hash using SHA2-256 truncated to >> 224 >> bits rather than use SHA-224. > > Yes, the Microsoft crypto api lacks support for SHA-224. We did want > the shorter length so SHA256 truncated was chosen. That makes sense. >> 4. Is it worth suggesting that some mechanism might be devised for >> annotating an e-mail message with the canonical form of the sender's >> local-part that is intended to be used to authenticate the message? > > The SMTP people raised strong objections about interpreting anything > as this is forbidden by the SMTP specifications. You will also find > dozens of messags and recordings of meetings in the archive that lead > to the current compromise text (which was also used in OPENPGPKEY, RFC-7929) "Here be dragons." Though I was thinking of a message header, not a feature of SMTP. But no doubt people will start experimenting with that anyway. Dale From nobody Tue Feb 28 12:39:56 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B02EF1296DF for ; Tue, 28 Feb 2017 12:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e3aU8lo2jHP7 for ; Tue, 28 Feb 2017 12:39:49 -0800 (PST) Received: from resqmta-po-12v.sys.comcast.net (resqmta-po-12v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:171]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 308101296D2 for ; Tue, 28 Feb 2017 12:39:49 -0800 (PST) Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-12v.sys.comcast.net with SMTP id ioXMcncFCCGpRioYmc8FcY; Tue, 28 Feb 2017 20:39:48 +0000 Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-po-08v.sys.comcast.net with SMTP id ioYkcRaE30ttWioYmc0mZE; Tue, 28 Feb 2017 20:39:48 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v1SKdkqF011080; Tue, 28 Feb 2017 15:39:46 -0500 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v1SKdkkJ011077; Tue, 28 Feb 2017 15:39:46 -0500 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: gen-art@ietf.org, draft-ietf-dane-smime.all@ietf.org, ietf@ietf.org, dane@ietf.org In-Reply-To: <87innwmphk.fsf@hobgoblin.ariadne.com> (worley@ariadne.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Tue, 28 Feb 2017 15:39:46 -0500 Message-ID: <87o9xmjbhp.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfCHvKlmAm3J0N85SXjYzwuFs5LxA9fegEMMe5ewUZbffN0wOGu+/m0wnbCzc03Od1KxYjGEvxgjDFYXl3zBJ2WfG/YvbppN1YevVLFRV4BhXYoWdiIlA siiXlp0JiVgIBHqMyhPJVpsin2yT2IH1oJkkYRLqLNtvVvAno1o4snp7MQNckgyKQlk0buVCk4tRn6d1Vv9ZLu8Cl0VXDCV45p0ZdDWPiwxSZrIQK4XnnA/E JIpBWqBabcG1rywvcQopCg== Archived-At: Subject: Re: [dane] [Gen-art] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 20:39:51 -0000 worley@ariadne.com (Dale R. Worley) writes: > [How about salting the hashes?] OK, this has been discussed... Dale From nobody Tue Feb 28 14:03:39 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 511061293D8 for ; Tue, 28 Feb 2017 14:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 BZf4ozULubSU for ; Tue, 28 Feb 2017 14:03:37 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40531128874 for ; Tue, 28 Feb 2017 14:03:37 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3vXszB4pbvz95; Tue, 28 Feb 2017 23:03:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1488319414; bh=AWbhUoLgfrwqKNoUM93pHTzvYbnUnySzBqh8+UQp+Ug=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=ewm6opafj/EzI1iR4gB1tY+7Gd6yWsNLFHwtz7eSDuOdyCTRKpr/uj82WK14lQZ4Z UZxTa1BNw7xVEptvE1pQbkAbQ8FbKudlYkJtjXbCwJiF4j9ALpmzuIuI8ncEp6bCuX sX1e5Ud1PV39QWTdttvnmlJOX5dBP3Cr16kuxRGs= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LoSzkOg0DMqA; Tue, 28 Feb 2017 23:03:31 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 28 Feb 2017 23:03:31 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id C07BD36A2; Tue, 28 Feb 2017 17:03:30 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca C07BD36A2 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id A8BC84168D46; Tue, 28 Feb 2017 17:03:30 -0500 (EST) Date: Tue, 28 Feb 2017 17:03:30 -0500 (EST) From: Paul Wouters To: "Dale R. Worley" In-Reply-To: <87r32ijbrt.fsf@hobgoblin.ariadne.com> Message-ID: References: <87r32ijbrt.fsf@hobgoblin.ariadne.com> User-Agent: Alpine 2.20 (LRH 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: dane@ietf.org Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 28 Feb 2017 22:03:38 -0000 On Tue, 28 Feb 2017, Dale R. Worley wrote: > Well enough. Actually, I thought about this issue some more, and that > led to my followup e-mail. I think there is a real desire to not have > the DNS provide a direct catalog of valid e-mail addresses, but it > conflicts with the weak security of non-salted hashes. As I said in > that e-mail, I think this could be improved by providing a hash in a DNS > record, which would mean that hashes would be well-justified as > providing substantially more privacy/security than direct UTF-8 (or > base64 or anything reversible). I don't think that justifies differentiating the lookups of OPENPGPKEY versus SMIMEA records. So even if I agreed with you, I think it is too late to change this. But I also do not agree :) Email addresses are not secrets. The only difference between publishing or not publishing OPENPGPKEY or SMIMEA records is that the spammer can do an offline versus an online attack. And with easilly available botnets these days, I don't think that makes any meaningful difference. Paul From nobody Tue Feb 28 21:05:49 2017 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 473D6129442 for ; Tue, 28 Feb 2017 21:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.82 X-Spam-Level: X-Spam-Status: No, score=-0.82 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_DYNAMIC=1.08, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzJ7wYmV3twR for ; Tue, 28 Feb 2017 21:05:47 -0800 (PST) Received: from miucha.iecc.com (abusenet-1-pt.tunnel.tserv4.nyc4.ipv6.he.net [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A88E12943F for ; Tue, 28 Feb 2017 21:05:47 -0800 (PST) Received: (qmail 19448 invoked from network); 1 Mar 2017 05:05:46 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 1 Mar 2017 05:05:46 -0000 Date: 1 Mar 2017 05:05:24 -0000 Message-ID: <20170301050524.1063.qmail@ary.lan> From: "John Levine" To: dane@ietf.org In-Reply-To: Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Cc: paul@nohats.ca Subject: Re: [dane] Review of draft-ietf-dane-smime-15 X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.17 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, 01 Mar 2017 05:05:48 -0000 In article you write: >On Tue, 28 Feb 2017, Dale R. Worley wrote: > >> Well enough. Actually, I thought about this issue some more, and that >> led to my followup e-mail. I think there is a real desire to not have >> the DNS provide a direct catalog of valid e-mail addresses, but it >> conflicts with the weak security of non-salted hashes. As I said in >> that e-mail, I think this could be improved by providing a hash in a DNS >> record, which would mean that hashes would be well-justified as >> providing substantially more privacy/security than direct UTF-8 (or >> base64 or anything reversible). > >I don't think that justifies differentiating the lookups of OPENPGPKEY >versus SMIMEA records. So even if I agreed with you, I think it is >too late to change this. They're experiments. I'd think it'd be useful for the experiments to see whether salted or unsalted hashes work better (or worse.) R's, John