Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC
Many thanks for reading the draft. > from: "Paul Wouters" on Mon, 2022-04-11 > to: zhangcuiling > cc: dnsop > subject: Re: [DNSOP] A new draft on SM2 digital signature algorithm for DNSSEC > > On Mon, 11 Apr 2022, zhangcuiling wrote: > > > And the main purpose is to improve the diversity of DNSSEC algorithms, and > > to make it convenient for people who want to use SM2 > > digital signature algorithm as an alternative for DNSSEC. > > We actually want to prevent as much diversity as we can, to avoid > creating more new long tails of deployment of algorithms. So a new That sounds reasonable. It does need additional work to support SM2 Digital Signature Algorithm for DNS software implementation. The good news is that Openssl has supported it since version 1.1.1. And I think Openssl is widely used among DNS software. > algorithm should really offer something the others do not. Also having > a number of ECC based algorithms would likely mean if one ends up > broken, all of them end up broken. > > So based on: > > Due to the similarity between SM2 and ECDSA with curve P-256, some > of the material in this document is copied liberally from RFC 6605 > [RFC6605]. > > I don't see a strong reason to adopt another ECC type of algorithm. Sorry that maybe I didn't make it clear. About SM2 and ECDSA: SM2 and ECDSA are similar in the following aspects: the length of the private key (32 octets), public key (64 octets) and the signature (64 octets) are the same. But there is an important difference between these two algorithms, which is the process of signature calculation. So SM2 is a different algorithm from ECDSA. By the way, compared to a totally different algorithm, the similarity between SM2 and ECDSA can reduce the complication of supporting SM2 to some extent. About the security of ECC-based algorithms: As far as I know, the security of ECC-based algorithms is strongly influenced by the curve it uses. Sometimes it's hard to say which curve is much safer. Elliptic curve secp256r1 (for DNSSEC) and secp256k1 (for blockchain) are relatively popular for ECDSA. SM2 uses a different curve and has different process with the signature generation and validation, so I'd like to consider it as an alternative to ECDSA. > > Additionally, in this case SM2/SM3 seems to be ISO standards that are > not freely available, so these are additionally problematic. > I agree with you. I should specify a document that could be downloaded freely. Here is another one introducing SM2/SM3 in detail: "Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 2: Digital signature algorithm" http://www.gmbz.org.cn/upload/2018-07-24/1532401673138056311.pdf It's written in English, but unfortunately it's not an international standard. I will keep on trying to find a more proper document. Thank you again for your time and your helpful comment. Best regards, Cathy Zhang ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications
Hello, thanks for your constructive comments. My answers are just below, with an updated document (from Duane's remarks, Mark's ones will follow later). 1. Beyond the technical aspects, there are several different persons to think about in our case : the DNS administrator obviously, the decision maker buying (or not) a secured online service, and the CISO. It looks more simple to have dedicated RR types to let them communicate together, without any information distortion. It's necessary to explain that the CRS record can play two roles : of course being involved during the authorization mechanism, and as an information for existing or potential customers checking this mechanism support before subscribing to a new service. In that case, any decision maker or CISO can check by himself without sorting all the TXT records found. @Mark : I am just discovering the APL RR now as I didn't notice it when checking what could be reused. It fits the needs of the CRC, with a different syntax, and likely it's still potentially easier to identify when building an inventory of what CRC-CRS contracts an organization has. 2. I updated for compliance with RFC2606 & RFC5737 3. Updated so 4. After your comments and correcting a typo, it gives ftp.example.com_21.example.net Such domain name for sure doesn't exist and uses the underscore character as separator. It has to be considered as storing data establishing a kind of contract between the two organizations involved. 5. I give some explanation in the answer 1 but I will rephrase. The CRS record can be used before subscribing to a service (typically any storage/log system/SIEM) as an indicator that this service provides the kind of authorization process described in the document. More importantly, it can be checked by the application during the authentication to know if the client CRC must be checked or not. However, if an application doesn't want to rely on the CRS RR, it also can use a parameter in its configuration file. Maybe adding a schema would help ? At least, I tested all that prior to sending my first email, with NSD and a modified Apache Tomcat, and I got the results I wanted. Internet Engineering Task Force E. Adell Internet-Draft 12 April 2022 Intended status: Informational Expires: 14 October 2022 Client Roaming Control draft-adell-client-roaming-00 Abstract This document specifies the Client Roaming Control (CRC) DNS Resource Record allowing an organization to better control the access to third-party applications over Internet. The applications implementing an authorization mechanism to honor the CRC, publish on their side the Client Roaming Support (CRS) Resource Record to inform of this support. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 14 October 2022. Copyright Notice Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. AdellExpires 14 October 2022[Page 1] Internet-Draft Client Roaming Control April 2022 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 3. The CRC Resource Record . . . . . . . . . . . . . . . . . . . 4 3.1. RR name field . . . . . . . . . . . . . . . . . . . . . . 4 3.2. CRC RDATA Wire Format . . . . . . . . . . . . . . . . . . 4 3.3. CRC Presentation Format . . . . . . . . . . . . . . . . . 4 4. The CRS Resource Record . . . . . . . . . . . . . . . . . . . 5 4.1. CRS RDATA Wire Format . . . . . . . . . . . . .
Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications
On Tue, 12 Apr 2022, Eugène Adell wrote: Beyond the technical aspects, there are several different persons to think about in our case : the DNS administrator obviously, the decision maker buying (or not) a secured online service, and the CISO. Why should this information exchange happen via DNS? It looks more simple to have dedicated RR types to let them communicate together It seems a REST API using some .well-known HTTPS link seems a better fit ? After your comments and correcting a typo, it gives ftp.example.com_21.example.net Such domain name for sure doesn't exist and uses the underscore character as separator. It has to be considered as storing data establishing a kind of contract between the two organizations involved. It should have a dot in between, eg ftp.example.com._21.example.net. Then, the underscore name should be uniquely identifying to split it from other DNS records. eg _crs or something. Have a look at other documents at https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names 5. I give some explanation in the answer 1 but I will rephrase. The CRS record can be used before subscribing to a service (typically any storage/log system/SIEM) as an indicator that this service provides the kind of authorization process described in the document. I still wonder if DNS is really the right fit for this. This document specifies the Client Roaming Control (CRC) DNS Resource Record allowing an organization to better control the access to third-party applications over Internet. The applications implementing an authorization mechanism to honor the CRC, publish on their side the Client Roaming Support (CRS) Resource Record to inform of this support. There is a big overlap here with MUD, see https://datatracker.ietf.org/doc/html/rfc8520 It also seems the source of authorization depends on the DNS name, but how do you ensure a device would not be lying about their name? Would this only work on zones with static DNS entries? If so, how would that scale? What would be the mechanism to authorize the publishing of CRS/CRC records, and why can that provisioning protocol not also be used to query/signal this data? Paul___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] introducing a couple of RRTypes (CRC/CRS) for B2B applications
Hi Paul, in the implementation I suggested, the new DNS RR types are not used for making people (administrator, decision-maker, CISO) communicating together but as an information source that is simple enough to be understood by everyone without the need of filtering and sorting data. I commented that to explain why new types are necessary, although CRC can be replaced with APL. Why use DNS at all ? Likely many server software can be modified to use the implementation suggested, while creating dependencies to another protocol not already supported by the server looks worse. For example, it's maybe not a good idea to update an FTP or LDAP server to support HTTP only to download a text file containing these networks allowed. And they would probably still need to start by a DNS request to find that file. If the Client DNS (CRC) is lying or not configured as asked by the CISO, the client organization might expose data and it's an internal threat to this organization. If the server DNS (CRS) is lying, the client organization might complain as the contract (if any) is not honored. If all is implemented/configured correctly and one client is lying on its identity (wrong information sent during the authentication for example), there is a mismatch between its real and expected IP addresses, and no authorization at the end. The use-case I'm thinking about is indeed for static entries handled manually. In my past experience, I would say each company I worked for would have benefited of some similar entries (5~10) without thinking "big". The mechanism to authorize these records is somewhat administrative for the CRC (the decision-maker asks the CISO who in turns asks the DNS admin to add a record), and limited for the CRS (a new application is brought online, with its own domain name, and an associated CRS record). As it's intended for Business-to-business, both parts still agree by another kind of contract, and I don't any necessity to have something more for the provisioning. E.A. Le mar. 12 avr. 2022 à 14:28, Paul Wouters a écrit : > > On Tue, 12 Apr 2022, Eugène Adell wrote: > > > Beyond the technical aspects, there are several different persons to > > think about in our case : the DNS administrator obviously, the > > decision maker buying (or not) a secured online service, and the CISO. > > Why should this information exchange happen via DNS? > > > It looks more simple to have dedicated RR types to let them > > communicate together > > It seems a REST API using some .well-known HTTPS link seems a better > fit ? > > > After your comments and correcting a typo, it gives > > ftp.example.com_21.example.net > > Such domain name for sure doesn't exist and uses the underscore > > character as separator. It has to be considered as storing data > > establishing a kind of contract between the two organizations > > involved. > > It should have a dot in between, eg ftp.example.com._21.example.net. > Then, the underscore name should be uniquely identifying to split it > from other DNS records. eg _crs or something. Have a look at other > documents at > https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names > > > 5. > > I give some explanation in the answer 1 but I will rephrase. The CRS > > record can be used before subscribing to a service (typically any > > storage/log system/SIEM) as an indicator that this service provides > > the kind of authorization process described in the document. > > I still wonder if DNS is really the right fit for this. > > > This document specifies the Client Roaming Control (CRC) DNS Resource > > Record allowing an organization to better control the access to > > third-party applications over Internet. The applications > > implementing an authorization mechanism to honor the CRC, publish on > > their side the Client Roaming Support (CRS) Resource Record to inform > > of this support. > > There is a big overlap here with MUD, see > https://datatracker.ietf.org/doc/html/rfc8520 > > It also seems the source of authorization depends on the DNS name, but > how do you ensure a device would not be lying about their name? Would > this only work on zones with static DNS entries? If so, how would that > scale? > > What would be the mechanism to authorize the publishing of CRS/CRC > records, and why can that provisioning protocol not also be used > to query/signal this data? > > Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IANA Policy for SVCB
I think Expert Review makes sense (with the expert reviewing the SHOULD around the specification). On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote: > I agree with Tommy. > > Selecting an expert who is able to recognize when wider review might help > is a far lower bar than the one Ray suggests might be necessary. > > On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: > > If this space is not extensible from non-IETF RFCs, we’ll have missed > > the mark. The space is designed to be large (65K) to allow new work to > > easily use this extensibility. We don’t need to be too conservative > > with this space. > > > > I disagree that there wouldn’t be good experts — we have authors of the > > document who have seen it through, and we have more people using this > > RR and gaining expertise. > > > > Expert review is the right balance here. > > > > Tommy > > > >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy > wrote: > >> > >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote: > >>> I am concerned that the set of Expert Reviewers necessary to handle > SVCB > >>> needs to have both expert DNS experience *and* detailed knowledge of > the > >>> SVCB model for this to work. > >>> > >>> I am not sure there's anybody who fits that criteria. > >> > >> Specification Required also assumes a community that can produce them, > which presumably contains the right experts. > >> > >> Are we actually moving toward IETF Review here? > >> > >> -MSK > >> ___ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > ___ > > DNSOP mailing list > > DNSOP@ietf.org > > https://www.ietf.org/mailman/listinfo/dnsop > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IANA Policy for SVCB
I'm happy as long as things are still fast and easy enough to support new/experimental/prototype usage. I think Expert Review with the proposed stuff for that expert to review is all reasonable for that goal. If we start getting into stricter bars than Expert Review, that's where we'd have to start discussing the complexity of breaking off separate private-use and experimental blocks with a lower bar. On Tue, Apr 12, 2022 at 3:10 PM Erik Nygren wrote: > I think Expert Review makes sense (with the expert reviewing the SHOULD > around the specification). > > On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote: > >> I agree with Tommy. >> >> Selecting an expert who is able to recognize when wider review might help >> is a far lower bar than the one Ray suggests might be necessary. >> >> On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: >> > If this space is not extensible from non-IETF RFCs, we’ll have missed >> > the mark. The space is designed to be large (65K) to allow new work to >> > easily use this extensibility. We don’t need to be too conservative >> > with this space. >> > >> > I disagree that there wouldn’t be good experts — we have authors of the >> > document who have seen it through, and we have more people using this >> > RR and gaining expertise. >> > >> > Expert review is the right balance here. >> > >> > Tommy >> > >> >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy >> wrote: >> >> >> >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote: >> >>> I am concerned that the set of Expert Reviewers necessary to handle >> SVCB >> >>> needs to have both expert DNS experience *and* detailed knowledge of >> the >> >>> SVCB model for this to work. >> >>> >> >>> I am not sure there's anybody who fits that criteria. >> >> >> >> Specification Required also assumes a community that can produce them, >> which presumably contains the right experts. >> >> >> >> Are we actually moving toward IETF Review here? >> >> >> >> -MSK >> >> ___ >> >> DNSOP mailing list >> >> DNSOP@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dnsop >> > >> > ___ >> > DNSOP mailing list >> > DNSOP@ietf.org >> > https://www.ietf.org/mailman/listinfo/dnsop >> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] IANA Policy for SVCB
Also let's ensure there are several experts like we have for new RR Types. On Tue, Apr 12, 2022 at 4:06 PM Eric Orth wrote: > I'm happy as long as things are still fast and easy enough to support > new/experimental/prototype usage. I think Expert Review with the proposed > stuff for that expert to review is all reasonable for that goal. If we > start getting into stricter bars than Expert Review, that's where we'd have > to start discussing the complexity of breaking off separate private-use and > experimental blocks with a lower bar. > > On Tue, Apr 12, 2022 at 3:10 PM Erik Nygren wrote: > >> I think Expert Review makes sense (with the expert reviewing the SHOULD >> around the specification). >> >> On Tue, Mar 22, 2022 at 8:34 PM Martin Thomson wrote: >> >>> I agree with Tommy. >>> >>> Selecting an expert who is able to recognize when wider review might >>> help is a far lower bar than the one Ray suggests might be necessary. >>> >>> On Wed, Mar 23, 2022, at 05:29, Tommy Pauly wrote: >>> > If this space is not extensible from non-IETF RFCs, we’ll have missed >>> > the mark. The space is designed to be large (65K) to allow new work to >>> > easily use this extensibility. We don’t need to be too conservative >>> > with this space. >>> > >>> > I disagree that there wouldn’t be good experts — we have authors of >>> the >>> > document who have seen it through, and we have more people using this >>> > RR and gaining expertise. >>> > >>> > Expert review is the right balance here. >>> > >>> > Tommy >>> > >>> >> On Mar 22, 2022, at 9:24 AM, Murray S. Kucherawy >>> wrote: >>> >> >>> >> On Tue, Mar 22, 2022 at 9:10 AM Ray Bellis wrote: >>> >>> I am concerned that the set of Expert Reviewers necessary to handle >>> SVCB >>> >>> needs to have both expert DNS experience *and* detailed knowledge of >>> the >>> >>> SVCB model for this to work. >>> >>> >>> >>> I am not sure there's anybody who fits that criteria. >>> >> >>> >> Specification Required also assumes a community that can produce >>> them, which presumably contains the right experts. >>> >> >>> >> Are we actually moving toward IETF Review here? >>> >> >>> >> -MSK >>> >> ___ >>> >> DNSOP mailing list >>> >> DNSOP@ietf.org >>> >> https://www.ietf.org/mailman/listinfo/dnsop >>> > >>> > ___ >>> > DNSOP mailing list >>> > DNSOP@ietf.org >>> > https://www.ietf.org/mailman/listinfo/dnsop >>> >>> ___ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>> >> ___ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >> > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
