Re: [DNSOP] I-D Action: draft-ietf-dnsop-dns-zone-digest-02.txt
> On Nov 7, 2019, at 7:56 PM, Vladimír Čunát wrote: > > Hello! > > On 10/28/19 10:32 PM, Wessels, Duane wrote: >> The one defined hash algorithm SHA384 has been renamed to SHA384-STABLE to >> reflect that it designed for use on stable (or small) zones where it is not >> burdensome to recalculate the digest over the entire zone data each time. > > Tiny nitpick: calling it "SHA384-STABLE" might be a tiny bit confusing > (to me), as I've seen that word refer to some particular hashing > approaches/properties. Actually some of the algorithms that efficiently > recompute after small changes in large zones... I'd even tend to call > those digests (more) "stable"/"steady" intuitively, but that might be > personal :-) I certainly don't have a strong opinion on the naming and > don't want to bike-shed, but I could imagine calling it "simple" or > "flat" or something along those lines. > > [example] https://en.wikipedia.org/wiki/Stable_hashing > > --Vladimir Hi Vladimir, Thanks for the feedback! I guess we settled on stable as being sort of opposite to dynamic, but I agree it's not all that great. I would be okay with "simple" or "flat" as well. DW smime.p7s Description: S/MIME cryptographic signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Specification of DNSKEY "Private-key-format"
Hi Victor On Thu, Aug 29, 2019 at 07:25:54PM +0530, Mukund Sivaraman wrote: > Hi Viktor > > On Thu, Aug 29, 2019 at 09:48:31AM -0400, Viktor Dukhovni wrote: > > On Thu, Aug 29, 2019 at 06:25:02PM +0530, Mukund Sivaraman wrote: > > > A tool such as BIND's dnssec-keygen generates the following formatted > > > private keys: > > > > > > [muks@naina ~]$ cat Kexample.org.+008+10638.private > > > Private-key-format: v1.3 > > > Algorithm: 8 (RSASHA256) > > > Modulus: [...] > > > PublicExponent: [...] > > > PrivateExponent: [...] > > > Prime1: [...] > > > Prime2: [...] > > > Exponent1: [...] > > > Exponent2: [...] > > > Coefficient: [...] > > > > Compare the above with: > > > > $ openssl genrsa 512 2>/dev/null | openssl rsa -text -noout | egrep -v > > ':..:' > > RSA Private-Key: (512 bit, 2 primes) > > modulus: > > publicExponent: 65537 (0x10001) > > privateExponent: > > prime1: > > prime2: > > exponent1: > > exponent2: > > coefficient: > > > > And it becomes clear that what you're seeing is a sequence of tagged > > base64 encodings of the BIGNUM elements of the CRT form of an RSA > > private key. > > I am initimately familiar with what these fields mean and the code that > generates it. The question is not about what the meaning of these fields > are. > > I am asking about where this key format is specified - I want to extend > it. I apologize for the way I replied to your email. My response was arrogantly written. You only tried to help me. (I realized it soon after sending the email and it has bugged me since.) Mukund ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Second Working Group Last Call for draft-ietf-dnsop-extended-error
On 11/14/19 12:05 AM, Viktor Dukhovni wrote: > It'd be a shame (though admittedly not frequent) to have a resolver > retry over TCP just to get the same answer with additional information > it does not need and perhaps does not even understand. EDE codes themselves take very little space, so truncating just the textual messages might be a good middle-ground but I certainly haven't tried thinking of all implications on EDE truncation yet. Communicating these through bit(s) in EDE or EDNS flags might be nice, and clients might even use them to set their preference. Still, ATM I can't clearly see whether such TC details would be useful in practice. I think we're fortunate that most use cases for EDE are failures... so the answer will probably be tiny. --Vladimir ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-server-cookies-02.txt
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 : Interoperable Domain Name System (DNS) Server Cookies Authors : Ondrej Sury Willem Toorop Donald E. Eastlake 3rd Mark Andrews Filename: draft-ietf-dnsop-server-cookies-02.txt Pages : 16 Date: 2019-11-18 Abstract: DNS cookies, as specified in RFC 7873, are a lightweight DNS transaction security mechanism that provides limited protection to DNS servers and clients against a variety of denial-of-service and amplification, forgery, or cache poisoning attacks by off-path attackers. This document provides precise directions for creating Server Cookies so that an anycast server set including diverse implementations will interoperate with standard clients. This document updates [RFC7873] The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-server-cookies/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-server-cookies-02 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-server-cookies-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-server-cookies-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
> On Nov 17, 2019, at 8:35 PM, Mark Andrews wrote: > > Just because broken configuration don’t always cause problems doesn’t mean > that they don’t sometimes. MTA’s need to know what names they are known > by to properly remove MX records from consideration when performing store and > forward. Email forwarding loops still occur. Postfix ignores the names, and does loop elimination by IP address. It also detects loops when it sees its own name in the 220 banner or EHLO reply. Relying on just canonical names for loop elimination is not enough. The same IP address can can have multiple names even without CNAMEs. Other MTAs may look at the names and not the addresses, but I would hope that they also employ additional loop detection mechanisms, and there's ultimately the hop (Received header) count. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
a correct implemention of smtp could pick up the a and from additional data without making any additional queries. it could also ignore cname records in the a/ response and declare that the a/ owner was wrong. we can't break working behaviour no matter what the statistics show. a draft that said clients can expect this would also have to say servers should not expect clients to expect this. vixie Get BlueMail for Android On 18 Nov 2019, 12:38, at 12:38, Viktor Dukhovni wrote: >> On Nov 17, 2019, at 8:35 PM, Mark Andrews wrote: >> >> Just because broken configuration don’t always cause problems doesn’t >mean >> that they don’t sometimes. MTA’s need to know what names they are >known >> by to properly remove MX records from consideration when performing >store and >> forward. Email forwarding loops still occur. > >Postfix ignores the names, and does loop elimination by IP >address. It also detects loops when it sees its own name in >the 220 banner or EHLO reply. Relying on just canonical names >for loop elimination is not enough. The same IP address can >can have multiple names even without CNAMEs. > >Other MTAs may look at the names and not the addresses, but >I would hope that they also employ additional loop detection >mechanisms, and there's ultimately the hop (Received header) >count. > >-- > Viktor. > >___ >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] RFC 8482 (the ANY -> HINFO hack) and DNAME
> On Nov 18, 2019, at 1:00 PM, Paul Vixie wrote: > > A correct implementation of SMTP could pick up the A and from > additional data without making any additional queries. Some resolvers return "minimal" answers and don't include additional records. MTA's can't rely on getting addresses in additional records, even if the name is canonical. If the authoritative server send the additionals along, then the (local by BCP) resolver the MTA is using will already have the data cached, and the followup query is fast. > It could also ignore CNAME records in the A/ response and declare > that the A/ owner was wrong. Yes, an implementation that does not support CNAMEs could do that. My point was that in practice MTAs do support CNAMEs, and they are deployed for real domains, and work well enough for the operators to continue to use them. > We can't break working behaviour no matter what the statistics show. The MX -> CNAME domains already exist, and receive email. The mainstream MTAs don't object, and so at this point the thing that's somewhat of sync with practical reality is the RFC. We can try to insist that the RFC is right and world is wrong, but I've moved on. > A draft that said clients can expect this would also have to say > servers should not expect clients to expect this. There could be such a draft, but for now at least the major MTAs just accept CNAMEs informally and get the mail delivered. Yes, it helps to not get too creative. Just today I helped an operator squash an ESMTP STARTTLS advertisement failure, which broke inbound email delivery from one large DANE-enabled sender. The problem was a odd-looking (but mostly benign) EHLO response anomaly: 250-"HELO OK." 250-... 250-STARTTLS ... instead of: 250-fqdn.example 250-... 250-STARTTLS ... This was find for most senders, but not all. One particular large sender's ESMTP parser seems to choke on the double-quoted "HELO OK.", and never sees the STARTTLS, and with DANE TLSA published, declines to send in the clear. At the end of the day, operating outside the RFC carries some risk, and one should not be cavalier in deploying creative deviations from the spec. However, post-MX CNAME indirection is seen to useful by some to stick to the spec, and since MTAs tolerate this, it is used in the wild. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Specification of DNSKEY "Private-key-format"
> On Nov 18, 2019, at 5:31 AM, Mukund Sivaraman wrote: > >> I am initimately familiar with what these fields mean and the code that >> generates it. The question is not about what the meaning of these fields >> are. >> >> I am asking about where this key format is specified - I want to extend >> it. > > I apologize for the way I replied to your email. My response was > arrogantly written. You only tried to help me. > > (I realized it soon after sending the email and it has bugged me since.) No worries, I did not see anything wrong with your response and not take offense, but thanks for reaching out just in case. -- Viktor. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] RFC 8482 (the ANY -> HINFO hack) and DNAME
Viktor Dukhovni wrote on 2019-11-18 12:56:> ... At the end of the day, operating outside the RFC carries some risk, and one should not be cavalier in deploying creative deviations from the spec. However, post-MX CNAME indirection is seen to useful by some to stick to the spec, and since MTAs tolerate this, it is used in the wild. a lot of things happen in the wild. that's why we call it "the wild". every protocol recommendation should be thought of as rebuilding the airplane during flight -- to be done with utmost caution. "just do whatever mostly works" is in no way cautious. -- P Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Warren Kumari's Recuse on draft-ietf-dnsop-serve-stale-09: (with COMMENT)
Warren Kumari has entered the following ballot position for draft-ietf-dnsop-serve-stale-09: Recuse When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-dnsop-serve-stale/ -- COMMENT: -- Recusing because I'm an author. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
