From nobody Sun Nov 8 20:53:40 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 712011B6343 for ; Sun, 8 Nov 2015 20:53:39 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRf-725bce6Q for ; Sun, 8 Nov 2015 20:53:36 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5862C1B6341 for ; Sun, 8 Nov 2015 20:53:36 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AF0F8284D23; Mon, 9 Nov 2015 04:53:34 +0000 (UTC) Date: Mon, 9 Nov 2015 04:53:34 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20151109045334.GU18315@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Nov 2015 04:53:39 -0000 On Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huque wrote: > This work is proposed to happen in TLS, but we hope to get plenty > of feedback from DNS/DANE folks. Here's a quick summary of the major > changes in -02: > > * Updated reference newly published DANE RFCs Thanks. > * An update to the chain data format. It now uses native DNS wire > format resource records with no TLS presentation language wrapping. > This makes it easier for implementations to work with existing > DNS libraries to produce and consume the data. But we still describe > the data format in sufficient detail that implementers not using DNS > libraries can work with it. I still think this should support and use DNS compression. > * Description of how CNAME and DNAMEs are accommodated > > * Reference to use of the X.509v3 TLS Feature Extension to mandate > use of the extension by a server certificate. > > * Reference to the EDNS chain query option draft as a future easy > way to obtain/produce the chain data. > > * Removed discussion of possible client caching of chain data > components (could be difficult to get right and/or a premature > optimization). Introduction: The intent of this proposal is to allow TLS clients to perform DANE authentication [RFC6698] of a TLS server certificate without performing perform additional DNS record lookups and incurring the associated latency penalty. s/performing perform/having to perform/ It also provides the ability to avoid potential problems with TLS clients being unable to look up DANE records because of an interfering or broken middlebox on the path between the endpoint and a DNS server. s/endpoint/client/ And lastly, it allows a TLS client to validate DANE records itself without needing access to a validating DNS resolver to which it has a secure connection. It will typically not be used for general DNSSEC validation of endpoint names, but is more appropriate for validation of DANE TLSA records. Clients can already do independent validation (perhaps at higher latency cost if they don't implement a *caching* stub resolver). Furthermore, this mechanism is, at least for now, *definitely* (not just typically) restricted to carrying DANE TLSA records and their signatures. This mechanism is useful for TLS applications that need to address the problems described above, typically web browsers or VoIP and XMPP services. Are "XMPP services" applications? I would say "typically in web browsers, VOIP or XMPP clients", but we still don't know that web browsers are likely to adopt DANE however hard we try. So we can't predict which applications will take the bait, perhaps we should not try. We might however indicate what "types" of applications are in scope, and that is mobile clients for which DNSSEC is not always available on random WiFi hotspots, and latency-sensitive clients for which making multiple DNS lookups to validate a DNSSEC response is not an option (and no DNSSEC validating cache is available locally). Section 3.2 The AuthenticationChain structure is composed of a sequence of uncompressed wire format DNS resource record sets (RRset) and corresponding signatures (RRsig) records. The record sets and signatures are presented in validation order, starting at the target DANE record, followed by the DNSKEY and DS record sets for each intervening DNS zone up to a trust anchor chosen by the server, typically the DNS root. Two issues here: * Because validation order is not always possible (in presence of DNAME/CNAME indirection), it is I think best to not suggest that the records are so ordered, even in the case when such ordering is possible. To do otherwise invites sloppy implementations that don't correctly deal with replies that are unavoidably not strictly ordered. * On the other hand, the specification needs to clearly identify what the server needs to use as the *first* RRset. This can be tricky. The point is that a DANE TLSA client connects to and authenticates a what is essentially "transport endpoint", except that the network address is replaced by a DNS name. On the other hand the accepting server might be behind a NAT device of some sort, and may not even know what port the client connected to! The client's name for the service can be learned from the SNI extension, which therefore MUST be used when the proposed extension is used, and presumably the transport protocol (TCP, or UDP) is known on the server end (the server will be doing TLS or DTLS after all, and will know which). So it would seem that the client needs to communicate the target port to the server, as the payload of the proposed extension in the client HELLO (extension would no longer be empty on the client side). The server's job is then to produce a set of DNS RRsets whose first element is either: _._. IN TLSA ... or _._. IN CNAME ... in the latter case ultimately along with the TLSA records for the target of the chain of CNAMEs. Each CNAME will of course require proof of the validity of that CNAME (which may be based on proof of associated DNAME records). This then brings us to the question of whether the server should be willing to attempt to construct such a set of records for an arbitrary SNI name the client happens to send. It seems that the answer should generally be "no". This is because otherwise the client would be able to trigger arbitrary DNS lookups on the server, which may impose unacceptable resource costs (and facilitate DoS attacks on the targets of such lookups). Therefore, servers MUST be configured with a list of SNI domains (or at perhaps domain suffixes) for which they are willing to attempt to produce a validated TLSA RRset. A bit lower we have: [TODO: mention that to reduce the size of the chain, the server can deliver exactly one RRsig per RRset, namely the one used to validate the chain as it is built.] This assumes that the server knows which algorithms the client's library supports. The server can definitely do some trimming if multiple signatures are present for the same algorithm as a side-effect of key rotation, but it cannot in general trim the list down to one signature per RRset, unless the client's extension also signals the supported algorithms (too complex I think, and serves to help "fingerprint" the client). Each RRset in the chain is composed of a sequence of wire format DNS resource records. The format of the resource record is described in RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be presented in the canonical form and ordering as described in RFC 4034 [RFC4034]. RRs within the RRset are ordered canonically, by treating the RDATA portion of each RR as a left-justified unsigned octet sequence in which the absence of an octet sorts before a zero octet. Here, I'd like to lift both the restriction on the order and canonical form. In which case, the server can return the records in exactly the form it obtained them from its own DNS server, likely not canonically ordered, and quite possibly with compression! The server may need to make multiple queries to obtain the full set of records to return to the client. In order to make it possible to retain DNS compression, the response format needs to consist of one or more wire-form DNS packets, each of which contains one or more answer RRsets ("additional" and "authority" records should be discarded at the server end, but with care, in the unlikely case that compressed answers point into records in the authority or additional sections.) Thus I think the right structure for the reply is a sequence of DNS packets, not a sequence of RRsets. Compression is then scoped to each individual packet. Of course we could make the server "work harder" by consolidating all the DNS packets it receives into a single sequence of RRsets as suggested in the current draft. This would typically require "decompression" and "recompression" once the full set of RRsets is assembled (if I think is best) we opt to minimize the network footprint of this extension. The first RRset in the chain MUST contain the DANE records being presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate the preceding RRset: Except of course when it is a CNAME (perhaps a chain of such CNAMEs). Some nameservers return RRSIGs before the record they signed. Again, apart from the first RRset being either the desired TLSA RRset, or a CNAME from its qname ultimately to a TLSA RRset, the order of records after the first should not be constrained. The client should load them *all* into memory, then validate the first (using all pertinent records in the resulting cache) and recurse if that first record is a CNAME, (being mindful of potential loops), until it ultimately validates a TLSA RRset, which authenticates the server's certificate or bare public key (RFC7250). I'll stop here for now, because if I'm in the rough on the above, further comments would likely fall afould of the same issues. -- Viktor. From nobody Tue Nov 10 11:35:43 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D7C21B3DAB for ; Tue, 10 Nov 2015 11:35:37 -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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ParrB467Qk4 for ; Tue, 10 Nov 2015 11:35:34 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 637CB1B3DA2 for ; Tue, 10 Nov 2015 11:35:25 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 26C91284D70; Tue, 10 Nov 2015 19:35:24 +0000 (UTC) Date: Tue, 10 Nov 2015 19:35:24 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20151110193523.GP18315@mournblade.imrryr.org> References: <20151109045334.GU18315@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151109045334.GU18315@mournblade.imrryr.org> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Nov 2015 19:35:37 -0000 On Mon, Nov 09, 2015 at 04:53:34AM +0000, Viktor Dukhovni wrote: > I still think this should support and use DNS compression. > > Each RRset in the chain is composed of a sequence of wire format DNS > resource records. The format of the resource record is described in > RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be > presented in the canonical form and ordering as described in RFC 4034 > [RFC4034]. > > RRs within the RRset are ordered canonically, by treating the RDATA > portion of each RR as a left-justified unsigned octet sequence in > which the absence of an octet sorts before a zero octet. > > Here, I'd like to lift both the restriction on the order and > canonical form. In which case, the server can return the > records in exactly the form it obtained them from its own DNS > server, likely not canonically ordered, and quite possibly with > compression! An alternative, (given that the server is expected to cache the extension and the server-side processing cost is presumably ammortized over multiple requests) is to collapse all the relevant RRsets into a single ("recompressed" by the server) DNS packet in which the initial TLSA RRset (preceded by any CNAME/DNAME and related RRSIG records that lead to this RRset) and its RRSIG appear in the "answer" section, while all the other records, (relevant RRSIG, DNSKEY and DS records of parent zones) are in the "additional" section. This single DNS "jumbo" packet can be picked apart and processed by a suitable DNS library that has existing code to process DNS packets with multiple RRsets (in multiple sections), in this case, as though the reply came from a root server, so that all the additional records are "in bailiwick". Of course the library might still need new code to support DANE processing in this new way, but there's a chance it might "just work", if all the RRsets are imported before any are verified. -- Viktor. From nobody Wed Nov 11 00:05:39 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0000E1B343F for ; Wed, 11 Nov 2015 00:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.351 X-Spam-Level: X-Spam-Status: No, score=-1.351 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjlivwVyqoDI for ; Wed, 11 Nov 2015 00:05:36 -0800 (PST) Received: from mx.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (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 F05EE1B343C for ; Wed, 11 Nov 2015 00:05:35 -0800 (PST) Received: from mail.roessner-net.de (mail.roessner-net.de [193.239.107.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.roessner-net.de", Issuer "thawte DV SSL CA - G2" (verified OK)) by mx.roessner-net.de (Postfix) with ESMTPS id 3nwdsT0LLwzGpSX for ; Wed, 11 Nov 2015 09:05:33 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=roessner-network-solutions.com; s=swioBi3opho; t=1447229133; i=@roessner-network-solutions.com; bh=oAzaa2z6RoTxpGdtvlzwJIg16QqvZgIRDlNGOvgHTSY=; h=From:Subject:Date:To; b=SDyn5TdjRc5eatWcGEgzGMbmBMA/NEmMUSnKdy6aUwJJ25cdbPnZ7m1Ofpg8D6+bA 1FzM4KSiBSQEiE99u9YH9HRqKzreu5t2bkilug0twnbfon3tSablIpGvD0+PPUpspb mDHlPQVtaUhodDEoAFe0NE5wnZaxzb2az53ELb24p/qfps7wXDqCy73PrqzouDgVvu U0+GXBkn4xQyNmA/6XAbWcLVaMPOSBwZtwSHqrDknTDAwREeFYffrVVfzgZ+1y/VJG xImHftnciWWi36HldkSHdd4s4YqOp3BJlOkgX3Cw4UtAbJejccJa4NEhQuwxxjOQk0 zYKjmm7Pog/yw== Received: from [172.16.2.200] (static-201-106.deltasurf.de [193.239.106.201]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: c@roessner-network-solutions.com) by mail.roessner-net.de (Postfix) with ESMTPSA id 3nwdsS24DnzMlGQ for ; Wed, 11 Nov 2015 09:05:32 +0100 (CET) From: =?utf-8?Q?Christian_R=C3=B6=C3=9Fner?= Content-Type: multipart/signed; boundary="Apple-Mail=_6955E201-A325-4A69-AB2E-948E3328215E"; protocol="application/pkcs7-signature"; micalg=sha1 Message-Id: <789370DC-D5CA-4F96-A20F-EB41B61D48FC@roessner-network-solutions.com> Date: Wed, 11 Nov 2015 09:05:29 +0100 To: "dane@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 9.1 \(3096.5\)) X-Mailer: Apple Mail (2.3096.5) Outgoingd-Filter: Outgoingd Filter v0.4.0_m1 mail.roessner-net.de 3nwdsS24DnzMlGQ Anomaly-Results: mail.roessner-net.de; rate=0% Archived-At: Subject: [dane] Is there some activity for Pointer-to-Server X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Nov 2015 08:05:38 -0000 --Apple-Mail=_6955E201-A325-4A69-AB2E-948E3328215E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I had written the reference implementation for SMIMA experimental draft. = So far that one works very will. I know, one very important discussion = was about the local part, which became SHA256/trunc at the moment. I am also interested about the other path doing the lookup over a = pointer to server variant. If I remember correctly, someone posted a draft for such a mechanism. = Something similar to: _smime.whatever.domain.tld. IN FOO = ...https://some.lookup.server.for.smime Even the same for OpenPGP I can't remember much more. And even did not find things in my mail = archive. So: Are there plans on working on such a draft? Especially the = protocol for the https-server? I am very much interested in implementing = a proof-of-concept in the current milter that uses SMIMEA already. So = developing such a draft could go hand in hand with theory and practice. Kind regards Christian= --Apple-Mail=_6955E201-A325-4A69-AB2E-948E3328215E Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIE8TCCBO0w ggPVoAMCAQICAhAFMA0GCSqGSIb3DQEBCwUAMIHeMQswCQYDVQQGEwJERTESMBAGCgmSJomT8ixk ARkWAmRlMRwwGgYKCZImiZPyLGQBGRYMcm9lc3NuZXItbmV0MQ8wDQYDVQQIDAZIZXNzZW4xEDAO BgNVBAcMB0Fsc2ZlbGQxDzANBgNVBAoMBlIuTi5TLjEeMBwGA1UECwwVQ2VydGlmaWNhdGUgQXV0 aG9yaXR5MRgwFgYDVQQDDA9Sb290Q0EgKGMpIDIwMTQxLzAtBgkqhkiG9w0BCQEWIGNAcm9lc3Nu ZXItbmV0d29yay1zb2x1dGlvbnMuY29tMB4XDTE0MDkwNzE0MDI0NloXDTI0MDkwNDE0MDI0Nlow gdAxCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vz c25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5O LlMuMQ0wCwYDVQQLDARNYWlsMRswGQYDVQQDDBJDaHJpc3RpYW4gUm9lc3NuZXIxLzAtBgkqhkiG 9w0BCQEWIGNAcm9lc3NuZXItbmV0d29yay1zb2x1dGlvbnMuY29tMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAvRa6QBgHt56hf1RuKHsNkXPXTFzG0RLualxlyfsJS0nWNWFaBD7ceZ8F WhnP7ypHSyWE4aCy7BYM4n2iVDm9m8bKV5cXuSdLY3kefqSOk9+YvCLu1MqQk70BY7UReS7OUJ1r ml1v09igaYA1+4FT8Um5oXB69BMm/JxFlkJ/TEu7KQzZ++oWavezChU+tc3neP4TJ9B+e4Q3BiTW RPMzmWf1HDR9RfhU4YPT0AQpvMusYUN/QKqKgh7cCCx8fcMO7noZDCNJchKLuil8/jKznJtj8+/B mwbvHJjshv/txNxKr8Id1K7+cQMweMA6uuOiJIt9oOAcPM8UEMzFwrShvwIDAQABo4HAMIG9MAkG A1UdEwQCMAAwLAYJYIZIAYb4QgENBB8WHU9wZW5TU0wgR2VuZXJhdGVkIENlcnRpZmljYXRlMB0G A1UdDgQWBBQkzf3k5Z/BAcTvlAu53yCIqJXMUzAfBgNVHSMEGDAWgBTgcUa1UKCapZJ6/qUWTH2C bOT9nDBCBgNVHR8EOzA5MDegNaAzhjFodHRwOi8vd3d3LnJvZXNzbmVyLW5ldHdvcmstc29sdXRp b25zLmNvbS9jcmwucGVtMA0GCSqGSIb3DQEBCwUAA4IBAQBGVbjnbP3RkXd5BStfKfyGWwNAAzrS dR1fy+tje5Zoq8t9nvxtaNnPCehyztTgUFfNaARFI5yY+z2ZaJ58NnQhSKYuZDkx/mwZkGcVbvp5 r7uDqFo42OfHej6SMIMzwKuXEgF26bKmcm4uZOouw8Ec68raEfnRY22loL8usx2yrH1qURgjSTJP PZ2Rs+2WVTWxylhLADAf7aAXTUPCx4zW6cGPYA2GR8w9ZYk74fIpPus4hs/LbBUVYtOMX6daVwkC 8xmQmcRihGo8wB5N2dH2T0fPV70HSn5GTUQ8O69ObDT8zo33dvg2w4swbWaKdn11Ywhd+HhvM+Ru bOSB+EBuMYIEYjCCBF4CAQEwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYKCZImiZPyLGQBGRYCZGUx HDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhlc3NlbjEQMA4GA1UEBwwH QWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx GDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYgY0Byb2Vzc25lci1uZXR3 b3JrLXNvbHV0aW9ucy5jb20CAhAFMAkGBSsOAwIaBQCgggJRMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MTExMTA4MDUzMFowIwYJKoZIhvcNAQkEMRYEFAz7TSBH UWmCDL2v2fC2lIk/nk0aMIH2BgkrBgEEAYI3EAQxgegwgeUwgd4xCzAJBgNVBAYTAkRFMRIwEAYK CZImiZPyLGQBGRYCZGUxHDAaBgoJkiaJk/IsZAEZFgxyb2Vzc25lci1uZXQxDzANBgNVBAgMBkhl c3NlbjEQMA4GA1UEBwwHQWxzZmVsZDEPMA0GA1UECgwGUi5OLlMuMR4wHAYDVQQLDBVDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxGDAWBgNVBAMMD1Jvb3RDQSAoYykgMjAxNDEvMC0GCSqGSIb3DQEJARYg Y0Byb2Vzc25lci1uZXR3b3JrLXNvbHV0aW9ucy5jb20CAhAFMIH4BgsqhkiG9w0BCRACCzGB6KCB 5TCB3jELMAkGA1UEBhMCREUxEjAQBgoJkiaJk/IsZAEZFgJkZTEcMBoGCgmSJomT8ixkARkWDHJv ZXNzbmVyLW5ldDEPMA0GA1UECAwGSGVzc2VuMRAwDgYDVQQHDAdBbHNmZWxkMQ8wDQYDVQQKDAZS Lk4uUy4xHjAcBgNVBAsMFUNlcnRpZmljYXRlIEF1dGhvcml0eTEYMBYGA1UEAwwPUm9vdENBIChj KSAyMDE0MS8wLQYJKoZIhvcNAQkBFiBjQHJvZXNzbmVyLW5ldHdvcmstc29sdXRpb25zLmNvbQIC EAUwDQYJKoZIhvcNAQEBBQAEggEAZEkEx71RDxcH8boU9kNqhvR3oE8qnFnE1Oo8JRMoqIKttnUo RBcWbGDefW+bvBtjZxN/LLZ9nnsjWzm7EkspuVpy+ca5b1eH/ZR6hOKC8gG3RPaRszuLwCYX8PCr J4wuSVhgGzSWyu/6w9xRYDgzxRtpo1fRMVHVCIg/khgaT5/C3hb8TBRqytLnua3J4s+P4sR2OWLk 5rC/fAQkYdYplmbUYDbTlXqmjnZUSZvpnmFTPwae4kQLa3SPclrdLRSY6xEuIF6RF3jcnvTM6ZBw i+ucPEtKOCQ1s4uhFZeE5+KRMeCfS8TL7lsfumyv22iWFtVippRDz4oq/ltA8FneKQAAAAAAAA== --Apple-Mail=_6955E201-A325-4A69-AB2E-948E3328215E-- From nobody Sat Nov 14 13:40:24 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124071B2BA2 for ; Sat, 14 Nov 2015 13:40:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.837 X-Spam-Level: X-Spam-Status: No, score=-0.837 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yUPGmKujm323 for ; Sat, 14 Nov 2015 13:40:21 -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-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4E8F1B2BA0 for ; Sat, 14 Nov 2015 13:40:20 -0800 (PST) Received: (qmail 19461 invoked from network); 14 Nov 2015 21:40:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4c03.5647aa44.k1511; bh=GNWJSbuneZ+xkQfIpUjwbQU5d4fVUhh14w7eGyBJLBA=; b=l4WK34vRajd/l5vTDDxy0uyUnoPXEHVjZnNlKvEvvb0QIPjvVW8AGxLaiSludrYYbuQmmY0icnbCK/jZ9l4VEvDbB7uojRTEb2Av/g3in2PQNox6LwkxKRQnNTBHgeM7VlcfG8p55ylevcDZkPKZ0QWDrdactFblX9vt6p7F5txsvIdQ974UqfsIkFOC7yEG0OSg4gNcwYF7iSwfU2pGfxT5BDCiQXqhUco7co2yCpEVzRl463yV+WuD9hSG+md/ DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=4c03.5647aa44.k1511; bh=GNWJSbuneZ+xkQfIpUjwbQU5d4fVUhh14w7eGyBJLBA=; b=UxtAipbyUJ98XwG8/0LHmlvCYfIgYaXmQ/LbplkRGOrQZc65sRCr/5ddsaQv796QPv7Kb7Kqp4j1xUGAE0vTVuT8p27hSS6n+pGVYT/TIcN0786ZdiN+QLGPXZoWXqr5sFTa+M2HkpqjxYhlC9tQ8LNRotAdkMdtqLGwLUxNc9rAJU98mQS3FaXXGgSma7bihM5XF3Z50ZX8sKet/06JC8cJmG47Ki4RQ2M+2Rrsd6oF8y64A//Z0yNlO1aw6Ciq Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 14 Nov 2015 21:40:20 -0000 Date: 14 Nov 2015 16:40:19 -0500 Message-ID: From: "John R Levine" To: "=?UTF-8?Q?Christian_R=C3=B6=C3=9Fner?=" In-Reply-To: <789370DC-D5CA-4F96-A20F-EB41B61D48FC@roessner-network-solutions.com> References: <789370DC-D5CA-4F96-A20F-EB41B61D48FC@roessner-network-solutions.com> User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Is there some activity for Pointer-to-Server X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 21:40:22 -0000 > If I remember correctly, someone posted a draft for such a mechanism. Something similar to: > > _smime.whatever.domain.tld. IN FOO ...https://some.lookup.server.for.smime That was me. See draft-levine-dns-mailbox-01, section 6. Also see draft-moore-email-addrquery-01 which discusses a method for publishing per-address info such as keys using an SMTP extension. I think that's more likely to make progress. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. From nobody Sat Nov 14 13:49:12 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 418E21B2BEA for ; Sat, 14 Nov 2015 13:49:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.263 X-Spam-Level: X-Spam-Status: No, score=0.263 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-8weWInKAX9 for ; Sat, 14 Nov 2015 13:49:10 -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-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 317381B2BE6 for ; Sat, 14 Nov 2015 13:49:10 -0800 (PST) Received: (qmail 20745 invoked from network); 14 Nov 2015 21:49:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=5108.5647ac55.k1511; bh=GwN+hj4iqRXoIx7+Icrv9PeBRfM9246HJ35sdIq09AU=; b=UOwScBJVjBvvOETDqz/Oe0EjU/UHJ/SpzcUqr3bnGLB52Yn1xbsDmBpEMzNFgrfQY27JS8TnRW1hufvBubeC9/iE67SihBn4pnL2JxTKDvChaT+8XXqyuJ1DA93OaHrD64DoGyBoiGmV2jNpUnlOGkvACN+Z6vh9Qo/KtuhUhfzY2bpYiP1Xo/fFyktyrbJOvMuu4XIUqGFf3jn1NSe3wymXqk9EQVSP4AA6aIaqhGDKYTfG+tSywcgiE6Y9Kxt6 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:subject:mime-version:content-type:user-agent; s=5108.5647ac55.k1511; bh=GwN+hj4iqRXoIx7+Icrv9PeBRfM9246HJ35sdIq09AU=; b=WqjFE3TYJQYuBNNkyv4nR7rIY0t7ZUQXSw1DcJ2KE7qqEDMfqNTAchixaqkCwqTI9HJGqJM1+Qc/pP8WM7uzVdYiV6NX/O4UCLQvgAeNDQXr/7PwQizYn582hs7Ns2Ys/Jy52ioNY4rGDhSQGyObgzWGtOtLJ3U7+912Kl+rC0dgXVVtOv4gPMoLpi2WEgNrpZZQMkBSqVojve0wDmB1jiDpk4R3KXWuoD7xVREbI7adn8mTFRshR9rJIH/rVRM+ Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.0/X.509/SHA1) via TCP6; 14 Nov 2015 21:49:08 -0000 Date: 14 Nov 2015 16:49:08 -0500 Message-ID: From: "John R Levine" To: "dane@ietf.org" User-Agent: Alpine 2.11 (OSX 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: Subject: [dane] Speaking of mailbox names in the DNS X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Nov 2015 21:49:11 -0000 Take a look at RFC 6763 on DNS-SD. Section 4.1.1 says you put the name of the service instance directly in the DNS as Net-Unicode which is basically UTF-8 minus control characters: ... Because Service Instance Names are not host names, they are not constrained by the usual rules for host names [RFC1033] [RFC1034] [RFC1035], and rich-text service subdomains are allowed and encouraged, for example: Building 2, 1st Floor . example . com . Building 2, 2nd Floor . example . com . Building 2, 3rd Floor . example . com . Building 2, 4th Floor . example . com . In addition, because Service Instance Names are not constrained by the limitations of host names, this document recommends that they be stored in the DNS, and communicated over the wire, encoded as straightforward canonical precomposed UTF-8 [RFC3629] "Net-Unicode" (Unicode Normalization Form C) [RFC5198] text. Since DNS-SD is widely deployed and the world hasn't come to an end, I don't see why mailbox names need anything else. This has the side effect of case folding ASCII characters, which some people appear to think is important. R's, John From nobody Sat Nov 14 23:02:28 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20B191A1A70 for ; Sat, 14 Nov 2015 23:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.91 X-Spam-Level: X-Spam-Status: No, score=-3.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZl3qUY5wCL8 for ; Sat, 14 Nov 2015 23:02:22 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00AEE1A1A96 for ; Sat, 14 Nov 2015 23:02:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1447570942; x=1479106942; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=6CScS2l0BBVgJaaTAMnWFBz7PjbJ/EJJC2cI8+dzmsY=; b=0JCfhIbutVskjBN32N+CP9nMGOYV8QaZKfI4W8ZqOBWUrf3l3sqRBEFU KPAv66L5PQrMinExoxKAIZZ9MWsI9FnM34qOkABaxFDCG+o1IvhAnxa/W ahEcKoFEujGO17CgeNH7ekW3nQ59yT+Kqt2FEQE425MpFyqOExpKdM56E f+XvGwsb6kTRXPo6DLiyX5wB4AChQLDgCk+lYUTZ1gCB5iAiIZ4YTJNA7 6Uq2DZJDanTnovZ3k0mwhlpGHADMyYKHw2YmpPLrbuovtRQ0jlpJG/0f7 iG9LxRqTdXNzYTxfezqaOm3aCtWsdEpPyFjA+qSJrmVRx42ibKFn0h8u5 g==; X-IronPort-AV: E=Sophos;i="5.20,296,1444647600"; d="scan'208";a="54242423" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Nov 2015 20:02:18 +1300 Received: from UXCN10-5.UoA.auckland.ac.nz ([169.254.5.51]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sun, 15 Nov 2015 20:02:18 +1300 From: Peter Gutmann To: John R Levine , =?iso-8859-1?Q?Christian_R=F6=DFner?= Thread-Topic: [dane] Is there some activity for Pointer-to-Server Thread-Index: AQHRHyUWBzx0EQBkH0OGZTpZVrcMYJ6cqKsW Date: Sun, 15 Nov 2015 07:02:17 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C73F4B64872@uxcn10-5.UoA.auckland.ac.nz> References: <789370DC-D5CA-4F96-A20F-EB41B61D48FC@roessner-network-solutions.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dane@ietf.org" Subject: Re: [dane] Is there some activity for Pointer-to-Server X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2015 07:02:26 -0000 John R Levine writes:=0A= =0A= >> If I remember correctly, someone posted a draft for such a mechanism. So= mething similar to:=0A= >>=0A= >> _smime.whatever.domain.tld. IN FOO ...https://some.lookup.server.for.smi= me=0A= >=0A= >That was me. See draft-levine-dns-mailbox-01, section 6.=0A= >=0A= >Also see draft-moore-email-addrquery-01 which discusses a method for=0A= >publishing per-address info such as keys using an SMTP extension. I think= =0A= >that's more likely to make progress.=0A= =0A= Or you could use RFC 4387, which has been a standards-track RFC for nearly = a=0A= decade.=0A= =0A= Peter.=0A= From nobody Thu Nov 19 03:39:12 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBFB61ACD97 for ; Thu, 19 Nov 2015 03:39:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pV1STTtT37Xp for ; Thu, 19 Nov 2015 03:39:09 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::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 A019F1ACD8E for ; Thu, 19 Nov 2015 03:39:08 -0800 (PST) Received: by qgeb1 with SMTP id b1so48623015qge.1 for ; Thu, 19 Nov 2015 03:39:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=vrF3NPSgZZenvXK5sygplj3L4NQWWMl5tvb9MEOdS3E=; b=AXn9vXyhdZsIMeVdpa+WWgSYdsXkMRaTwQYxSnipiLFn03Suf7XWKimjnYG2xz87XV VFsllDGNN6SW6LBU078BTLi4fXVq4IzaHthgtkAu4IssIslrz5QLDV07RBEuIAq+oVOu A/fEyeTP+1+sWErV2shpEtRKoRGx551e7HTkpUUYZ6sZ8UP8axbeON5a5ZwdVC5KMJbO ngf/ZJBDz+TMH5dgaYhntN04aMIEgiZ1MhGgcYha+gaJMCU8VcWtpsDaTyhqjihx2o6h dsQ14lkB6SesmgdW8vJ3kIeE7rfhDNAfQsU9qKKhNhEdr3pddR+e+FNsh5boWudN3r3l vqnA== MIME-Version: 1.0 X-Received: by 10.140.129.198 with SMTP id 189mr6951246qhb.10.1447933147826; Thu, 19 Nov 2015 03:39:07 -0800 (PST) Received: by 10.140.87.117 with HTTP; Thu, 19 Nov 2015 03:39:07 -0800 (PST) In-Reply-To: <20151109045334.GU18315@mournblade.imrryr.org> References: <20151109045334.GU18315@mournblade.imrryr.org> Date: Thu, 19 Nov 2015 06:39:07 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a1134f4b0ef71210524e33481 Archived-At: Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Nov 2015 11:39:11 -0000 --001a1134f4b0ef71210524e33481 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 8, 2015 at 11:53 PM, Viktor Dukhovni wrote: > On Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huque wrote: > > > This work is proposed to happen in TLS, but we hope to get plenty > > of feedback from DNS/DANE folks. Here's a quick summary of the major > > changes in -02: > > > > Thanks. > [ ... detailed comments omitted ... ] Thanks for the detailed review and feedback Viktor, and sorry for my belated reply. I just got back from vacation, and will read this in detail and respond in the next few days. -- Shumon Huque --001a1134f4b0ef71210524e33481 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Nov 8, 2015 at 11:53 PM, Viktor Dukhovni <ietf-dane@dukhovni.org= > wrote:
O= n Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huque wrote:

> This work is proposed to happen in TLS, but we hope to get plenty
> of feedback from DNS/DANE folks. Here's a quick summary of the maj= or
> changes in -02:
>

Thanks.

[ ... detailed comments = omitted ... ]

Thanks for the detailed review and f= eedback Viktor, and sorry for my belated reply. I just got back from vacati= on, and will read this in detail and respond in the next few days.

--=C2=A0
Shumon Huque

=
--001a1134f4b0ef71210524e33481-- From nobody Mon Nov 23 05:19:29 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FBB11A9171 for ; Mon, 23 Nov 2015 05:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B2FSpdKO8f1G for ; Mon, 23 Nov 2015 05:19:22 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 B1F1A1A1AE1 for ; Mon, 23 Nov 2015 05:19:21 -0800 (PST) Received: by qkao63 with SMTP id o63so58472365qka.2 for ; Mon, 23 Nov 2015 05:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=sxoh9ZXHZqG32RpgV63iARbXxcoUR45Ok/M4rv4FmSw=; b=yi3nvcCv28L4JV/pTRDRF0//vjtxibYHF5/yJO/1N5NCwFyqbmtR2CHW5i5rr9TTX1 Bac959bg8xtfn2YSWb/fk4XXDIlDpPLjKy6qihkLRxBUgj8kwz++xhntbnzehaD+9jcZ uWZvUwxOeNZhHPnbEn/RlhRoakmf+Q2Zj6fHJuwVgBgxtkm+o0dmvSnUGGdZFZEN+pTW tPjPSCL87/SDuyQoJh7TAm3K1WZJaTYbH8Y9qg1TGsqmeek37emRzJouvzPmEhtEWw3T JRHXweTc1xhkGOQhMAdMabnFAX8qWFF/5sewfHEFJZqJC74NKNAXGDiLykyGoHDwyrg6 MWxg== MIME-Version: 1.0 X-Received: by 10.55.203.151 with SMTP id u23mr26063658qkl.84.1448284760802; Mon, 23 Nov 2015 05:19:20 -0800 (PST) Received: by 10.140.87.117 with HTTP; Mon, 23 Nov 2015 05:19:20 -0800 (PST) In-Reply-To: <20151109045334.GU18315@mournblade.imrryr.org> References: <20151109045334.GU18315@mournblade.imrryr.org> Date: Mon, 23 Nov 2015 08:19:20 -0500 Message-ID: From: Shumon Huque To: "" Content-Type: multipart/alternative; boundary=001a1134ef98b38d70052535123f Archived-At: Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Nov 2015 13:19:28 -0000 --001a1134ef98b38d70052535123f Content-Type: text/plain; charset=UTF-8 On Sun, Nov 8, 2015 at 11:53 PM, Viktor Dukhovni wrote: > On Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huque wrote: > > > * An update to the chain data format. It now uses native DNS wire > > format resource records with no TLS presentation language wrapping. > > This makes it easier for implementations to work with existing > > DNS libraries to produce and consume the data. But we still describe > > the data format in sufficient detail that implementers not using DNS > > libraries can work with it. > > I still think this should support and use DNS compression. We're still discussing this point and I'm interested in hearing opinions from other folks too. My original assertion was that I didn't think it was worth it given that the size of the chain is going to be dominated by larger elements like public keys (DNSKEY rdata) and signatures (RRSIG rdata). However, I take your point that as deployment moves to smaller ECDSA objects, this calculation could change. Then the question is what form this compression should take, which relates directly to your comment further down about DNS messages vs RRsets. Compression in the DNS protocol is currently defined in terms of DNS messages, so we'd have to define a new scheme. The simplest would be to redefine (for the purpose of this TLS extension only) the compression pointer in the label's 1st octet to refer to an offset from the beginning of the chain data structure. Or, switch to DNS messages. > > * Description of how CNAME and DNAMEs are accommodated > > > > * Reference to use of the X.509v3 TLS Feature Extension to mandate > > use of the extension by a server certificate. > > > > * Reference to the EDNS chain query option draft as a future easy > > way to obtain/produce the chain data. > > > > * Removed discussion of possible client caching of chain data > > components (could be difficult to get right and/or a premature > > optimization). > > Introduction: > > The intent of this proposal is to > allow TLS clients to perform DANE authentication [RFC6698] of a TLS > server certificate without performing perform additional DNS record > lookups and incurring the associated latency penalty. > > s/performing perform/having to perform/ Yup, will fix. > It also > provides the ability to avoid potential problems with TLS clients > being unable to look up DANE records because of an interfering or > broken middlebox on the path between the endpoint and a DNS server. > > s/endpoint/client/ Ok. > And lastly, it allows a TLS client to validate DANE records > itself without needing access to a validating DNS resolver > to which it has a secure connection. It will typically not > be used for general DNSSEC validation of endpoint names, > but is more appropriate for validation of DANE TLSA records. > > Clients can already do independent validation (perhaps at higher > latency cost if they don't implement a *caching* stub resolver). Yes, that's true. The term "validating DNS resolver" could technically cover a local stub validator too, but I think we can add some wording specifically on this point. > Furthermore, this mechanism is, at least for now, *definitely* > (not just typically) restricted to carrying DANE TLSA records > and their signatures. Yes, it can carry other records (CNAME, DNAME, perhaps NSEC, etc). I think the point being made in that sentence was that the goal was to validate a servers TLSA record rather than say the servers address record mapping (although technically it might be able to do that retrospectively). > This mechanism is useful for TLS applications that need to address > the problems described above, typically web browsers or VoIP and XMPP > services. > > Are "XMPP services" applications? I would say "typically in > web browsers, VOIP or XMPP clients", It might be best to say "applications" (rather than "clients") such as Web, XMPP, VoIP. Both server and client sides of these applications will have to implement the protocol. > but we still don't know > that web browsers are likely to adopt DANE however hard we try. > So we can't predict which applications will take the bait, > perhaps we should not try. We might however indicate what > "types" of applications are in scope, and that is mobile clients > for which DNSSEC is not always available on random WiFi hotspots, > and latency-sensitive clients for which making multiple DNS > lookups to validate a DNSSEC response is not an option (and > no DNSSEC validating cache is available locally). Well, we're talking to some web folks who are interested and involved. So while I agree that we don't yet know if web browsers will adopt DANE, I don't have a problem mentioning them as a possible consumer. Maybe we can soften the wording here so as not to imply any predictions. Good point about mobile clients being in scope. I could be persuaded to remove that paragraph entirely if we don't want to sway the discussion in the direction of any specific applications, but I think mentioning possible applications helps the reader understand more concretely what this solution is being designed for. > Section 3.2 > > The AuthenticationChain structure is composed of a sequence of > uncompressed wire format DNS resource record sets (RRset) and > corresponding signatures (RRsig) records. The record sets and > signatures are presented in validation order, starting at the target > DANE record, followed by the DNSKEY and DS record sets for each > intervening DNS zone up to a trust anchor chosen by the server, > typically the DNS root. > > Two issues here: > > * Because validation order is not always possible (in presence > of DNAME/CNAME indirection), it is I think best to not > suggest that the records are so ordered, even in the case > when such ordering is possible. I agree that CNAME/DNAME indirection makes this trickier. A later section does describe how ordering is done for CNAME/DNAME chains, essentially using multiple sequences of ordered RRsets. > To do otherwise invites > sloppy implementations that don't correctly deal with > replies that are unavoidably not strictly ordered. The TLS server in this case would be required to order the RRsets appropriately, regardless of what order they appeared in the DNS wire messages they received. In an ideal world, I agree that it would be better if we could leave the ordering unspecified, but we're working with requirements from some of the potential consumers of this. Certificate chains in TLS are ordered (from EE cert towards trust anchor), and they'd like the DNS RRsets to be similarly ordered, so that the client can authenticate the data in one sequential pass through. That was our starting point. We'll continue to have discussions on this topic (and I'd be happy to rope you in), but I am a bit reluctant to expend energy to develop a protocol that application developers won't implement, so I'm trying to be flexible. > * On the other hand, the specification needs to clearly > identify what the server needs to use as the *first* RRset. > > This can be tricky. The point is that a DANE TLSA client > connects to and authenticates a what is essentially "transport > endpoint", except that the network address is replaced by > a DNS name. On the other hand the accepting server might > be behind a NAT device of some sort, and may not even know > what port the client connected to! > > The client's name for the service can be learned from the > SNI extension, which therefore MUST be used when the proposed > extension is used, and presumably the transport protocol > (TCP, or UDP) is known on the server end (the server will > be doing TLS or DTLS after all, and will know which). I agree. Making the SNI extension mandatory seems necessary (and also an easy requirement since this is a green field application), but I wasn't able to get agreement from some of my co-authors on this. Will re-open the discussion. > So it would seem that the client needs to communicate the > target port to the server, as the payload of the proposed > extension in the client HELLO (extension would no longer > be empty on the client side). Hmm, I hadn't considered the case of servers behind NATs. But I guess IPv4 depletion and CGNs might make this a more prevalent (and reasonable) use case we should try to accommodate. If we're populating the client side extension with data, it could carry both the server's name and port. > The server's job is then to produce a set of DNS RRsets > whose first element is either: > > _._. IN TLSA ... > > or > > _._. IN CNAME ... > > in the latter case ultimately along with the TLSA records > for the target of the chain of CNAMEs. Each CNAME will of > course require proof of the validity of that CNAME (which > may be based on proof of associated DNAME records). > > This then brings us to the question of whether the server > should be willing to attempt to construct such a set of > records for an arbitrary SNI name the client happens to > send. It seems that the answer should generally be "no". > This is because otherwise the client would be able to > trigger arbitrary DNS lookups on the server, which may > impose unacceptable resource costs (and facilitate DoS > attacks on the targets of such lookups). Yes, this would have been obvious to me -- that the server should only construct chains for its own name(s). But thanks for raising it. We should make this requirement explicit in the draft. > Therefore, servers MUST be configured with a list of SNI > domains (or at perhaps domain suffixes) for which they are > willing to attempt to produce a validated TLSA RRset. Yes. > > A bit lower we have: > > [TODO: mention that to reduce the size of the chain, the server can > deliver exactly one RRsig per RRset, namely the one used to validate > the chain as it is built.] > > This assumes that the server knows which algorithms the client's > library supports. The server can definitely do some trimming > if multiple signatures are present for the same algorithm as > a side-effect of key rotation, but it cannot in general trim > the list down to one signature per RRset, unless the client's > extension also signals the supported algorithms (too complex > I think, and serves to help "fingerprint" the client). Good point. Maybe it's simplest to remove this requirement, or only trim obviously safe signatures due to key rotation or signatures that aren't required (such as a ZSK signature over the DNSKEY RRset - unnecessary but often seen in the wild). Having the client indicate its supported algorithms in the extension might be worth considering though. > Each RRset in the chain is composed of a sequence of wire format DNS > resource records. The format of the resource record is described in > RFC 1035 [RFC1035], Section 3.2.1. The resource records SHOULD be > presented in the canonical form and ordering as described in RFC 4034 > [RFC4034]. > > RRs within the RRset are ordered canonically, by treating the RDATA > portion of each RR as a left-justified unsigned octet sequence in > which the absence of an octet sorts before a zero octet. > > Here, I'd like to lift both the restriction on the order and > canonical form. In which case, the server can return the > records in exactly the form it obtained them from its own DNS > server, likely not canonically ordered, and quite possibly with > compression! See previous remarks about ordering - a continuing discussion topic. > > The server may need to make multiple queries to obtain the full > set of records to return to the client. In order to make it > possible to retain DNS compression, the response format needs > to consist of one or more wire-form DNS packets, each of which > contains one or more answer RRsets ("additional" and "authority" > records should be discarded at the server end, but with care, > in the unlikely case that compressed answers point into records > in the authority or additional sections.) The Answer section precedes Authority and Additional, and compression pointers can only reference prior occurences of names, so your last concern is probably not a problem. However, authority section data may not be discardable in some cases, such as a wildcard record which would need an NSEC & RRSIG from the authority section. > Thus I think the right structure for the reply is a sequence > of DNS packets, not a sequence of RRsets. Compression is then > scoped to each individual packet. > > Of course we could make the server "work harder" by consolidating > all the DNS packets it receives into a single sequence of RRsets > as suggested in the current draft. This would typically require > "decompression" and "recompression" once the full set of RRsets > is assembled (if I think is best) we opt to minimize the network > footprint of this extension. If we migrate to DNS messages, the best format would be the proposed EDNS chain query message, which would remove a lot of the overhead: http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query But we'd need to be to process regular messages for servers that don't support this too. I'll start some discussion on this topic. > > The first RRset in the chain MUST contain the DANE records being > presented. The subsequent RRsets MUST be a sequence of DNSKEY and DS > RRsets, starting with a DNSKEY RRset. Each RRset MUST authenticate > the preceding RRset: > > Except of course when it is a CNAME (perhaps a chain of such > CNAMEs). Some nameservers return RRSIGs before the record they > signed. Again, apart from the first RRset being either the > desired TLSA RRset, or a CNAME from its qname ultimately to a > TLSA RRset, the order of records after the first should not be > constrained. > > The client should load them *all* into memory, then validate > the first (using all pertinent records in the resulting cache) > and recurse if that first record is a CNAME, (being mindful of > potential loops), until it ultimately validates a TLSA RRset, > which authenticates the server's certificate or bare public > key (RFC7250). > > I'll stop here for now, because if I'm in the rough on the above, > further comments would likely fall afould of the same issues. No, you're not in the rough and I very much appreciate the detailed comments Viktor. As I mentioned, we're working with some constraints and desires imposed by the likely consumers of this mechanism, but there is of course room for discussion and refinement. -- Shumon Huque --001a1134ef98b38d70052535123f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On S= un, Nov 8, 2015 at 11:53 PM, Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
> On Sun, Nov 01, 2015 at 08:34:40AM +0900, Shumon Huqu= e wrote:
>
> > * An update to the chain data format. It now uses native DNS w= ire
> > =C2=A0 format resource record= s with no TLS presentation language wrapping.
> > =C2=A0 This makes it easier for implementations to work with e= xisting
> > =C2=A0 DNS libraries to p= roduce and consume the data. But we still describe
> > =C2=A0 the data format in sufficient detail that implemen= ters not using DNS
> > =C2=A0 librari= es can work with it.
>
> I still think this should support and use DNS compres= sion.

= We're still discussing this point and I'm interested in hearing opi= nions
from other folks too.

My original assertion= was that I didn't think it was worth it given
that the size of the chain is going to be dominated by larger eleme= nts
like public keys (DNSKEY rdata) and sig= natures (RRSIG rdata). However,
I take your= point that as deployment moves to smaller ECDSA objects,
this calculation could change.

Then the question is what form th= is compression should take, which
relates d= irectly to your comment further down about DNS messages vs
RRsets. Compression in the DNS protocol is currently defin= ed in terms
of DNS messages, so we'd ha= ve to define a new scheme. The simplest
wou= ld be to redefine (for the purpose of this TLS extension only) the
compression pointer in the label's 1st octet to= refer to an offset from
the beginning of t= he chain data structure. Or, switch to DNS messages.

> > * Description of h= ow CNAME and DNAMEs are accommodated
> &= gt;
> > * Reference to use of the X.5= 09v3 TLS Feature Extension to mandate
> = > =C2=A0 use of the extension by a server certificate.
> >
> > * Refe= rence to the EDNS chain query option draft as a future easy
> > =C2=A0 way to obtain/produce the chain data.
> >
>= > * Removed discussion of possible client caching of chain data
> > =C2=A0 components (could be difficult to= get right and/or a premature
> > =C2= =A0 optimization).
>
> Introduction:
>
<= div class=3D"gmail_extra">> =C2=A0 =C2=A0 =C2=A0 =C2=A0The intent of thi= s proposal is to
> =C2=A0 =C2=A0 =C2=A0 = =C2=A0allow TLS clients to perform DANE authentication [RFC6698] of a TLS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0server certi= ficate without performing perform additional DNS record
> =C2=A0 =C2=A0 =C2=A0 =C2=A0lookups and incurring the asso= ciated latency penalty.
>
> =C2=A0 =C2=A0 s/performing perform/having to perform= /

Yup,= will fix.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0It also
> =C2=A0 =C2=A0 =C2=A0 =C2=A0provides the ability to avoid potential p= roblems with TLS clients
> =C2=A0 =C2=A0= =C2=A0 =C2=A0being unable to look up DANE records because of an interferin= g or
> =C2=A0 =C2=A0 =C2=A0 =C2=A0broken= middlebox on the path between the endpoint and a DNS server.
>
> =C2=A0 =C2=A0 = s/endpoint/client/

Ok.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0And lastly, it allows a TLS clie= nt to validate DANE records
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0itself without needing access to a validating DNS resolver=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0to which i= t has a secure connection.=C2=A0 It will typically not
> =C2=A0 =C2=A0 =C2=A0 =C2=A0be used for general DNSSEC vali= dation of endpoint names,
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0but is more appropriate for validation of DANE TLSA record= s.
>
>= ; =C2=A0 =C2=A0 Clients can already do independent validation (perhaps at h= igher
> =C2=A0 =C2=A0 latency cost if th= ey don't implement a *caching* stub resolver).

Yes, that's true. The term= "validating DNS resolver" could technically
cover a local stub validator too, but I think we can add some w= ording
specifically on this point.

> =C2=A0 = =C2=A0 Furthermore, this mechanism is, at least for now, *definitely*
=
> =C2=A0 =C2=A0 (not just typically) restrict= ed to carrying DANE TLSA records
> =C2= =A0 =C2=A0 and their signatures.

=
Yes, it can carry other records (CNAME, DNAME, p= erhaps NSEC, etc). I think
the point being = made in that sentence was that the goal was to validate
a servers TLSA record rather than say the servers address reco= rd mapping
(although technically it might b= e able to do that retrospectively).

> =C2=A0 =C2=A0 =C2=A0 =C2=A0This mechanis= m is useful for TLS applications that need to address
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the problems described above, ty= pically web browsers or VoIP and XMPP
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0services.
>
> =C2=A0 =C2=A0 Are "XMPP services&q= uot; applications?=C2=A0 I would say "typically in
> =C2=A0 =C2=A0 web browsers, VOIP or XMPP clients",

It migh= t be best to say "applications" (rather than "clients")= such
as Web, XMPP, VoIP. Both server and c= lient sides of these applications
will have= to implement the protocol.

> =C2=A0 =C2=A0 but we still don't know
<= div class=3D"gmail_extra">> =C2=A0 =C2=A0 that web browsers are likely t= o adopt DANE however hard we try.
> =C2= =A0 =C2=A0 So we can't predict which applications will take the bait,
> =C2=A0 =C2=A0 perhaps we should not try= .=C2=A0 We might however indicate what
>= =C2=A0 =C2=A0 "types" of applications are in scope, and that is = mobile clients
> =C2=A0 =C2=A0 for which= DNSSEC is not always available on random WiFi hotspots,
> =C2=A0 =C2=A0 and latency-sensitive clients for which ma= king multiple DNS
> =C2=A0 =C2=A0 lookup= s to validate a DNSSEC response is not an option (and
> =C2=A0 =C2=A0 no DNSSEC validating cache is available local= ly).

W= ell, we're talking to some web folks who are interested and involved.
So while I agree that we don't yet know = if web browsers will adopt DANE,
I don'= t have a problem mentioning them as a possible consumer. Maybe
we can soften the wording here so as not to imply any p= redictions. Good
point about mobile clients= being in scope.

I could be persuaded to remove that paragraph entirely if we don= 't
want to sway the discussion in the d= irection of any specific applications,
but = I think mentioning possible applications helps the reader understand
<= div class=3D"gmail_extra">more concretely what this solution is being desig= ned for.

> Section 3.2
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0The AuthenticationChain struc= ture is composed of a sequence of
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0uncompressed wire format DNS resource record sets (= RRset) and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0= corresponding signatures (RRsig) records.=C2=A0 The record sets and
> =C2=A0 =C2=A0 =C2=A0 =C2=A0signatures are pre= sented in validation order, starting at the target
> =C2=A0 =C2=A0 =C2=A0 =C2=A0DANE record, followed by the DNSKEY= and DS record sets for each
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0intervening DNS zone up to a trust anchor chosen by the= server,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0ty= pically the DNS root.
>
> =C2=A0 =C2=A0Two issues here:
>
> =C2=A0 =C2=A0 =C2=A0 * B= ecause validation order is not always possible (in presence
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 of DNAME/CNAME indirectio= n), it is I think best to not
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 suggest that the records are so ordered, even in the c= ase
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 when s= uch ordering is possible.

I agree that CNAME/DNAME indirection makes this trickie= r. A later section
does describe how orderi= ng is done for CNAME/DNAME chains, essentially
using multiple sequences of ordered RRsets.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 = To do otherwise invites
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 sloppy implementations that don't correctly deal with
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 replies that = are unavoidably not strictly ordered.

<= /div>
The TLS server in this case would be requir= ed to order the RRsets
appropriately, regar= dless of what order they appeared in the DNS
wire messages they received.

In an ideal world, I agree that it would be better= if we could leave
the ordering unspecified= , but we're working with requirements from some
of the potential consumers of this. Certificate chains in TLS are = ordered
(from EE cert towards trust anchor)= , and they'd like the DNS RRsets to be=C2=A0
similarly ordered, so that the client can authenticate the data in on= e=C2=A0
sequential pass through. That was o= ur starting point.

We'll continue to have discussions on this topic (and I= 9;d be happy to
rope you in), but I am a bi= t reluctant to expend energy to develop a
p= rotocol that application developers won't implement, so I'm trying = to
be flexible.

> =C2=A0 =C2=A0 =C2=A0 * On th= e other hand, the specification needs to clearly
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 identify what the server needs to us= e as the *first* RRset.
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This can be tricky.=C2= =A0 The point is that a DANE TLSA client
&g= t; =C2=A0 =C2=A0 =C2=A0 =C2=A0 connects to and authenticates a what is esse= ntially "transport
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 endpoint", except that the network address is replaced b= y
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 a DNS na= me.=C2=A0 On the other hand the accepting server might
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 be behind a NAT device of some= sort, and may not even know
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 what port the client connected to!
>
> =C2=A0 =C2=A0 =C2=A0= =C2=A0 The client's name for the service can be learned from the
=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 SNI extension, = which therefore MUST be used when the proposed
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 extension is used, and presumably the = transport protocol
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 (TCP, or UDP) is known on the server end (the server will
<= div class=3D"gmail_extra">> =C2=A0 =C2=A0 =C2=A0 =C2=A0 be doing TLS or = DTLS after all, and will know which).

<= /div>
I agree. Making the SNI extension mandatory= seems necessary (and
also an easy requirem= ent since this is a green field application),
but I wasn't able to get agreement from some of my co-authors on
this. Will re-open the discussion.

> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 So it would seem that the client needs to communicate the=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 target po= rt to the server, as the payload of the proposed
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 extension in the client HELLO (exten= sion would no longer
> =C2=A0 =C2=A0 =C2= =A0 =C2=A0 be empty on the client side).
Hmm, I hadn't considered the case of= servers behind NATs. But I guess
IPv4 depl= etion and CGNs might make this a more prevalent (and reasonable)
use case we should try to accommodate.

If we're populat= ing the client side extension with data, it could
carry both the server's name and port.

> =C2=A0 =C2=A0 =C2=A0 =C2= =A0 The server's job is then to produce a set of DNS RRsets
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 whose first element i= s either:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _<port>._<proto= col>.<SNI-FQDN> IN TLSA ...
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 or
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 _<port>._<protocol= >.<SNI-FQDN> IN CNAME ...
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 in the latter= case ultimately along with the TLSA records
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 for the target of the chain of CNAMEs.= =C2=A0 Each CNAME will of
> =C2=A0 =C2= =A0 =C2=A0 =C2=A0 course require proof of the validity of that CNAME (which=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 may be ba= sed on proof of associated DNAME records).
= >
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This = then brings us to the question of whether the server
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 should be willing to attempt to = construct such a set of
> =C2=A0 =C2=A0 = =C2=A0 =C2=A0 records for an arbitrary SNI name the client happens to
=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 send.=C2=A0 It = seems that the answer should generally be "no".
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 This is because otherwise= the client would be able to
> =C2=A0 = =C2=A0 =C2=A0 =C2=A0 trigger arbitrary DNS lookups on the server, which may=
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 impose un= acceptable resource costs (and facilitate DoS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 attacks on the targets of such lookups)= .

Yes,= this would have been obvious to me -- that the server should
only construct chains for its own name(s). But thanks fo= r raising
it. We should make this requireme= nt explicit in the draft.

> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Therefore, servers MUS= T be configured with a list of SNI
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0 domains (or at perhaps domain suffixes) for which = they are
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 w= illing to attempt to produce a validated TLSA RRset.

Yes.

>
> =C2=A0 =C2=A0 A bit lower we have:
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0[= TODO: mention that to reduce the size of the chain, the server can
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 deliver exactly on= e RRsig per RRset, namely the one used to validate
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 the chain as it is built.]
>
> =C2=A0 = =C2=A0 This assumes that the server knows which algorithms the client's=
> =C2=A0 =C2=A0 library supports.=C2=A0= The server can definitely do some trimming
> =C2=A0 =C2=A0 if multiple signatures are present for the same algorit= hm as
> =C2=A0 =C2=A0 a side-effect of k= ey rotation, but it cannot in general trim
= > =C2=A0 =C2=A0 the list down to one signature per RRset, unless the cli= ent's
> =C2=A0 =C2=A0 extension also= signals the supported algorithms (too complex
> =C2=A0 =C2=A0 I think, and serves to help "fingerprint" = the client).

Good point. Maybe it's simplest to remove this requirement, or o= nly=C2=A0
trim obviously safe signatures du= e to key rotation or signatures that=C2=A0
= aren't required (such as a ZSK signature over the DNSKEY RRset -=C2=A0<= /div>
unnecessary but often seen in the wild).

Having t= he client indicate its supported algorithms in the extension
might be worth considering though.

> =C2=A0 =C2=A0 =C2=A0 = =C2=A0Each RRset in the chain is composed of a sequence of wire format DNS<= /div>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0resource re= cords.=C2=A0 The format of the resource record is described in
> =C2=A0 =C2=A0 =C2=A0 =C2=A0RFC 1035 [RFC1035], Sec= tion 3.2.1.=C2=A0 The resource records SHOULD be
> =C2=A0 =C2=A0 =C2=A0 =C2=A0presented in the canonical form and o= rdering as described in RFC 4034
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0[RFC4034].
>
> =C2=A0 =C2=A0 =C2=A0 =C2=A0RRs within the= RRset are ordered canonically, by treating the RDATA
> =C2=A0 =C2=A0 =C2=A0 =C2=A0portion of each RR as a left-jus= tified unsigned octet sequence in
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0which the absence of an octet sorts before a zero o= ctet.
>
= > =C2=A0 =C2=A0 Here, I'd like to lift both the restriction on the o= rder and
> =C2=A0 =C2=A0 canonical form.= =C2=A0 In which case, the server can return the
> =C2=A0 =C2=A0 records in exactly the form it obtained them from i= ts own DNS
> =C2=A0 =C2=A0 server, likel= y not canonically ordered, and quite possibly with
> =C2=A0 =C2=A0 compression!
See previous remarks about ordering - a c= ontinuing discussion topic.

>
> =C2=A0 =C2= =A0 The server may need to make multiple queries to obtain the full
> =C2=A0 =C2=A0 set of records to return to the= client.=C2=A0 In order to make it
> =C2= =A0 =C2=A0 possible to retain DNS compression, the response format needs
> =C2=A0 =C2=A0 to consist of one or more = wire-form DNS packets, each of which
> = =C2=A0 =C2=A0 contains one or more answer RRsets ("additional" an= d "authority"
> =C2=A0 =C2=A0 = records should be discarded at the server end, but with care,
> =C2=A0 =C2=A0 in the unlikely case that compressed = answers point into records
> =C2=A0 =C2= =A0 in the authority or additional sections.)

The Answer section precedes Authori= ty and Additional, and compression
pointers= can only reference prior occurences of names, so your last
concern is probably not a problem.

However, authority section da= ta may not be discardable in some
cases, su= ch as a wildcard record which would need an NSEC & RRSIG
from the authority section.

> =C2=A0 =C2=A0 Thus I think the= right structure for the reply is a sequence
> =C2=A0 =C2=A0 of DNS packets, not a sequence of RRsets.=C2=A0 Compre= ssion is then
> =C2=A0 =C2=A0 scoped to = each individual packet.
>
> =C2=A0 =C2=A0 Of course we could make the server &qu= ot;work harder" by consolidating
> = =C2=A0 =C2=A0 all the DNS packets it receives into a single sequence of RRs= ets
> =C2=A0 =C2=A0 as suggested in the = current draft.=C2=A0 This would typically require
> =C2=A0 =C2=A0 "decompression" and "recompression= " once the full set of RRsets
> =C2= =A0 =C2=A0 is assembled (if I think is best) we opt to minimize the network=
> =C2=A0 =C2=A0 footprint of this exten= sion.

= If we migrate to DNS messages, the best format would be the proposed
<= div class=3D"gmail_extra">EDNS chain query message, which would remove a lo= t of the overhead:

=C2=A0 =C2=A0 http://tools.ietf.org/html/draft-ietf-dnsop-edns-c= hain-query

But we'd need to be to process regular messages for servers th= at don't
support this too. I'll sta= rt some discussion on this topic.

>
> =C2= =A0 =C2=A0 =C2=A0 =C2=A0The first RRset in the chain MUST contain the DANE = records being
> =C2=A0 =C2=A0 =C2=A0 =C2= =A0presented.=C2=A0 The subsequent RRsets MUST be a sequence of DNSKEY and = DS
> =C2=A0 =C2=A0 =C2=A0 =C2=A0RRsets, = starting with a DNSKEY RRset.=C2=A0 Each RRset MUST authenticate
> =C2=A0 =C2=A0 =C2=A0 =C2=A0the preceding RRset:<= /div>
>
> = =C2=A0 =C2=A0 Except of course when it is a CNAME (perhaps a chain of such<= /div>
> =C2=A0 =C2=A0 CNAMEs).=C2=A0 Some name= servers return RRSIGs before the record they
> =C2=A0 =C2=A0 signed.=C2=A0 Again, apart from the first RRset being = either the
> =C2=A0 =C2=A0 desired TLSA = RRset, or a CNAME from its qname ultimately to a
> =C2=A0 =C2=A0 TLSA RRset, the order of records after the first s= hould not be
> =C2=A0 =C2=A0 constrained= .
>
>= =C2=A0 =C2=A0 The client should load them *all* into memory, then validate=
> =C2=A0 =C2=A0 the first (using all pe= rtinent records in the resulting cache)
>= ; =C2=A0 =C2=A0 and recurse if that first record is a CNAME, (being mindful= of
> =C2=A0 =C2=A0 potential loops), un= til it ultimately validates a TLSA RRset,
&= gt; =C2=A0 =C2=A0 which authenticates the server's certificate or bare = public
> =C2=A0 =C2=A0 key (RFC7250).
>
> I&#= 39;ll stop here for now, because if I'm in the rough on the above,
> further comments would likely fall afould = of the same issues.

No, you're not in the rough and I very much appreciate th= e detailed
comments Viktor. As I mentioned,= we're working with some constraints
an= d desires imposed by the likely consumers of this mechanism, but
there is of course room for discussion and refinement= .

--
Shumon Huque

--001a1134ef98b38d70052535123f-- From nobody Fri Nov 27 23:09:20 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C633C1B2FF5 for ; Fri, 27 Nov 2015 23:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.1 X-Spam-Level: X-Spam-Status: No, score=0.1 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NyGJygaNQE4C for ; Fri, 27 Nov 2015 23:09:15 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4792F1B300E for ; Fri, 27 Nov 2015 23:09:15 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D66AF284E34; Sat, 28 Nov 2015 07:09:13 +0000 (UTC) Date: Sat, 28 Nov 2015 07:09:13 +0000 From: Viktor Dukhovni To: dane@ietf.org Message-ID: <20151128070913.GJ18315@mournblade.imrryr.org> References: <20151109045334.GU18315@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [dane] New version of tls-dnssec-chain draft (-02) X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: dane@ietf.org List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Nov 2015 07:09:18 -0000 On Mon, Nov 23, 2015 at 08:19:20AM -0500, Shumon Huque wrote: > Compression in the DNS protocol is currently defined in terms > of DNS messages, so we'd have to define a new scheme. The simplest > would be to redefine (for the purpose of this TLS extension only) the > compression pointer in the label's 1st octet to refer to an offset from > the beginning of the chain data structure. Or, switch to DNS messages. The potential advantage of switching to DNS messages is that this is presumably a format already understood by various libraries. > > Furthermore, this mechanism is, at least for now, *definitely* > > (not just typically) restricted to carrying DANE TLSA records > > and their signatures. > > Yes, it can carry other records (CNAME, DNAME, perhaps NSEC, etc). I think > the point being made in that sentence was that the goal was to validate > a servers TLSA record rather than say the servers address record mapping > (although technically it might be able to do that retrospectively). Yes, I think we should be specific about what the TLS extension carries, namely the TLSA records for (port, protocol, fqdn) triple with any requisite CNAME expansion. > > * Because validation order is not always possible (in presence > > of DNAME/CNAME indirection), it is I think best to not > > suggest that the records are so ordered, even in the case > > when such ordering is possible. > > I agree that CNAME/DNAME indirection makes this trickier. A later section > does describe how ordering is done for CNAME/DNAME chains, essentially > using multiple sequences of ordered RRsets. And therefore I think the ordering requirement is for the most part needlessly restrictive. The processing logic as I see it is: + Bring all the records into a transient empty cache (no external lookups for cache missses, the cache is the entire universe), not losing track of which was the first. + Starting at the first RRset, if it is a CNAME, validate the chain of CNAMES leading to the actual target TLSA RRset. + Validate the target RRset (often the first RRset absent CNAMEs). All the RRsets other than the first are just cached, and so their order is not significant, with one important exception: NSEC3 records that validate wildcard responses need arrive directly after the wildcard response and be stored with that wildcard response. Finding them is cumbersome after the fact. Which brings us back to the message format, if it is just a stream of RRsets (rather than a stream of DNS messages), what binds the NSEC/NSEC3 records to the associated wildcard response? ; ANSWER: ; *._tcp.example.com IN CNAME _dane.example.com. _25._tcp.example.com. IN CNAME _dane.example.com. _dane.example.com. IN TLSA 3 1 1 ... ; AUTHORITY ; This, or equivalent NSEC3 record *._tcp.example.com. IN NSEC example.com. CNAME In what order should these RRsets appear? How are the NSEC (or worse NSEC3) records to be associated with the wildcard (first) answer in a stream of records that is not broken down into the usual query/answer/authority/additional format if they are not explicitly grouped with the packet in question? (Broader search for suitable NSEC3 records across all the returned RRsets?) > > To do otherwise invites > > sloppy implementations that don't correctly deal with > > replies that are unavoidably not strictly ordered. > > The TLS server in this case would be required to order the RRsets > appropriately, regardless of what order they appeared in the DNS > wire messages they received. See above, I think this deserves more thought... > In an ideal world, I agree that it would be better if we could leave > the ordering unspecified, but we're working with requirements from some > of the potential consumers of this. What are these unstated requirements? The discussion will probably be more productive if they are made explicit. > Certificate chains in TLS are ordered > (from EE cert towards trust anchor), and they'd like the DNS RRsets to be > similarly ordered, so that the client can authenticate the data in one > sequential pass through. That was our starting point. Except that in practice (and formally in the TLS 1.3) draft the certificates are not so ordered, and DNS resolution with CNAMEs and wildcard records is not nearly so "linear". > We'll continue to have discussions on this topic (and I'd be happy to > rope you in), but I am a bit reluctant to expend energy to develop a > protocol that application developers won't implement, so I'm trying to > be flexible. This protocol is not something "application developers" should even for a moment consider implementing. It goes into DNS libraries that are enhanced to support this use case. The application will just shunt the records from the TLS server to the library, and get back the validated TLSA RRset or a suitable error. > I agree. Making the SNI extension mandatory seems necessary (and > also an easy requirement since this is a green field application), > but I wasn't able to get agreement from some of my co-authors on > this. Will re-open the discussion. SNI is already required for DANE clients: https://tools.ietf.org/html/rfc7671#section-3 > > So it would seem that the client needs to communicate the > > target port to the server, as the payload of the proposed > > extension in the client HELLO (extension would no longer > > be empty on the client side). > > Hmm, I hadn't considered the case of servers behind NATs. But I guess > IPv4 depletion and CGNs might make this a more prevalent (and reasonable) > use case we should try to accommodate. > > If we're populating the client side extension with data, it could > carry both the server's name and port. Except that SNI already carries the name, so I would not duplicate that. > > [TODO: mention that to reduce the size of the chain, the server can > > deliver exactly one RRsig per RRset, namely the one used to validate > > the chain as it is built.] > > > > This assumes that the server knows which algorithms the client's > > library supports. The server can definitely do some trimming > > if multiple signatures are present for the same algorithm as > > a side-effect of key rotation, but it cannot in general trim > > the list down to one signature per RRset, unless the client's > > extension also signals the supported algorithms (too complex > > I think, and serves to help "fingerprint" the client). > > Good point. Maybe it's simplest to remove this requirement, or only > trim obviously safe signatures due to key rotation or signatures that > aren't required (such as a ZSK signature over the DNSKEY RRset - > unnecessary but often seen in the wild). > > Having the client indicate its supported algorithms in the extension > might be worth considering though. But complicated, because the client might not know which algorithms are supported by its DNS library. The library would have to provide an interface to get that list. If the list is optional, than an empty list should mean that no algorithms can be dropped. As you note, with a bit of work some other redundancies can be eliminated. > If we migrate to DNS messages, the best format would be the proposed > EDNS chain query message, which would remove a lot of the overhead: > > http://tools.ietf.org/html/draft-ietf-dnsop-edns-chain-query > > But we'd need to be to process regular messages for servers that don't > support this too. I'll start some discussion on this topic. It would certainly be good to leverage this if the same format can be used for both. Much more likely to be implemented in DNS libraries if it kills two birds with one stone. Don't know how this works with non-linear results involving non-sibling CNAMEs. > No, you're not in the rough and I very much appreciate the detailed > comments Viktor. As I mentioned, we're working with some constraints > and desires imposed by the likely consumers of this mechanism, but > there is of course room for discussion and refinement. As I mentioned above, if you could be more explicit about these, that might be helpful. -- Viktor. From nobody Sun Nov 29 14:52:21 2015 Return-Path: X-Original-To: dane@ietfa.amsl.com Delivered-To: dane@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C7E91B3775; Sun, 29 Nov 2015 14:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.215 X-Spam-Level: X-Spam-Status: No, score=0.215 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgnj8prXUkSk; Sun, 29 Nov 2015 14:52:16 -0800 (PST) Received: from mail.rozanak.com (mail.rozanak.com [IPv6:2a01:238:42ad:1500:aa19:4238:e48f:61cf]) (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 EA0D01B3772; Sun, 29 Nov 2015 14:52:12 -0800 (PST) Received: from localhost (unknown [127.0.0.1]) by mail.rozanak.com (Postfix) with ESMTP id EB41425CA0C5; Sun, 29 Nov 2015 22:52:10 +0000 (UTC) X-Virus-Scanned: amavisd-new at rozanak.com Received: from mail.rozanak.com ([127.0.0.1]) by localhost (mail.iknowlaws.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3VpuGYYBQAkK; Sun, 29 Nov 2015 23:51:38 +0100 (CET) Received: from kopoli (p200300864F79670B18AC49435F038AE1.dip0.t-ipconnect.de [IPv6:2003:86:4f79:670b:18ac:4943:5f03:8ae1]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.rozanak.com (Postfix) with ESMTPSA id 1637425CA074; Sun, 29 Nov 2015 23:51:38 +0100 (CET) From: "Hosnieh Rafiee" To: Date: Sun, 29 Nov 2015 23:51:32 +0100 Message-ID: <002301d12af8$7ea0d2e0$7be278a0$@rozanak.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdEq+Hnm/LWOYFmVSraYug69QoUG3w== Content-Language: en-us Archived-At: Cc: DNSOP@ietf.org Subject: [dane] a new draft?? Bounding of authentication and authorization X-BeenThere: dane@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DNS-based Authentication of Named Entities List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Nov 2015 22:52:18 -0000 Dear All, Before writing a draft (since I have had some unused drafts so far and ... do not want to repeat the same mistake...), I would like to know the opinion of WG on the overview of an idea for the extension of DANE so that it can be used for other use cases beyond Email and web, especially for certificates based authentication (known as TLS based authentication) of single devices in the network where we have DANE as a complete option in place of PKI model and the first A of AAA model. In other word, the extension focuses on not only giving the TLSA record back to the verifier node but also the references of policy templates in resource policy storage. Let me give you an example to be clearer ( I did not use the real example so that it can be simpler to avoid the use of network related concept) In Alice's enterprise, instead of AAA method, we assume that it is TLS based authentication where authentication is based on the devices' certificates and not the username and password. Therefore, DANE is in use as a way to authenticate the Alice's laptop. Alice need to access business server C and B in her enterprise network after her laptop is being authenticated. For authentication, Alice can herself generates a public/private key and self-sign it. then it goes to the administrator of her enterprise network called Bob to generate the TLSA record of her certificate and store it in the DNS server so that later on business server C can verify Alice by query the DNS server. Further, Bob also creates two new templates in resource policy server and call them template AliceB and AliceC. Then in AliceB it includes the authorization access to business server B and in AliceC it defines Business server C. To provide the binding of the Alice template with the authentication information (certificates), Bob stores the template reference number of Alice policy in a new resource record so called Parent policy Indices (PP RR) on DNS server (This is the extension to DNS to bound the authentication and authorization). Now, Alice tries to access business server C, the business server C asks the certificates of Alice to establish a secure TLS channel. Alice's laptop submits its certificates to business server C. Business server C needs to verify this certificates, it queries the DNS server and asks for TLSA record of Alice. DNS server checks Alice's laptop FQDN that includes in the query of Business server C and retrieves Alice's laptop TLSA record. Further it needs to retrieve the authorization information of Alice's laptop. The extension is that business server C also retrieves the reference numbers that Bob stored it before in PP RR from DNS server along with TLSA record. Then it can query the resource policy storage based on this reference number that is the reference to the Alice template in resource policy and retrieves the ALiCE's authorization information to make sure Alice is authorized to use business server C. With this simple resource record, we added this bounding of authentication and authorization. There might be some questions here such as: 1- Why not to store the whole authorization information on DNS server instead of only storing the reference number Answer: because at the moment in most network infrastructure, there are already resource policy servers that stored the authorization information and it is so costly to restore them all again in a new place otherwise there is easy way of conversion. Further, since DNS is usually publicly available to its local network or global network, therefore, for security reason, not all nodes should be able to know the content of the authorization information. It might leak some critical information about the infrastructure and resources in the network which might be both security and privacy issue. This is why, only reference number and a small readable human text is enough for that. 2- Why not to store the TLSA record also in the resource policy so that the business server C (as in my example) query the resource policy based on the TLSA record. By doing that, we limit the DANE use case and it can no longer be used for some other use cases that we have in our mind for multi-tenancy where each tenants can create subdomain on its own zone and re-assign these policies to its sub-domain. This is because a resource policy usually cannot be shared with the tenant but DNS power allows a tenant to only access its own zone and update its own resources. Therefore, this tenant can also create a sub domain on its own zone and assign a part of its resources to third parties. In my example, Alice can allow David, her employee to access business server B but not business server C by updating DNS server with the TLSA record of David's laptop's certificate and in PP RR adding the template of business server B (AliceB). Therefore, Alice, without the need to ask Bob again, could authorize someone else to only access a part of its authorized resources in the network. The concept can be to some extend similar to OAuth, but the difference is that we want also to reduce CapEx in the network by eliminating the use of PKI infrastructure and any other extra servers or services and the idea is to use the existing resources that is supported by almost all networks for both authentication and authorization purposes. As I said the use case is for network infrastructure but it might have several other use cases that might come to your mind according to my simple example. It would be good to hear some other use cases and ideas. Therefore, the proposed extension is this PP record and the processes of this new resource record so that, TLSA and PP are able to be updated via the DDNS but only by authorized owner, further, PP RR is also given to the verifier node when a node query the TLSA record in case for instance, it sets a flag. I would love to hear your opinion about this and if you think this worth to write it as a draft , I would appreciate any volunteers for that. Thank you, Best, Hosnieh