Re: [DNSOP] [dnsext] CGA-TSIG - new version
Follow up, I thought again about the possible attacks scenarios. I concluded that I also need to include the new public key in the content of the old signature. This means the old signature should be new public key + timestamp, otherwise the attacker might have a possibility (a few seconds) to do the replay attack by copying the old public key and oldsignature. So, you're right, it still might cause the attacker to attack. But to avoid increasing packet size, it is only enough for the two values that is new public key and timestamp. Since the new public key is verified by both CGA verification process and also the new signature and the old public key is verified by old signature. I will correct this in the next version of the document. Thanks, Best, Hosnieh -Original Message- From: dnsext [mailto:dnsext-boun...@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Sunday, February 16, 2014 12:41 PM To: 'Marc Buijsman' Cc: 'Jeroen van der Ham'; DNSOP@ietf.org; dns...@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version Dear Marc, Thanks for your comments. Regarding the size of the length fields, however, I'm still confused by what you are trying to say. I did not consider the number of bits, I really considered the number of bytes (octets). If I wanted to encode the length in bits (and I don't), I would have set the value to 2048. But I'm dividing by 8 and set the value to 256 instead, which is the length in *bytes* as you said yourself. The reason why you divide by 8 a second time is a mystery to me. The outcome would then be the number of groups of 8 bytes, but I've never seen a length encoding before that counts such 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32 octobytes, while I am counting 256 bytes (as usual). Also, I don't understand what you mean to say by multiple of 8. If the encoding would be in bits (and again, it's not) and the data is always a number of whole bytes, then yes the value would be a multiple of 8. But we are talking about an encoding in bytes here, which do not necessarily come in groups of 8 (and is therefore not necessarily a multiple of 8). I also don't know what checksum fields you mean or how their length is relevant here, but the IPv4 header checksum field and UDP checksum field in a regular DNS packet are two bytes each. http://tools.ietf.org/html/rfc3971#section-5.1 maybe my wording is not correct. Check the length field here. 8 bits is really not enough for that. So, If you check the implementation of SeNDs (Docomo, etc). what they do is they shift the values or easier way is to divide by 8. With regard to the old signature: how would including more fields in the digest operation increase the packet size? No matter how many fields you digest, the resulting signature is always of the same length. And the fields I was referring to are already part of the packet. In order to be able to authenticate the new public key, you MUST at least include the new public key in the digest operation. Otherwise the packet could be intercepted and the new public key could be replaced without notice. You're not talking about SHA1 digest, you're talking about digital signature. It depends on the input data. This is why , for example, in SeND they included padding at the end that this value can be the multiple of 8. If this value had a fixed size, they would not include any length to it. In RFCs they usually include lengths when the length of value is variable and without length field, one cannot determine the length. http://tools.ietf.org/html/rfc3971#section-5.2 So, this value is not actually the same size and depends on the plain text that one wants to sign. Secondly, if you check the content of the signature, you will notice that I included all the DNS message and it is not like before. Because the new signature is verified before old signature, no replay attack can be happened since the new signature verification will be failed. So no need to sign a large data for old signature field and only timestamp or a small value is enough just to show that this node is the owner of this public key. To avoid replay attack again, I consider to sign the timestamp. I hope this answer your questions. Thanks, Best, Hosnieh Kind regards, Marc Buijsman Hosnieh Rafiee schreef op 15-2-2014 0:07: Thanks for the information you've provided, I improved the document according to comments and found out that the report also has a few problems which is due to the fact that it misinterpreted the of CGA-TSIG document. Here I explain the problems or the reasons of choices: - CGA-TSIG cannot use MAC as a signature field. The purpose was that to have all the CGA data in one section instead of trying to find them in different sections of TSIG. - sizes of length encoding: It is one byte. It is enough for
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On 2/15/2014 11:15 PM, Patrik Fältström wrote: The largest problem for IETF and DNS innovation is that the consensus in IETF seems to be that innovation of DNS is not possible unless it involves reuse of the TXT resource record. That assertion is quite wrong on both process and technical grounds Process: There is certainly a long history of very strong resistance from a core group of DNS advocates in the IETF; and yes, there is an IAB report that doesn't like TXT usage. But there is also a long history of other folk adding DNS usage in spite of that. So a casual claim of IETF consensus is simply false. Technical: The use of underscore-based naming variations has provided an easy, efficient and safe means of eliminating TXT usage ambiguity. By way of examples, note the SRV record and DKIM, but there are others. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] CGA-TSIG - new version
Dear Marc, Thanks again for your message. Let me first react to your first email of today. CGA uses the RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I understand it as explained at http://tools.ietf.org/html/rfc3447#section-8.2.1 is that the length of the output signature S only depends on the length k of the RSA modulus n, and not on the length of the input message M. The algorithm accomplishes this by using a hash function on message M, SHA-1 in case of CGA. So provided that the RSA key has been determined, it does not matter how many fields you concatenate and take as input message M (although there is a maximum depending on the chosen hash function); the output will always be a signature of length k. The signature field is variable because the RSA key size is variable; not because the message is variable. You're right I guess I was confused two different things -- data encryption and signature generation. I re-checked the signature generation algorithm. Since first the data is hashed using SHA function and then the digest is encrypted using a private key, this will lead to having the same length signature. But I need to update the document that the signature should be generated based on the standard RSASSA-PKCS1-v1_5 or for ECC (as a future replacement of RSA) there should be a standard way. Because I think it is necessary to also consider other SHA algorithms since SHA1 is no longer consider a very strong hash function and CGA-TSIG needs to support any future changes to other algorithms. I was not aware that SEND actually encodes groups of 8 bytes. I thought you meant that the value set in the length field should be a multiple of 8, but now I see you mean that the length of the data itself should be a multiple of 8. It is then logical that you might need padding to be able to make whole 'octobytes'. However, I don't believe that this padding is needed for the signature operation since the hash function takes a variable amount of input bytes anyway. You also didn't mention anything about padding in your draft (nor does the CGA RFC), so I assumed the encoded length to be in bytes just like the other length-encoding fields in the TSIG RR. I'm also not sure if you save more space by using 1 byte for the length-encoding field and additional padding, instead of 2 bytes for the length-encoding field without padding. IMHO, we do not really need two bytes and no padding is also needed. Because I think if the encryption is on hash function, then it always generates the same values that is multiple of 8. To have a proof of concept, I checked RSA signature a few minutes ago with different key sizes (1024bits , 1280bits, 1536bits, 1792bits,2048bits, 3072bits) and the result was always the multiple of 8. Regarding the old signature, I think you could even leave out the timestamp from the old signature operation. As long as you sign the new public key with the old public key (with the old signature as ouput) in order to authenticate the new public key, it is also possible to authenticate the timestamp and fudge field provided that they have been signed with the new public key (as required by TSIG, which recommends a fudge value of 300 seconds i.e. 5 minutes, a bit more than a few seconds). Hum... I guess you're right. Signing only the new public key is enough and in this case no timestamp is needed for the old signature (not new signature). I know the attacker only has a small period of time to do this attack and if it cannot do it, since the new public key is replaced with the old one on the DNS server, it cannot do this attack anymore or this attack is not effective as there is no old public key anymore valid. So I assume this scenario can be like this: The original node wants to change its IP address or public key. It signs all DNS message excluding the signature fields using its own new private key and sign the new public key using its own old private key. Then submit this packet including the TSIG RR with CGA-TSIG DATA The attacker eavesdrops and copy only the old public key and old signature from the packet and sign the DNS message using its own private key and submit this value... But the verification of the old signature fails since the attacker cannot copy the new public key of the original node. If it does this, the CGA verification will be failed and the node cannot prove the owner of this public key. So, By assuming such failure in the attack scenario. I guess only signing the new public key for old signature is enough. For this purpose no more authentication is needed since the time has been already checked for the new signature. Thanks, Best, Hosnieh ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On Feb 15, 2014, at 11:15 PM, Patrik Fältström p...@frobbit.se wrote: On 2014-02-16 03:04, David Conrad wrote: Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a seeding ground)? The largest problem for IETF and DNS innovation is that the consensus in IETF seems to be that innovation of DNS is not possible unless it involves reuse of the TXT resource record. Sorry, friend, but this is trolling. Or do you believe that DANE is not an innovation? --Paul Hoffman signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On 02/16/2014 04:52 PM, Paul Hoffman wrote: Sorry, friend, but this is trolling. Or do you believe that DANE is not an innovation? Well, I personally am not so sure that the delta to CERT records (RFC 4398) is all that big, so is this really the best example you have? ;-). ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On 2/16/2014 6:03 AM, Patrik Fältström wrote: I think this email make exactly my point. Please explain. By way of anticipating your response, I should not have removed your key conclusion: Unless that is put to rest, we can not do much at all. That is demonstrably not true, as well as the claim of consensus about not being able to do anything being wrong. But even at the simple fact level, are you under the impression that SRV uses TXT? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On 2014-02-16 17:39, Patrik Fältström wrote: On 2014-02-16 16:52, Paul Hoffman wrote: On Feb 15, 2014, at 11:15 PM, Patrik Fältström p...@frobbit.se wrote: On 2014-02-16 03:04, David Conrad wrote: Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a seeding ground)? The largest problem for IETF and DNS innovation is that the consensus in IETF seems to be that innovation of DNS is not possible unless it involves reuse of the TXT resource record. Sorry, friend, but this is trolling. Or do you believe that DANE is not an innovation? I think so, What I mean is that I *DO* think DANE is an innovation! and I like DANE, I am all in favor of innovation, but I see strong forces against DANE, inside IETF. Yes, I am just starting to investigate and try to mitigate, but the forces against are the ones I see too often: - We can not use new RR Types, lets use A and TXT - DNSSEC will never take off - Lets just use HTTP for transport My point is that to get innovation, we have to over and over and over again address these issues. Ok, I take Daves point that there is no consensus from a process definition of consensus in the IETF, but the _feeling_ is that there is consensus as there is no consensus that we CAN add new RR-Types etc. Just look at the SPF discussion, or the cert-for-secure-xmpp which is what I refer to regarding we can not use DANE as DNSSEC is not deployed. I see too many similarities between the two. And as I wrote, I claim those views block innovation more than anything else in IETF at the moment. Patrik ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop signature.asc Description: OpenPGP digital signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On 2014-02-16, at 11:39, Patrik Fältström p...@frobbit.se wrote: - We can not use new RR Types, lets use A and TXT - DNSSEC will never take off - Lets just use HTTP for transport I think we are suffering from a knee-jerk instinct to say no to ideas that we assume will never work in the real world. We can't add more transports (e.g. SCTP), because even if implemented there's just too much middleware in the world that will interact badly. We can't add more resource records, because there are nameserver implementations that don't deal with opaque types properly, and won't allow the new resource records to be published. We can't do anything that will cause larger responses, because EDNS support is not widespread, and in any case the network can't reliably deliver fragments. If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them. What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. Rich people are the ones that realise that you only need one out of ten business ventures to succeed to get a pay out. So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments are not necessary? Anybody else feel like working on the specification for SCTP transport? :-) Joe signature.asc Description: Message signed with OpenPGP using GPGMail ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
Joe Abley wrote: ... If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them. reflection attacks aren't a fact of life. DNS RRL does not require a forklift upgrade of the infrastructure, isn't stopped by middleboxes, and does not change the protocol. i think you should discriminate more finely as to what we ought and ought not give up about. What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. ... those were my exact words upon the publication of RFC 2671. it's been fifteen years. i think if any change to the dns protocol was going to be useful enough to overcome edge corruption and edge inertia, it would be EDNS0. however, it's heartening to see another generation of cannon fodder lining up to enter the trenches. you go, joe. i'll cheer you on. but i'll be working on a RESTful/JSON API to hide DNS edge traffic inside TLS, in sessions not managed by any X.509 CA, while cheering you on. So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments are not necessary? Anybody else feel like working on the specification for SCTP transport? :-) go, joe, go! vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] CGA-TSIG - new version
Dear Marc, Yes, that's what I thought too, so that's why I proposed to use 1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1. IMHO, we do not really need two bytes and no padding is also needed. Because I think if the encryption is on hash function, then it always generates the same values that is multiple of 8. To have a proof of concept, I checked RSA signature a few minutes ago with different key sizes (1024bits , 1280bits, 1536bits, 1792bits,2048bits, 3072bits) and the result was always the multiple of 8. This is indeed true for the signature fields. However, you also defined single- byte length fields for the complete CGA-TSIG DATA field, the Parameters field and the Old PK field (not in the table in section 4.1 of draft 07, but you do in the figure in section 4.2). The Parameters field includes the public key, which consists of (for example) an 1024-bit modulus, but also of a variably sized exponent (say 3 bytes), PLUS the bytes of the encapsulating DER encoding. According to my calculations, this requires a minimum of 161 bytes for the complete DER-encoded public key. If you then add the 16-byte modifier, the 8-byte prefix, the 1-byte collision count, and 0 bytes for the extension fields (but this one is variable as well), then you get a total size of 186 for the Parameters field, which is not a multiple of 8. You would then need 6 bytes of additional padding, or fiddle with the padding inside the DER structure (but I don't think this is desirable). Assuming that the Old PK is also a DER-encoded ASN.1 structure and that an Old PK of similar size is added to the packet (161 + 7 bytes padding), then the complete CGA-TSIG DATA field would be of size 660 (including 22 bytes for the encoding of 1.2.840.113549.1.1.5 in domain name syntax and two signatures of length 128), which requires an additional padding of 4 bytes to make it a multiple of 8. So the total padding in this case would be 6 + 7 + 4 = 17 bytes. However, if you would use 2 bytes for all five length fields then you don't need padding and you would actually spare 17 - 5 = 12 bytes. To be honest, I don't think the difference is significant enough with respect to the total size of 664 bytes to make it a strong argument for using 2-byte length fields, but I do think that it makes implementing CGA-TSIG much more straightforward without having the hassle of adding paddings to each variably sized field. It would also be in line with the size of the length fields defined by TSIG, which are also 2 bytes. Agreed. For CGA-TSIG data structure, I will change it but for signatures, I will let it to be only 8 bits since it does not need it. Agreed. That only leaves the problem of how you notify your clients of your new IPv6 address. :) It is also not a problem. I addressed it in the new version. The client receives the IP address of the DNS server from the option of the router advertisement (if it wants to be secure) and this is the recommended way. So, the routers usually sends the RA message in a frequent intervals. This also inform the clients about any changes of the DNS information such as the DNS IP addresses. I just explain a possible attack scenario here A node receives a RA message and after verification accepts that router prefix and also sets its DNS IP address (resolver A). Whenever it wants to resolve any domain names, it asks the resolver A to translate a domain to an iP address. Now consider a case where resolver A changes its IP address for whatever reason. If we say that the RA message interval is 10 minutes. The node now wants to resolve a name and since it hasn't yet received any new RA message, it sends a message to the old resolver. We assume that the attacker can eavesdrop this message. He immediately answers instead of legitimate resolver (since there is no resolver using that old IP address). The resolver, according to CGA-TSIG document, needs to include the CGA-TSIG data structure that enables the other nodes to verify it. Since the attacker does not have the private key of the legitimate resolver, it cannot spoof the old IP address of the legitimate resolver since the CGA verification will fails and signature is not valid if the time signed is an old time. So, this attack fails. But only the problem is that the node needs to either wait for another RA message to receive the new information about the resolver or can send a RS message and ask for a new RA message to save time. This can happen after the node does not receive any response from the legitimate resolver. It then assumes that the legitimate resolver is not alive anymore. The other way to solve this problem is that. The resolver announce the nodes who wants to communicate, about the changes in its IP address. But this is more complicated than the first solution. Because, the node should know when the resolver wants to change its IP address. However, we can decrease the complexity by having a
Re: [DNSOP] AS112 bits and pieces
In message alpine.deb.2.03.1402141618310.14...@iskra.ottix.net, William F. Maton Sotomayor writes: On Fri, 14 Feb 2014, Tony Finch wrote: Joe Abley jab...@hopcount.ca wrote: Reactions and reviews of the two documents would be most welcome! The as112-dname draft still does not mention the glibc DNAME logging bug. Which Linux distro, or a set of Linux distros? Some seaches yield various bug reports related to DNAME over the last few years in a couple of distros. Really does it matter? The answer gets correctly processed and a little syslog noise is produced. If you have the problem upgrade / report it. B.T.W. FreeBSD cleaned this up in 2007. http://svnweb.freebsd.org/base/release/10.0.0/lib/libc/net/gethostbydns.c?r1=188315r2=188316; https://www.ietf.org/mail-archive/web/dnsop/current/msg10638.html Typo: flexibl Apart from that, looks OK :-) +1 Tony. -- f.anthony.n.finch d...@dotat.at http://dotat.at/ Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first. Rough, becoming slight or moderate. Showers, rain at first. Moderate or good, occasionally poor at first. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop wfms ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On Sun, 16 Feb 2014, Dave Crocker wrote: On 2/16/2014 6:03 AM, Patrik Fältström wrote: I think this email make exactly my point. Please explain. By way of anticipating your response, I should not have removed your key conclusion: Unless that is put to rest, we can not do much at all. That is demonstrably not true, as well as the claim of consensus about not being able to do anything being wrong. Needing TXT records is really a red herring. For instance, look at http://tools.ietf.org/html/draft-wouters-dane-openpgp-02 and the implementation in: https://github.com/letoams/openpgpkey-milter (with supporting https://github.com/letoams/hash-slinger/blob/master/openpgpkey ) It uses a private use RRtype of 65280 and helps you create an RFC 3597 Generic Record type for records. At any time can now, I can ask for an IANA registration - I've just waited a bit for a discussion and WG adoption. At no point in time did I need to use TXT records and at no point in time did I need to modify DNS software. So yes, innovation via TXT record has been put to rest a long long time ago. The problem we have now is purely in process. During the last few IETF meetings, I was always told I was a guest at DNSOPs, that it is the wrong place for discussion about new RRtypes or EDNS options, and I've been forced to use the DNSEXT mailing list of a closed WG. DNSOP needs to broaden its charter, or we need to revive some kind of DNSEXT group. So let's discuss WG scope and not TXT records. Thanks, Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On 2/15/14, 9:04 PM, David Conrad wrote: [perpass dropped from ccs] On Feb 15, 2014, at 11:57 AM, Paul Wouters p...@nohats.ca wrote: At ietf87 it was planned to have a discussion at dnsop about this continued problem of drafts that fall between operations and extensions and the fact that dnsext closed down. Nothing happened at ietf87 or ietf88. I hope to see this as agenda item for dnsop this meeting. We need a WG to discuss DNS innovation. At the Vancouver DNSOP meeting when there was some discussion I thought was protocol development related, I got up to the mike asked if DNSOP was the right place for that discussion, being righteously indignant that DNSOP would discuss something non-operational. However, after sitting down someone pointed out to me that one of the common recurrent complaints about the IETF is that operators tend to get excluded and that maybe DNSOP is actually the best place to discuss DNS protocol development since that's where operators go. Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a seeding ground)? As the co-chair or DNSOP who took this rather liberal view of our charter, I attempted to use the focus be the 'operational impacts' of several of the proposals, such at Mr. Wouter's too on tcp keepalives and query chaining. I do believe it was the right thing to do, and I continue to do so. We had great discussion on the topic and while nothing could be agreed on, there was some solid advice to take back on the issues. One of the things we've been discussing internally (and have been negligent in bringing forward to the group) with our glorious ADs is expanding the charter. tim ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [perpass] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS
Dear all, This proposal has multiple shortcomings compared to DNSCurve. First off, it says that the rationale for TLS over DNSCurve is simply to take advantage of TLS. I would respectfully submit that DJB can do a better job than the TLS committee, and did. Merely adding bolts and nuts onto a design is not improving it. Secondly, this proposal only works on TCP. This imposes latency and state requirements that most people would rather avoid. The use of keepalive only addresses computational burden, not state burden, and with the DH speed records we have today unnecessary. Thirdly, this proposal ignores entirely how to validate the server over the TLS connection. Does it need a certificate? Who should be allowed to sign it? How should it be validated? DNSSEC provides a PKI, and this proposal provides another one. Their interactions will not be fun. Fourthly, there is substantial operational knowledge and deployed, working, code implementing DNSCurve. This does not hold for this proposal. Sincerely, Watson Ladd ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [perpass] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS
On Sat, Feb 15, 2014 at 8:44 AM, Watson Ladd watsonbl...@gmail.com wrote: Dear all, This proposal has multiple shortcomings compared to DNSCurve. And some advantages over DNSCurve. First off, it says that the rationale for TLS over DNSCurve is simply to take advantage of TLS. I would respectfully submit that DJB can do a better job than the TLS committee, and did. Merely adding bolts and nuts onto a design is not improving it. That is a value judgement that cannot be measured. While DJB's crypto algorithms have been widely adopted, his crypto protocols have not. Secondly, this proposal only works on TCP. This imposes latency and state requirements that most people would rather avoid. The use of keepalive only addresses computational burden, not state burden, and with the DH speed records we have today unnecessary. That is a measureable criticism. Note that DNSCurve trades latency and state for massive amounts more computation by parties who might not care to do any. Even after many years, there has been no noticeable interest in DNSCurve from those whom that protocol would hit the hardest. Thirdly, this proposal ignores entirely how to validate the server over the TLS connection. True. Does it need a certificate? No. Who should be allowed to sign it? Allowed? Are we now the identity police? How should it be validated? Using TLS authentication. DNSSEC provides a PKI, and this proposal provides another one. Their interactions will not be fun. They in fact might be fun; they have barely been explored. Fourthly, there is substantial operational knowledge and deployed, working, code implementing DNSCurve. This does not hold for this proposal. I question substantial and operational at the level that is expected for this protocol. Regardless, there is substantial operational knowledge of TLS that dwarfs whatever has been done for DNSCurve. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [perpass] draft-hzhwm-start-tls-for-dns-00: Starting TLS over DNS
Cherry-picking the worst of the assertions... On Sat, Feb 15, 2014 at 10:08 AM, Paul Vixie p...@redbarn.org wrote: has mr. bernstein's Curve25519 (see http://en.wikipedia.org/wiki/Curve25519) been explicitly validated by other crypto experts? Yes. last i knew he was the only one claiming it was correct and strong enough for production use. It has been widely discussed with no papers showing any flaws at all. The crypto is not in question: the rest of the protocol is. --Paul Hoffman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] CGA-TSIG - new version
Dear Hosnieh, You're right I guess I was confused two different things -- data encryption and signature generation. I re-checked the signature generation algorithm. Since first the data is hashed using SHA function and then the digest is encrypted using a private key, this will lead to having the same length signature. I'm glad you agree. :) But I need to update the document that the signature should be generated based on the standard RSASSA-PKCS1-v1_5 or for ECC (as a future replacement of RSA) there should be a standard way. Because I think it is necessary to also consider other SHA algorithms since SHA1 is no longer consider a very strong hash function and CGA-TSIG needs to support any future changes to other algorithms. Yes, that's what I thought too, so that's why I proposed to use 1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1. IMHO, we do not really need two bytes and no padding is also needed. Because I think if the encryption is on hash function, then it always generates the same values that is multiple of 8. To have a proof of concept, I checked RSA signature a few minutes ago with different key sizes (1024bits , 1280bits, 1536bits, 1792bits,2048bits, 3072bits) and the result was always the multiple of 8. This is indeed true for the signature fields. However, you also defined single-byte length fields for the complete CGA-TSIG DATA field, the Parameters field and the Old PK field (not in the table in section 4.1 of draft 07, but you do in the figure in section 4.2). The Parameters field includes the public key, which consists of (for example) an 1024-bit modulus, but also of a variably sized exponent (say 3 bytes), PLUS the bytes of the encapsulating DER encoding. According to my calculations, this requires a minimum of 161 bytes for the complete DER-encoded public key. If you then add the 16-byte modifier, the 8-byte prefix, the 1-byte collision count, and 0 bytes for the extension fields (but this one is variable as well), then you get a total size of 186 for the Parameters field, which is not a multiple of 8. You would then need 6 bytes of additional padding, or fiddle with the padding inside the DER structure (but I don't think this is desirable). Assuming that the Old PK is also a DER-encoded ASN.1 structure and that an Old PK of similar size is added to the packet (161 + 7 bytes padding), then the complete CGA-TSIG DATA field would be of size 660 (including 22 bytes for the encoding of 1.2.840.113549.1.1.5 in domain name syntax and two signatures of length 128), which requires an additional padding of 4 bytes to make it a multiple of 8. So the total padding in this case would be 6 + 7 + 4 = 17 bytes. However, if you would use 2 bytes for all five length fields then you don't need padding and you would actually spare 17 - 5 = 12 bytes. To be honest, I don't think the difference is significant enough with respect to the total size of 664 bytes to make it a strong argument for using 2-byte length fields, but I do think that it makes implementing CGA-TSIG much more straightforward without having the hassle of adding paddings to each variably sized field. It would also be in line with the size of the length fields defined by TSIG, which are also 2 bytes. Hum... I guess you're right. Signing only the new public key is enough and in this case no timestamp is needed for the old signature (not new signature). I know the attacker only has a small period of time to do this attack and if it cannot do it, since the new public key is replaced with the old one on the DNS server, it cannot do this attack anymore or this attack is not effective as there is no old public key anymore valid. So I assume this scenario can be like this: The original node wants to change its IP address or public key. It signs all DNS message excluding the signature fields using its own new private key and sign the new public key using its own old private key. Then submit this packet including the TSIG RR with CGA-TSIG DATA The attacker eavesdrops and copy only the old public key and old signature from the packet and sign the DNS message using its own private key and submit this value... But the verification of the old signature fails since the attacker cannot copy the new public key of the original node. If it does this, the CGA verification will be failed and the node cannot prove the owner of this public key. So, By assuming such failure in the attack scenario. I guess only signing the new public key for old signature is enough. For this purpose no more authentication is needed since the time has been already checked for the new signature. Agreed. That only leaves the problem of how you notify your clients of your new IPv6 address. :) Thank you! Kind regards, Marc Buijsman ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] [dnsext] CGA-TSIG - new version
Dear Hosnieh, First of all, I'm glad I could be of help and to see that a number of my suggestions have been adopted! Regarding the size of the length fields, however, I'm still confused by what you are trying to say. I did not consider the number of bits, I really considered the number of bytes (octets). If I wanted to encode the length in bits (and I don't), I would have set the value to 2048. But I'm dividing by 8 and set the value to 256 instead, which is the length in *bytes* as you said yourself. The reason why you divide by 8 a second time is a mystery to me. The outcome would then be the number of groups of 8 bytes, but I've never seen a length encoding before that counts such 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32 octobytes, while I am counting 256 bytes (as usual). Also, I don't understand what you mean to say by multiple of 8. If the encoding would be in bits (and again, it's not) and the data is always a number of whole bytes, then yes the value would be a multiple of 8. But we are talking about an encoding in bytes here, which do not necessarily come in groups of 8 (and is therefore not necessarily a multiple of 8). I also don't know what checksum fields you mean or how their length is relevant here, but the IPv4 header checksum field and UDP checksum field in a regular DNS packet are two bytes each. With regard to the old signature: how would including more fields in the digest operation increase the packet size? No matter how many fields you digest, the resulting signature is always of the same length. And the fields I was referring to are already part of the packet. In order to be able to authenticate the new public key, you MUST at least include the new public key in the digest operation. Otherwise the packet could be intercepted and the new public key could be replaced without notice. Kind regards, Marc Buijsman Hosnieh Rafiee schreef op 15-2-2014 0:07: Thanks for the information you've provided, I improved the document according to comments and found out that the report also has a few problems which is due to the fact that it misinterpreted the of CGA-TSIG document. Here I explain the problems or the reasons of choices: - CGA-TSIG cannot use MAC as a signature field. The purpose was that to have all the CGA data in one section instead of trying to find them in different sections of TSIG. - sizes of length encoding: It is one byte. It is enough for any key sizes. If you also check the checksum field in the packets, you will find out that it is only 8 bits or one byte. In the emails I explained to you that it is the multiple of 8. In no RFC you can find out that the value is the length of data in bits. It is always the length of data in bytes. But how you showed in your report is that you consider the number of bits and not bytes so you had the following example 2048/8=256 (now you only converted the number of bits to bytes) so you needed to divide it by another 8 that is 256/8=32 and this is the value you set to length. If you even consider the key size 7680, then the length will be only 120. nd - old signature only contains time signed. The reason is to avoid increasing the packet length I appreciate further comments and would like more people review it so that we can go ahead with this document. Thanks, Hosnieh A new version of I-D, draft-rafiee-intarea-cga-tsig-07.txt has been successfully submitted by Hosnieh Rafiee and posted to the IETF repository. Name: draft-rafiee-intarea-cga-tsig Revision: 07 Title:Secure DNS Authentication using CGA/SSAS Algorithm in IPv6 Document date:2014-02-15 Group:Individual Submission Pages:26 URL: http://www.ietf.org/internet-drafts/draft-rafiee-intarea-cga-tsig-07.txt Status: https://datatracker.ietf.org/doc/draft-rafiee-intarea-cga-tsig/ Htmlized: http://tools.ietf.org/html/draft-rafiee-intarea-cga-tsig-07 Diff: http://www.ietf.org/rfcdiff?url2=draft-rafiee-intarea-cga-tsig-07 Abstract: This document describes a new mechanism that can be used to reduce the need for human intervention during DNS authentication and secure DNS authentication in various scenarios such as the DNS authentication of resolvers to stub resolvers, authentication during zone transfers, authentication of root DNS servers to recursive DNS servers, and authentication during the FQDN (RFC 4703) update. Especially in the last scenario, i.e., FQDN, if the node uses the Neighbor Discovery Protocol (NDP) (RFC 4861, RFC 4862), unlike the Dynamic Host Configuration Protocol (DHCP) (RFC 3315), the node has no way of updating his FQDN records on the DNS and has no means for a secure authentication with the DNS server. While this is a major problem in NDP-enabled networks, this is a minor problem in DHCPv6. This is because the DHCP server updates the FQDN records on behalf
Re: [DNSOP] [dnsext] CGA-TSIG - new version
Dear Hosnieh, Let me first react to your first email of today. CGA uses the RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I understand it as explained at http://tools.ietf.org/html/rfc3447#section-8.2.1 is that the length of the output signature S only depends on the length k of the RSA modulus n, and not on the length of the input message M. The algorithm accomplishes this by using a hash function on message M, SHA-1 in case of CGA. So provided that the RSA key has been determined, it does not matter how many fields you concatenate and take as input message M (although there is a maximum depending on the chosen hash function); the output will always be a signature of length k. The signature field is variable because the RSA key size is variable; not because the message is variable. I was not aware that SEND actually encodes groups of 8 bytes. I thought you meant that the value set in the length field should be a multiple of 8, but now I see you mean that the length of the data itself should be a multiple of 8. It is then logical that you might need padding to be able to make whole 'octobytes'. However, I don't believe that this padding is needed for the signature operation since the hash function takes a variable amount of input bytes anyway. You also didn't mention anything about padding in your draft (nor does the CGA RFC), so I assumed the encoded length to be in bytes just like the other length-encoding fields in the TSIG RR. I'm also not sure if you save more space by using 1 byte for the length-encoding field and additional padding, instead of 2 bytes for the length-encoding field without padding. Regarding the old signature, I think you could even leave out the timestamp from the old signature operation. As long as you sign the new public key with the old public key (with the old signature as ouput) in order to authenticate the new public key, it is also possible to authenticate the timestamp and fudge field provided that they have been signed with the new public key (as required by TSIG, which recommends a fudge value of 300 seconds i.e. 5 minutes, a bit more than a few seconds). Kind regards, Marc Buijsman Hosnieh Rafiee schreef op 16-2-2014 13:10: Follow up, I thought again about the possible attacks scenarios. I concluded that I also need to include the new public key in the content of the old signature. This means the old signature should be new public key + timestamp, otherwise the attacker might have a possibility (a few seconds) to do the replay attack by copying the old public key and oldsignature. So, you're right, it still might cause the attacker to attack. But to avoid increasing packet size, it is only enough for the two values that is new public key and timestamp. Since the new public key is verified by both CGA verification process and also the new signature and the old public key is verified by old signature. I will correct this in the next version of the document. Thanks, Best, Hosnieh -Original Message- From: dnsext [mailto:dnsext-boun...@ietf.org] On Behalf Of Hosnieh Rafiee Sent: Sunday, February 16, 2014 12:41 PM To: 'Marc Buijsman' Cc: 'Jeroen van der Ham'; DNSOP@ietf.org; dns...@ietf.org Subject: Re: [dnsext] CGA-TSIG - new version Dear Marc, Thanks for your comments. Regarding the size of the length fields, however, I'm still confused by what you are trying to say. I did not consider the number of bits, I really considered the number of bytes (octets). If I wanted to encode the length in bits (and I don't), I would have set the value to 2048. But I'm dividing by 8 and set the value to 256 instead, which is the length in *bytes* as you said yourself. The reason why you divide by 8 a second time is a mystery to me. The outcome would then be the number of groups of 8 bytes, but I've never seen a length encoding before that counts such 'octobytes' (which is not a byte, but 8 bytes). So you are counting 32 octobytes, while I am counting 256 bytes (as usual). Also, I don't understand what you mean to say by multiple of 8. If the encoding would be in bits (and again, it's not) and the data is always a number of whole bytes, then yes the value would be a multiple of 8. But we are talking about an encoding in bytes here, which do not necessarily come in groups of 8 (and is therefore not necessarily a multiple of 8). I also don't know what checksum fields you mean or how their length is relevant here, but the IPv4 header checksum field and UDP checksum field in a regular DNS packet are two bytes each. http://tools.ietf.org/html/rfc3971#section-5.1 maybe my wording is not correct. Check the length field here. 8 bits is really not enough for that. So, If you check the implementation of SeNDs (Docomo, etc). what they do is they shift the values or easier way is to divide by 8. With regard to the old signature: how would including more fields in the digest operation increase the
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
The largest problem for IETF and DNS innovation is that the consensus in IETF seems to be that innovation of DNS is not possible unless it involves reuse of the TXT resource record. Yes, sort of. The consensus in one part of the IETF is that adding new RR types is too hard due to DNS server upgrades and particularly to the web crudware that most people use to provision their DNS. The consensus in another part of the IETF is that adding new RR types is trivial, and anyone who thinks otherwise is stupid. (I oversimplify but not by much.) I've had a draft kicking around for a while, with recent additions from Vixie, of an RR config language to allow the DNS to be largely self-describing, with most new RR types having names and formats published in a well known place so the servers and crudware can handle new RRs without software upgrades (after a one-off upgrade to handle the config language itself) or config changes. The responses to the draft have been most educational. R's, John ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] meta issue: WG to discuss DNS innovation (was Re: draft-hzhwm-start-tls-for-dns-00)
On 17/02/2014, at 5:48 am, Joe Abley jab...@hopcount.ca wrote: On 2014-02-16, at 11:39, Patrik Fältström p...@frobbit.se wrote: - We can not use new RR Types, lets use A and TXT - DNSSEC will never take off - Lets just use HTTP for transport I think we are suffering from a knee-jerk instinct to say no to ideas that we assume will never work in the real world. We can't add more transports (e.g. SCTP), because even if implemented there's just too much middleware in the world that will interact badly. We can't add more resource records, because there are nameserver implementations that don't deal with opaque types properly, and won't allow the new resource records to be published. We can't do anything that will cause larger responses, because EDNS support is not widespread, and in any case the network can't reliably deliver fragments. If we believe all these problems are intractable, then we might as well just accept that overloading TXT records and reflection attacks are a fact of life, and stop worrying about them. What I would prefer, though, is a more entrepreneurial approach where the likelihood of short-term operational problems (or even long-term failure of the work) should not stop us from trying. Rich people are the ones that realise that you only need one out of ten business ventures to succeed to get a pay out. So, how about a starting point where we assume that if a particular extension has value to anybody, the operators (the market) will adjust to allow it to work, and if it doesn't, then adjustments are not necessary? Very well put indeed. The default position currently seems to be that consensus is so hard to achieve because it demands so much that very little can pass. A particular symptom of that is the increasing calls for a requirements draft or problem statement (which is obviously wider than DNSOP). We'd do well from turning that on its head and making the default position that everything passes unless consensus is that it shouldn't, which would generally be because it is truly awful, duplicative, nobody understands it, etc. As Henry Ford probably didn't say If I had asked people what they wanted, they would have said faster horses.”. Or better still a genuine quote from Steve Crocker in the final ICANN board vote on new TLDs: The case for new TLDs is a little harder to pin down. But one of the most important principles in the creation of the Internet from a very long time ago was not to stifle or prejudge what the paths for innovation are. So the default has to be that, absent a strong case that such things will cause harm, we must move forward. And I strongly support this. Jay Anybody else feel like working on the specification for SCTP transport? :-) Joe ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop -- Jay Daley Chief Executive .nz Registry Services (New Zealand Domain Name Registry Limited) desk: +64 4 931 6977 mobile: +64 21 678840 linkedin: www.linkedin.com/in/jaydaley ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
