Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt
In your previous mail you wrote: > Two points that I request this WG to discuss are: > > 1. Sparsely TSIG signed TCP continuation messages (section 6.4 in draft) => I'd like to do this but it is not possible to change requirements for existing implementations so easily. I added a SHOULD for signing all messages so on the long term they should disapear.,, > 2. Truncated MACs => first they are optional so not required to be implemented/supported. Second I'd like to get the opinion from a cryptographer because I heard that truncated HMACs have some security benefits. Last of course they make messages shorter so have a clear operational advantage. Now I do not know if they are heavily used. If they are not we can consider to add a NOT RECOMMENDED for their implementation/support even it is not really in the scope of the document. Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt
On Mon, Nov 19, 2018 at 07:15:34PM +0530, Mukund Sivaraman wrote: > Hi Stephen, Francis > > On Mon, Nov 19, 2018 at 04:56:50AM -0800, internet-dra...@ietf.org wrote: > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the Domain Name System Operations WG of the > > IETF. > > > > Title : Secret Key Transaction Authentication for DNS > > (TSIG) > > Authors : Francis Dupont > > Stephen Morris > > Paul Vixie > > Donald E. Eastlake 3rd > > Olafur Gudmundsson > > Brian Wellington > > Filename: draft-ietf-dnsop-rfc2845bis-02.txt > > Pages : 26 > > Date: 2018-11-19 When investigating a TKEY related implementation bug, I notice that the text in RFC 3645 is not very clearly written about prohibiting TSIG signed responses for some error conditions (e.g., section 4.1.3 where the writing seems to assume paragraph contexts). I recommend that you check the various cases in RFC 3645 to make sure the protocol doesn't allow inclusion of arbitrary or invalid request MAC in response TSIG MAC computation, and state this so in the bis draft. In any case, the text in the draft has to be updated for the relaxation in RFC 3645 section 2.2. It wouldn't be so bad if the two RFCs can be merged as part of this bis work. Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt
Hi Mark On Wed, Nov 21, 2018 at 09:29:03AM +1100, Mark Andrews wrote: > > On 20 Nov 2018, at 12:45 am, Mukund Sivaraman wrote: > > Two points that I request this WG to discuss are: > > > > 1. Sparsely TSIG signed TCP continuation messages (section 6.4 in draft) > > I would accept not generating sparsely TSIG signed TCP continuation messages > (except for test code) immediately. It will take many years before one could > remove the validation side as you need to ensure that all you current peers > don’t generate that style of stream. Time of publication +10 years if you > want to remove the validation side. By that time there should be very few > legacy peers. > > Add a bit about logging when STSTCM is seen on a connection so it becomes > noisy. Include the cut off date. This logging will unfortunately be on > the wrong end of the connection but will give some indication of the expected > breakage. Start logging at publication date +8 years so the noise is around > the breakage time and not immediately. This plan sounds good to me. We'll need a plan like this as NSD is the one among the popular open source nameservers that generates such continuations by default. I don't think there's even an option to turn it off - I may be wrong. BIND and Knot sign every message - IIRC Knot's behavior is based on BIND's though their code is different. > > 2. Truncated MACs > > > > I feel both should be obsoleted now to reduce implementation complexity > > and scope for errors causing authentication bypass. I have talked about > > these on this list before, but won't restate comments in support here to > > prejudice discussion. > > This is more complicated. Removing code support will break existing > configurations that are using truncated hashes. This would require > deciding a cut off date (publication +10 years), logging when used > including the cut off date. This is basically human to human rather > than machine to machine. Code gets updated. Humans don’t. We'd have to do something similar here too - only generate full MACs and support verifying with truncated MACs (if configured so per local policy) for a period. I faintly seem to remember that perhaps Knot doesn't even support truncated MACs (I went through that code last when we were notified of the TSIG bypass vulnerability). Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Review of draft-ietf-dnsop-rfc2845bis-02.txt
> On 20 Nov 2018, at 12:45 am, Mukund Sivaraman wrote: > > Hi Stephen, Francis > > On Mon, Nov 19, 2018 at 04:56:50AM -0800, internet-dra...@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Domain Name System Operations WG of the >> IETF. >> >>Title : Secret Key Transaction Authentication for DNS (TSIG) >>Authors : Francis Dupont >> Stephen Morris >> Paul Vixie >> Donald E. Eastlake 3rd >> Olafur Gudmundsson >> Brian Wellington >> Filename: draft-ietf-dnsop-rfc2845bis-02.txt >> Pages : 26 >> Date: 2018-11-19 > > First, I want to point out that this is a bis document and not errata, > so it need not (and should not) be limited to just fixing the TSIG > authenication bypass attack. I strongly feel that RFC 2845 is unclearly > specified, and TSIG (the protocol) is over-specified. This bis revision > should make amends. > > Two points that I request this WG to discuss are: > > 1. Sparsely TSIG signed TCP continuation messages (section 6.4 in draft) I would accept not generating sparsely TSIG signed TCP continuation messages (except for test code) immediately. It will take many years before one could remove the validation side as you need to ensure that all you current peers don’t generate that style of stream. Time of publication +10 years if you want to remove the validation side. By that time there should be very few legacy peers. Add a bit about logging when STSTCM is seen on a connection so it becomes noisy. Include the cut off date. This logging will unfortunately be on the wrong end of the connection but will give some indication of the expected breakage. Start logging at publication date +8 years so the noise is around the breakage time and not immediately. > 2. Truncated MACs > > I feel both should be obsoleted now to reduce implementation complexity > and scope for errors causing authentication bypass. I have talked about > these on this list before, but won't restate comments in support here to > prejudice discussion. This is more complicated. Removing code support will break existing configurations that are using truncated hashes. This would require deciding a cut off date (publication +10 years), logging when used including the cut off date. This is basically human to human rather than machine to machine. Code gets updated. Humans don’t. > I previously reviewed this bis draft here: > https://www.ietf.org/mail-archive/web/dnsop/current/msg21227.html > > Many of my review comments were responded to with the terse "17y" > comment by one of the authors. > > However, ome of the comments from my previous review have been > incorporated into the current document, but some have not. I > specifically request Stephen to read the comments in my previous review > carefully comparing against the current text in context, because I feel > some of those changes still have to be made. > > Soon after this TSIG authentication bypass attack was reported, during a > review of the BIND TSIG implementation by Ray Bellis and me, we found a > couple of other issues. One of them is not a real-world issue (to do > with under-specification of what to do with full MAC length having > non-integral number of octets - there are no such common HMACs > currently), and another that I'm not able to remember that had to do > with an off-by-1 (or something similar) on the fudge and time signed > fields. Do you have any recollection of it Ray? > > Mukund > > ___ > 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] Review of draft-ietf-dnsop-rfc2845bis-02.txt
On 19/11/2018 13:45, Mukund Sivaraman wrote: Soon after this TSIG authentication bypass attack was reported, during a review of the BIND TSIG implementation by Ray Bellis and me, we found a couple of other issues. One of them is not a real-world issue (to do with under-specification of what to do with full MAC length having non-integral number of octets - there are no such common HMACs currently), and another that I'm not able to remember that had to do with an off-by-1 (or something similar) on the fudge and time signed fields. Do you have any recollection of it Ray? I vaguely recall the discussion but not the detail of it. ISTR it was something to do with using a <= comparison rather than <, or vice versa. Ray ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
