Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On Thu, Sep 27, 2007 at 06:45:55PM -0700, Paul Hoffman <[EMAIL PROTECTED]> wrote a message of 36 lines which said: > It ignores one of the main reasons that many organizations purposely > choose to provide recursive lookup to the public, namely for their > own roaming users. No, it is *not* ignored. See section 4, for instance : o Use TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to authenticate the clients. This is a less error prone method, which allows server operators to provide service to clients who change IP address frequently (e.g. roaming clients). VPN are another solution, although not mentioned in the I-D, may be because it is obvious. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
At 18:45 27-09-2007, Paul Hoffman wrote: The Security Considerations section for this document is much too narrow. It ignores one of the main reasons that many organizations purposely choose to provide recursive lookup to the public, namely for their own roaming users. Without an open, known-good nameserver at a fixed address, roaming users need to trust whatever is given to them by their ISP at The same question of trust is applicable to general users as well as you pointed out in your comment about ISPs. The Security Considerations section needs to deal with these issues, even if they do not change the advice given in section 4. Although this document does not create any new security issues for the DNS protocol, it may be an issue for users of the service. A note covering the points you raised could be added under security considerations. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: getaddrinfo() and searching
--On Friday, 28 September, 2007 09:48 +1000 Mark Andrews
<[EMAIL PROTECTED]> wrote:
>...
>> It's not. Even without IPv6, having search domains means you
>> can get unexpected results. If that's not acceptable, don't
>> complain, but put a period behind your FQDNs.
>
> Please state were in RFC 952 a final period is legal in
> a hostname.
>
> Remember applications take HOSTNAMES not DOMAIN NAMES.
> There are HOSTNAMES that you cannot store in the DNS.
> There are DOMAIN NAMES that are not legal HOSTNAMES.
Mark, your recollection and understanding of history and
vocabulary may be different from mine (and probably is), but I
think you are getting confused by some informal terminology and
risking confusing others even further.
RFC 952 in fact prohibits trailing periods in domain names used
as host names, but 952 is a very early document, superceded by
all sorts of things both formally and informally. I note, for
example, that it has been a rather long time since every
boundary router on the network (a "gateway") had a name ending
in "-GW" or "-GATEWAY". Please don't read sentences of 952 out
of context and consider them binding.
You will not find the "hostname" versus "domain" distinction
made in RFC 1034. 1034 and its conceptual predecessors
discusses the domain name system as a replacement for the
hostname one and even notes (correctly) that different
applications have different syntax rules for names for hosts.
To make the ambiguity worse, when the term "host" or "hostname"
is used in applications in conjunction with the DNS, that term
often refers to the leaf-note label and not to the FQDN. See,
for example, section 3.7 of RFC 821, which describes
"Fred.Cambridge.UK" as a possible "host-and-domain identifier".
However, the familiar "mailbox" is defined as
::= "@"
Note that it is not
"@"
or
"@"
RFC 1034 also seems to believe that all fully-qualified (aka
"absolute") domains names, including those used to refer to
hosts, end in a period, even if that period is typographically
omitted for convenience. Of course, it also contains a
masterwork of apparently-circular definition: "A domain is
identified by a domain name, and consists of that part of the
domain name space that is at or below the domain name which
specifies the domain."
While 1034 suggests that the trailing period is always
permitted, even if it is implied, Section 2.3.1 of 1035 gives a
syntax that doesn't permit them. But it does so without trying
to distinguish between a "host" and a "domain". In particular,
it says that [all of] "The labels must follow the rules for
ARPANET host names", which is ultimately a reference to 952
although 1035 repeats the rule. That rule is applied to all
labels, not just the leaf one or ones identifying hosts.
As an indirect illustration of this, note that 1035 Section 3.5
describes IN-ADDR.ARPA as supporting "host address to host name
mapping". That mapping is to an FQDN, not a label or "hostname"
as you use the term above.
RFC 1123 makes explicit provision for trailing dots in
application interfaces to domain names ("hosts") while noting
that RFC 822 (and 821) do not permit that syntax in the
protocols. Nothing has ever permitted a UI designer, even for a
mail-related program, from accepting the trailing dot as long as
it is removed (and any searching or aliases resolved) before the
name goes out on the wire.
So I believe the distinction you are trying to make is not
historically supported, not particularly helpful, ambiguous, and
probably just plain wrong.
regards,
john
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
At 9:19 AM +0200 9/28/07, Stephane Bortzmeyer wrote: On Thu, Sep 27, 2007 at 06:45:55PM -0700, Paul Hoffman <[EMAIL PROTECTED]> wrote a message of 36 lines which said: > It ignores one of the main reasons that many organizations purposely choose to provide recursive lookup to the public, namely for their own roaming users. No, it is *not* ignored. See section 4, for instance : o Use TSIG [RFC2845] or SIG(0) [RFC2931] signed queries to authenticate the clients. This is a less error prone method, which allows server operators to provide service to clients who change IP address frequently (e.g. roaming clients). This is a suggestion for something that essentially no one can use today (as is admitted after the text after the quote). VPN are another solution, although not mentioned in the I-D, may be because it is obvious. It is not "obvious", at least to some of the people I have spoken with. It is also not obvious to VPN vendors; otherwise, they would have easy-to-use settings to make it happen. None of the VPN client that I have seen have such settings. Listing such things in the Security Considerations section of a document is a good practice, regardless of what you think is obvious. At 12:15 PM +0200 9/28/07, Jaap Akkerhuis wrote: There are two major reasons for an organization to not want roaming users to trust locally-assigned DNS servers. Open recursive servers doesn't help in against man in the middle attacks. Correct; no one said that they did. Open recursive name servers help against against roaming users being directed to DNS servers whose security policy is different than their organizations'. If you want to avoid that use VPN's or (for DNS) TSIG. Indeed. I seem to remember that the ID actually mentions that. I cannot find any mentions of VPNs or IPsec. Given that the document admits that TSIG and SIG(0) are essentially unavailable today on end users systems, and IPsec is much more common, saying something about this in the Security Considerations section might be of value. As my earlier message said, this is not for Section 4, which is only talking about authentication of clients. At 1:20 PM +0200 9/28/07, Joao Damas wrote: Opening up your resolver so you can server roaming users, without further protection, is, at best, naive. From the standpoint of the organization whose security policy includes the way their users do DNS resolution, it is better than nothing, and this document's "best practices" pretty much limit them to nothing. For a non-ISP, ingress filtering will not help at all (even though it should still be implemented, and customers should urge their ISPs to implement it). IP-based authentication does not work for mobile users. Interface-based authentication does not work for mobile users. TSIG and SIG(0) does not work for mobile users until it is implemented in their computers, which the draft admits it is not for the vast majority of users. If the document doesn't want to deal with those organizations, it needs to say so in the introduction and again in the Security Considerations section. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
It does indeed as Stephane pointed out. Opening up your resolver so you can server roaming users, without further protection, is, at best, naive. Joao On 28 Sep 2007, at 12:15, Jaap Akkerhuis wrote: There are two major reasons for an organization to not want roaming users to trust locally-assigned DNS servers. Open recursive servers doesn't help in against man in the middle attacks. If you want to avoid that use VPN's or (for DNS) TSIG. I seem to remember that the ID actually mentions that. jaap ___ DNSOP mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/dnsop ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On 28-Sep-2007, at 1136, Paul Hoffman wrote: It is not "obvious", at least to some of the people I have spoken with. It is also not obvious to VPN vendors; otherwise, they would have easy-to-use settings to make it happen. I'm surprised by that comment. I think it's a common use case that organisations who deploy VPNs have split DNS; that is, namespaces available through internal network resolvers that do not appear in the global namespace. In my experience, it is normal for: - VPN client software to use IP addresses rather than names to establish a secure tunnel with the home network - Local resolver settings on the VPN client's machine to be re- written to use internal home network nameservers while the VPN session is active This is certainly how the cisco VPN client supplied to me by my employer (and the subsequent versions I've downloaded directly from cisco) work, for example. I was under the impression that cisco had fairly significant market share in this area. This is not to say that the topic doesn't deserve mention in the draft at hand. However, your logic in the last sentence above seems suspect to me. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
At 12:04 PM -0400 9/28/07, Joe Abley wrote: On 28-Sep-2007, at 1136, Paul Hoffman wrote: It is not "obvious", at least to some of the people I have spoken with. It is also not obvious to VPN vendors; otherwise, they would have easy-to-use settings to make it happen. I'm surprised by that comment. I think it's a common use case that organisations who deploy VPNs have split DNS; that is, namespaces available through internal network resolvers that do not appear in the global namespace. In my experience, it is normal for: - VPN client software to use IP addresses rather than names to establish a secure tunnel with the home network - Local resolver settings on the VPN client's machine to be re-written to use internal home network nameservers while the VPN session is active That's completely true for remote users who are already using a VPN. In that case, there is no reason for the organization to have a recursive resolver facing outwards. What was being discussed was setting up a VPN just for getting DNS resolution, not for access to other internal resources. IPsec can be used to create a tunnel to just a single resource if the organization wants the external user to access that resource only. --Paul Hoffman, Director --VPN Consortium ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
There are two major reasons for an organization to not want roaming users to trust locally-assigned DNS servers. Open recursive servers doesn't help in against man in the middle attacks. If you want to avoid that use VPN's or (for DNS) TSIG. I seem to remember that the ID actually mentions that. jaap ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On 28-Sep-2007, at 1136, Paul Hoffman wrote: > It is not "obvious", at least to some of the people I have spoken > with. It is also not obvious to VPN vendors; otherwise, they would > have easy-to-use settings to make it happen. I'm surprised by that comment. I'm not. As it happens I've used three different VPN services in the past few years and I will soon be forced to switch to a fourth. In each case the IT folks managed to jury-rig things so that DNS queries got redirected, but I've been told in some cases it required quite a bit of effort. And it is also my understanding that requiring this significantly limited our our options in choosing VPN solutions. I think it's a common use case that organisations who deploy VPNs have split DNS; that is, namespaces available through internal network resolvers that do not appear in the global namespace. Yes, we have this in spades at Sun. Can't say it works all that well, but this is really a separate issue. In my experience, it is normal for: - VPN client software to use IP addresses rather than names to establish a secure tunnel with the home network I'm sure this is done, but I think it is more common to use DNS entries. You have to validate the server's certificate or whatever anyway, so all direct use of IP address does is limit certain denial of service attacks but at the cost of a significant loss in flexibility. - Local resolver settings on the VPN client's machine to be re- written to use internal home network nameservers while the VPN session is active Yeah, that's what the client ends up doing. I don't know the specifics of how this has been implemented in the various clients I've had to use, but it has tended to be quite fragile - on numerous occasions things have failed in such a way that my DNS settings were completely trashed and I had to go in and reset them manually. I eventually wrote a little script I can run to force things back to where they're supposed to be with a single command. Perhaps if this the need for this were called out more specifically more attention would be paid to making this work well. This is certainly how the cisco VPN client supplied to me by my employer (and the subsequent versions I've downloaded directly from cisco) work, for example. I was under the impression that cisco had fairly significant market share in this area. Since I don't really know who or what's responsible for the many problems I've seen with this I'm not going to provide specifics regarding the clients I've used. However, I will say that I think you've had a fair bit of luck here. This is not to say that the topic doesn't deserve mention in the draft at hand. However, your logic in the last sentence above seems suspect to me. FWIW, I am in full support of Paul and John's position here. Ned ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [TLS] Re: Third Last Call: draft-housley-tls-authz-extns
At Fri, 28 Sep 2007 16:39:05 -0400 (EDT), Dean Anderson wrote: > On Fri, 21 Sep 2007, Tim Polk wrote: > > The TLS working group declined to take this work on. That is > > different from not supporting publication. > > The above isn't a true statement. The name of the draft > "draft-housley-tls-authz-extns" contains the name of the working group, > a fact that indicates it is a working group document. After the fraud > by Housley was discovered, and the approval was removed, the TLS Working > Group was asked, but no longer supported the protocol because of the > patent. See Rescorla's message, quoted above. Dean, Your statement above is inaccurate. The -tls- in the document name does not mean that the document is a WG document. It's quite common to have draft-- documents, which generally indicates that the named individual believes the document is targets at that WG. As an example, consider the following documents: draft-bryan-p2psip-reload-01.txt draft-jennings-p2psip-asp-00.txt draft-matthews-p2psip-hip-hop-00.txt These are all alternative documents targeted at the P2PSIP WG (there are about 5 more, too) but none have been accepted by the WG. This document has never been a work item of the TLS WG. -Ekr ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: Last Call: draft-ietf-dnsop-reflectors-are-evil (Preventing Use of Recursive Nameservers in Reflector Attacks) to BCP
On 28-Sep-2007, at 1516, Dean Anderson wrote: Not widely supported in clients. Therefore, not a solution. In fact, it's quite feasible in operating systems which can run a local instance of (say) BIND9. It would be fair to say that installing and configuring BIND9 on an average laptop is far beyond the abilities of the average laptop owner, but that's presumably just a matter of packaging. VPN are another solution, although not mentioned in the I-D, may be because it is obvious. Maybe its not mentioned because its not a practical solution. But whatever the reason it isn't mentioned, a 25 million user VPN is not going to happen with 10/8. Well, that depends on what you mean by "VPN". If you mean "a hub and spoke topology of tunnels, all concentrated centrally" then yeah, that sounds like a bit of a stretch. If you mean "use of AH in queries sent towards a resolver which is configured somehow to discard packets that are not authentic" then I suspect there are ways to make that scale, even for quite large client populations. (I might choose to incorporate anycast into such a design. You, presumably, would not. :-) A comcast person recently complained on PPML that there wasn't enough RFC1918 space for their internal network. I have heard such reports from Comcast in various forums. I have no reason to doubt them. I do not think that is especially pertinent to the question at hand, however. Joe ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [TLS] Re: Third Last Call: draft-housley-tls-authz-extns
On 2007-09-29 08:58, Eric Rescorla wrote: ... After the fraud by Housley was discovered, I don't know who wrote this libel that Eric replied to (apparently it was someone whose email gets magically deleted before it reaches me), but I would like to remind people that the late IPR disclosure in this case had nothing whatever to do with Russ Housley. Sorry about the excessive cross-posting, but it does seem necessary to correct libels. Being falsely accused of fraud seems to be an occupational hazard for IETF Chairs, but that doesn't mean it should go unrefuted. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [DNSOP] Re: getaddrinfo() and searching
> > > --On Friday, 28 September, 2007 09:48 +1000 Mark Andrews > <[EMAIL PROTECTED]> wrote: > > >... > >> It's not. Even without IPv6, having search domains means you > >> can get unexpected results. If that's not acceptable, don't > >> complain, but put a period behind your FQDNs. > > > > Please state were in RFC 952 a final period is legal in > > a hostname. > > > > Remember applications take HOSTNAMES not DOMAIN NAMES. > > There are HOSTNAMES that you cannot store in the DNS. > > There are DOMAIN NAMES that are not legal HOSTNAMES. > > Mark, your recollection and understanding of history and > vocabulary may be different from mine (and probably is), but I > think you are getting confused by some informal terminology and > risking confusing others even further. > > RFC 952 in fact prohibits trailing periods in domain names used > as host names, but 952 is a very early document, superceded by > all sorts of things both formally and informally. I note, for > example, that it has been a rather long time since every > boundary router on the network (a "gateway") had a name ending > in "-GW" or "-GATEWAY". Please don't read sentences of 952 out > of context and consider them binding. > > You will not find the "hostname" versus "domain" distinction > made in RFC 1034. Actually will find the distinction made. Please go re-read RFC 1034 and RFC 1035. Mark 3.5. Preferred name syntax The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes. However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs. For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names. Note: NS specifies a HOST. 3.3.11. NS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / NSDNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: NSDNAME A which specifies a host which should be authoritative for the specified class and domain. Note: CNAME is a general DOMAIN. 3.3.1. CNAME RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ / CNAME / / / +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ where: CNAME A which specifies the canonical or primary name for the owner. The owner name is an alias. > 1034 and its conceptual predecessors > discusses the domain name system as a replacement for the > hostname one and even notes (correctly) that different > applications have different syntax rules for names for hosts. > To make the ambiguity worse, when the term "host" or "hostname" > is used in applications in conjunction with the DNS, that term > often refers to the leaf-note label and not to the FQDN. See, > for example, section 3.7 of RFC 821, which describes > "Fred.Cambridge.UK" as a possible "host-and-domain identifier". > However, the familiar "mailbox" is defined as > ::= "@" > Note that it is not >"@" > or >"@" > > RFC 1034 also seems to believe that all fully-qualified (aka > "absolute") domains names, including those used to refer to > hosts, end in a period, even if that period is typographically > omitted for convenience. > Of course, it also contains a > masterwork of apparently-circular definition: "A domain is > identified by a domain name, and consists of that part of the > domain name space that is at or below the domain name which > specifies the domain." > > While 1034 suggests that the trailing period is always > permitted, even if it is implied, Section 2.3.1 of 1035 gives a > syntax that doesn't permit them. But it does so without trying > to distinguish between a "host" and a "domain". In particular, > it says that [all of] "The labels must follow the rules for > ARPANET host names", which is ultimately a reference to 952 > although 1035 repeats the rule. That rule is applied to all > labels, not just the leaf one or ones identifying hosts. > > As an indirect illustration of this, note that 1035 Section 3.5 > describes IN-ADDR.ARPA as supporting "host address to host name > mapping". That mapping is to an FQDN, not a label or "hostname" > as you use the term above. It does for almost all possible hostnames. Maximum length hostnames ca
