Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, 21 Sep 2013, Dave Crocker wrote: 2) Encourage distributed services over centralized services. For example, social networking services today are heavily centralized. +1 Except that essentially all services other than email have gained popularity in centralized form, including IM. Note that decentralising makes you less anonymous. If everyone runs their own jabber service with TLS and OTR, you are less anonymous than today. So decentralising is not a solution on its own for meta-data tracking. So there appear to be some important and difficult operational and usability barriers, standing in the way of more truly distributed applications. Because people still think of data centers are the CPUs running the internet, when they should be thinking of loading up everyone's phones with these services. These devices are more powerful that our 4U servers of 10 years ago. Paul
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, 21 Sep 2013, Stephen Farrell wrote: On 09/21/2013 02:42 PM, Roger Jørgensen wrote: On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. It's a draft from 1998: http://tools.ietf.org/html/draft-ietf-ipsec-internet-key-00 I'm considering implementing something like that for the next version of libreswan. But if we resurrect this draft, it needs work to get modernized or be started as a complete rewrite from scratch. For exaple, we'd have to ensure that these connections remain sandboxed to the machine, and that any IP assignments are not leaking outside the machine (in the light of NAT based inner IPs, etc) Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, 11 Sep 2013, Joe Abley wrote: 1. We only need to know the current time to an accuracy of 1 hour. [RRSIG expiration times are specified with a granularity of a second, right? I appreciate that most people are generous with signature inception and expiration times in order to facilitate clock skew on validators, but I think 1 hour needs some qualification.] The 1h came from the shortest RRSIG validity time in the chain to get to pool.ntp.org, but performing a handful of queries now, I cannot find that magical RRSIG with the 1h validity period. Note: I also once ran into bad clocks due to dual boot systems with Windows and Daylight Savings Time, so I explicitely set inception time to -2h. One hour is not enough on doubly broken systems. Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, 12 Sep 2013, Theodore Ts'o wrote: More importantly, what problem do people think DNSSEC is going to solve? It is still a hierarchical model of trust. So at the top, if you don't trust Verisign for the .COM domain and PIR for the .ORG domain (and for people who are worried about the NSA, both of these are US corporations), the whole system falls apart. Any co-ercing that happens has to be globally visible, if the target ensures he is using random nameservers to query for data. This should be detectable, and I hope that high value domains (like eff.org) ensure that they are monitoring DNS answers to see if any forged-with-private-key answers are seen in the wild. (eg RIPE Atlas?) Once we have proof of that, we can ponder about how to cut the US Government out of our DNS roots. (sadly, eff.org is still not signed and has no TLSA record. Likely due to their registrar not supporting it, but at least they could do DLV) And even if you believe Verisign and PIR are a paragons of virtue which are incorruptible (even when in a dark room when no one can see, as the old Chinese saying goes), what about all of the registrars? Their dynamic with their users and the market is the same as with CA's --- the market virtually guarantees a race to the bottom in terms of quality and prices. So beyond replacing names like Comodo with Go Daddy, what benefit do you actually think would accrue? You'll still be dealing with a self-service security model, probably using e-mail based password recovery. As Tony said. You can pick a non-bottom one. Basically, DNSSEC maps almost identically to the previously unsolved problem. Not at all - targetted attacks with CAs are easy. Unlike with DNSSEC. Furthermore, TLDs could institute a delay mechanism with respect to updating KSK/DS record so a compromised Registrar requesting an updated DS won't come into effect immediately, and the Registrant has time to react. Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Thu, 12 Sep 2013, Theodore Ts'o wrote: Any co-ercing that happens has to be globally visible, if the target ensures he is using random nameservers to query for data. Not necessarily. First of all, an active attacker located close to the target can simply replace the DNS replies with bogus records, Not if I run DNS over TCP through tor. That's why I said random servers. Are they going to after a single target by being upstream of all the tor exit nodes? Even if they did, we should just run monitors for our own zones that also query for that data using tor. They won't know the difference between the monitor and their target. signed by the registrar's key which was either coerced or stolen by the NSA's Key Recovery Service. Secondly, if the web site has all of its nameservers run by the same organization (i.e., GoDadddy's DNS service), the nameservers could be set up to return the bogus DNS records only to specific IP addresses or specific IP ranges. See above. Finally, if you think the target can try to find random caching nameservers all across the networ to use, (a) there are certain environments where this is not allowed --- some ISP's or hotel/coffee shop/airline's networks require that you use their name server, and (b) for good and proper reasons, most nameservers have been configured not to allow recursive queries to random IP addresses. See above. But also, you can use various open resolvers. The Fedora Project even runs a few for dnssec-trigger that are accessable only via TCP - I'm hoping more people will put up TCP-only open resolvers, especially with: https://datatracker.ietf.org/doc/draft-wouters-edns-tcp-chain-query/ Furthermore, TLDs could institute a delay mechanism with respect to updating KSK/DS record so a compromised Registrar requesting an updated DS won't come into effect immediately, and the Registrant has time to react. A delay mechanism would only work if the TLD sent a notification of a changed KSK/DS record to the Registrant --- but would TLD have access to the contact information for the Registrant? Yes, the TLD runs their Registry with admin-c and tech-c contact information. Another method would be for the domain lock to get a delay of a few hours and/or a confirmation message to the registrant if the registrar changes the lock status. Paul
Re: [DNSOP] Practical issues deploying DNSSEC into the home.
On Wed, 11 Sep 2013, Olafur Gudmundsson wrote: I think you can avoid that issue by having the device not pass traffic until the DNSSEC validation is enabled. Only the device needs the special permissive handling for this to work. You mean only allow NTP and DNS traffic in the beginning, until checks are done? In many cases we can get a reasonable time by writing the current time to a NVRAM variable every 6 hours or so, but that only helps for reboot. And if you think of laptop and/or phone, add hotspot detection to this isolation mode. It's harder because it needs a private browser window type state. Paul
Re: Practical issues deploying DNSSEC into the home.
On Tue, 10 Sep 2013, Jim Gettys wrote: We uncovered two practical problems, both of which need to be solved to enable full DNSSEC deployment into the home: 1) DNSSEC needs to have the time within one hour. But these devices do not have TOY clocks (and arguably, never will, nor even probably should ever have them). So how do you get the time after you power on the device? The usual answer is use ntp. Except you can't do a DNS resolve when your time is incorrect. You have a chicken and egg problem to resolve/hack around :-(. Securely bootstrapping time in the Internet is something I believe needs doing and being able to do so over wireless links, not just relying on wired links. One solution is tlsdate which uses the installed bundled CA (or comes with its own) and runs TLS against a bunch of well known large sites (using insecure DNS) and sets the time based on the TLS handshakes. 2) when you install a new home router, you may want to generate certificates for that home domain (particularly so it can be your primary name server, which you'd really like to be under your control anyway, rather than delegating to someone else who could either intentionally on unintentionally subvert your domain). Right now, on that class hardware, there is a dearth of entropy available, causing such certificate generation to be painful/impossible without human intervention, which we know home users don't do. These SOC's do not have hardware RNG's, and we can't trust them either blindly. Ted's working on that situation in Linux; it is probably a case of the enemy of the good is the perfect, but certainly I'm now much more paranoid than I once was. Be aware openwrt has a history (with openswan) to blindly change /dev/random references into /dev/urandom. You are most likely better of giving the device a webgui and using the clients javascript to generate randomness. (yes I know, I just said to use javascript for private keys) But I'm still thinking of a scheme involving insecure ntp lookups for pool.ntp.org, then using inception times of RRSIGs of TLDs to narrow down the current time. Of course, all of that is vulnerable to replay attacks. Also, I believe the rasberry pi's, having the same problem, have a hwclock service that saves a timestamp on shutdown to the filesystem and loads it on boot. That solves the issue for quick reboots. Another method is the last access time of the filesystem. But I'm not sure if that's a linux/ext4+ only feature, or whether the filesystems in embedded devices have a similar value stored somewhere. Paul
Re: pgp signing in van
On Mon, 9 Sep 2013, Fernando Gont wrote: It might be worth thinking about why ssh and ssl work so well, and PGP/GPG don't. Just a quick guess: SSL works automagically, PGP doesn't. So even if the user doesn't care, SSL is there. PGP, OTOH, usually requires explicit installation of a plug in and weird stuff (for mere mortals) such as generating keys, etc. Related (does not take away the full pain): http://tools.ietf.org/html/draft-wouters-dane-openpgp-00 Paul
Re: IAB Statement on Dotless Domains
On Fri, 12 Jul 2013, Keith Moore wrote: On 07/12/2013 09:28 AM, Phillip Hallam-Baker wrote: On Fri, Jul 12, 2013 at 8:58 AM, Keith Moore mo...@network-heretics.com wrote: On 07/12/2013 08:16 AM, Phillip Hallam-Baker wrote: And before people start bringing up all the reasons I am wrong here, first consider the fact that for many years it was IETF ideology that NATs were a terrible thing that had to be killed. A position I suspect was largely driven by some aggressive lobbying by rent-seeking ISPs looking to collect fees on a per device basis rather than per connection. You are weakening your argument. NATs still are a terrible thing that need to be killed. There is an argument in the above? I read just a misguided opinion with no facts. They break applications and prevent many useful applications from being used on the Internet. That much is more widely understood now than it was 10-15 years ago. It was always understood by the engineers. It's the money making machine that did not care. I think that at this point you are the only person still making the argument that the world should reject the easy fix for IPv4 address exhaustion that solves their problems at negligible cost to them for the sake of forcing them to make a transition that would be very difficult, expensive and impact every part of the infrastructure. I suggest Phillip is rewarded with a staticly configured 192.168.1.1 address for life on _all_ of his devices. Most folk here value consensus. I do not value consensus when it is wrong. Nor do I. Indeed. When you're NAT on the net, you're NOT on the net -- Hugh Daniel Paul
Re: IAB Statement on Dotless Domains
On Fri, 12 Jul 2013, Paul Wouters wrote: I clearly meant 192.168.1.1 to go to Keith Moore, but the terribly gmail quoting method confused me in who said what :P Paul Date: Fri, 12 Jul 2013 10:12:24 From: Paul Wouters p...@nohats.ca Cc: Phillip Hallam-Baker hal...@gmail.com, IETF Discussion Mailing List ietf@ietf.org To: Keith Moore mo...@network-heretics.com Subject: Re: IAB Statement on Dotless Domains On Fri, 12 Jul 2013, Keith Moore wrote: On 07/12/2013 09:28 AM, Phillip Hallam-Baker wrote: On Fri, Jul 12, 2013 at 8:58 AM, Keith Moore mo...@network-heretics.com wrote: On 07/12/2013 08:16 AM, Phillip Hallam-Baker wrote: And before people start bringing up all the reasons I am wrong here, first consider the fact that for many years it was IETF ideology that NATs were a terrible thing that had to be killed. A position I suspect was largely driven by some aggressive lobbying by rent-seeking ISPs looking to collect fees on a per device basis rather than per connection. You are weakening your argument. NATs still are a terrible thing that need to be killed. There is an argument in the above? I read just a misguided opinion with no facts. They break applications and prevent many useful applications from being used on the Internet. That much is more widely understood now than it was 10-15 years ago. It was always understood by the engineers. It's the money making machine that did not care. I think that at this point you are the only person still making the argument that the world should reject the easy fix for IPv4 address exhaustion that solves their problems at negligible cost to them for the sake of forcing them to make a transition that would be very difficult, expensive and impact every part of the infrastructure. I suggest Phillip is rewarded with a staticly configured 192.168.1.1 address for life on _all_ of his devices. Most folk here value consensus. I do not value consensus when it is wrong. Nor do I. Indeed. When you're NAT on the net, you're NOT on the net -- Hugh Daniel Paul
Re: IAB Statement on Dotless Domains
On Fri, 12 Jul 2013, Phillip Hallam-Baker wrote: Today most people have come to accept my position on NAT, in fact it has become the mainstream position. Or perhaps I was not. But I guess it's software written by those three companies listed below that's soo good that makes quoting clear :P But none of the people who spent time trying to slap me down or get me to stop expressing a heretical view have ever said 'hey Phill you were right all along'. Because you're not? (If the quoting worked this time and you really said NAT's have a value other then being a cheap band-aid for those with lots of money) And I don't expect things to be different this time round. But in ten years time it will be obvious that domains are going to be dotless and three of the biggest dotless domains are going to be called .apple and .microsoft and .google and they are going to be the companies writing much of the software used to connect to the Internet and their commercial interests are not exactly best served by supporting clapped out thirty year old software programs. I notice you are missing .oracle and .exchange and .mail. Is that because you can't take any more slaps on the back or because you know too many companies that have servers in their domain that would get bypassed by your awesome magic three software vendors listed above? Dotted domains were a bad idea in DNS to start with and giving a perpetually renewing contract to Network Solutions to operate the best one was sillier. We should embrace the opportunity to throw a bad engineering decision into the dustbin of history not try to take the side of the TLD operators whose rent seeking opportunities are threatened by the inevitable transition to a dotless scheme. I can't wait for your draft suggesting a fix based on a DNS zone that whitelists/blacklists those words that can be used dotless withou harm, after using /etc/hosts through ansible fails to scale. Paul
Re: IAB Statement on Dotless Domains
On Fri, 12 Jul 2013, Phillip Hallam-Baker wrote: I notice you are missing .oracle and .exchange and .mail. Is that because you can't take any more slaps on the back or because you know too many companies that have servers in their domain that would get bypassed by your awesome magic three software vendors listed above? No, I limited it to them only because those three companies can flood the market with software that makes the decision by force majeur. I don't think the domains you list have the market power on the desktop to be a sufficient quorum. avoiding answering the implicit question about huge collateral damage when exchange.company.TLD and oracle.company.TLD start resolving to company external IPs. Even if just _one_ airline company would fall into this trap, it would be millions of dollars of damage alone. Paid for by vanity domains that make turning clearly visible domain names into a confusion about what's a single word and what's a domain name. The community has only two choices that make sense, either embrace dotless domains or deploy DNS rules that simply block all the new ICANN TLDs as unnecessary rent seeking noise. We disagree on the the first, and the second one is as relevant as whether I should add sugar to my morning coffee or not. The proportion of the Internet user community that is aware of default domain sufixes at all is very unlikely to be as much as 1%. So if we are going to make a proper argument on the grounds of avoiding user confusion we should probably be telling software providers to stop supporting the local domain prefixes in platforms as a security risk. The default path on this machine is probably verizon.net. I find the default domain suffix to be sufficiently useless that I never bother to set it. You think that users know and/or can set a default domain suffix? That programmers twenty years ago knew and/or understood what that even meant (or you think no one runs 20 year old software?) That everyone knows about suffix manipulation through their DHCP connections? And VPN connections? Apart from that, were you a proponent of the file extension and mime type wars too? Because as soon as one company takes something like .profitable as dotless, someone else will claim profitable:// and all the browsers will just be giant pools of local policy causing utter confusion and at best will yield a totally unpredictable user experience for dotless domains. Don't expect a pat on the shoulder from me in twenty years. Paul
Hugh Daniel has passed away
Hugh Daniel passed away on June 3rd after what appears to have been a heart attack. https://nohats.ca/hugh-of-borg.jpg Those who met him, know him. Principled to the core, and very present in any room, he compelled people to listen to him - both by what he said, and how loud he said it. He has made many contributions during the early days of IPsec and DNSSEC. He was a manager of the FreeS/WAN Project for many years and co-founder of The Openswan Project and recently The Libreswan Project, although his health prevented him from being as active and he wanted to be in the last two years. I met him for the first time at the CCC summer conference in 1999. Our car had broken down, and everyone around me suggested to find Hugh Daniel for help. He shone his freeswan photon light under the car, diagnosed the problem, and put in a quick fix we could carefully drive to a repair shop at 5km/h where we could tell the mechanic what to fix. We started talking about Linux, crypto and he recruited me for the FreeS/WAN and the goal to make the default mode of the internet encrypted. It is what started me on IPsec, Opportunistic Encryption and DNS(SEC). In 2003, he brought me to my first IETF in Vienna. Hugh, you are still causing a difference and we will raise a non-aloholic drink in your honour when we have reached the universal deployment of encrypted communication for everything. When you're NAT on the net, you're NOT on the net -- Hugh Daniel
Re: meetecho praise
On Mon, 18 Mar 2013, alejandroacostaal...@gmail.com wrote: I used to connect using a regular jabber client but the experience with meetecho is much better. Having audio, chat room and the slides is fantastic. I did not use the html5 version so my audio was using vlc, I had to modify our firewall rules becase the destionation port was blocked. Audio was very good (it can always be better of course). The various versions did not work well for me at all, and I had to go back to using the plain mp3 audio feeds. These had minor issues at the beginning of sessions, but the quality (volume!) was much better then at previous IETF's where I was a remote participant. Paul
Re: [IETF] Re: Welcome to IETF-86!
On Sat, 9 Mar 2013, Warren Kumari wrote: Is someone going to update the IETFers iphone app? It still does not have the sculed in it :/ I have no idea, but this reminds me…. A huge, heartfelt thanks to whoever wrote it -- it makes life much much easier… The IETF86 schedule updates when you install the app store update. However, it seems navigation isn't full working for me yet. Perhaps it will work better once the day is within the schedule. Paul
Re: Welcome to IETF-86!
On Fri, 8 Mar 2013, Jari Arkko wrote: The IETF meeting is beginning on Sunday. I'd like to welcome everyone to the meeting! This blog highlights some of topics that I find most interesting in the meeting: http://www.ietf.org/blog/2013/03/welcome-to-ietf-86/ Is someone going to update the IETFers iphone app? It still does not have the sculed in it :/ Paul
Re: A Splendid Example Of A Renumbering Disaster
On Mon, 26 Nov 2012, Benson Schliesser wrote: I expect to be flamed for suggesting it, but why not use the Shared Address Space for this purpose? (http://tools.ietf.org/html/rfc6598) You can't, if carriers are assigning you that IP range. You'd still get a conflict if you use it for your own VPN range, as the inner address cannot be in the same subnet as the outer address (whether in tunnel mode, or when using transport mode with L2TP) Paul
Re: A Splendid Example Of A Renumbering Disaster
On Sat, 24 Nov 2012, Sabahattin Gucukoglu wrote: http://b.logme.in/2012/11/07/changes-to-hamachi-on-november-19th/ LogMeIn Hamachi is basically a NAT-traversing layer 2 VPN solution. They avoided conflicts with RFC 1918 space by hijacking IPv4 space in 5/8, now actively being allocated by LIRs in Europe. When that didn't work (see link above), they moved to 25/8, allocated to the UK MoD. While I'm almost sure that they haven't got it quite so wrong this time, following the comments says that the idea was not only a very bad one to start with, it's cost a lot of people a lot of grief that IPv6 was clearly going to mitigate in renumbering. Perhaps it is why they recommend it per default, if not for the number of applications that would be broken by it. Both TMobile in the US, and Rogers/Fido in Canada use 25/8. Our IPsec client per default only allows incoming NAT-T for ranges in RFC1918, due to security reasons (you don't want them hijacking google's ip range). So we actually had to add 25/8 to the white list a few years ago. But, it would be nice to have an IPv4 range dedicated to VPN ranges, so you can setup things like L2TP tunnels without fear of collision in the RFC1918 space, although I guess technology has advanced enough to implement proper segmentation and workarounds for this these days. Paul
Re: IESG Considering a Revision to NOTE WELL
On Tue, 6 Nov 2012, Fred Baker (fred) wrote: This note is rather lighter in weight and tone than its predecessor, and seems like a good direction. Can you explain your reasoning why this seems like a good direction. For example, how would the new Note Well improve our situation in the Versign DNSSEC case? Link to patent: http://domainnamewire.com/2012/10/05/verisign-files-patent-application-for-way-of-transfering-hosting-on-dnssec-domains/ Comparison of Patent vs IETF work: http://ubuntuone.com/4Bz1BqOsGMkTUQgViEL0rz Paul
Re: IESG Considering a Revision to NOTE WELL
On Tue, 6 Nov 2012, Stephan Wenger wrote: So, to summarize, out of the 60 or so non-third-party disclosures that have been made over the last 4+ months, only a few may or may not be late; the rest almost certainly is not. Do we have a list of known IPR for which no disclosure was filed whatsoever (a.k.a. very very very late or possible never filing on purpose) ? Without that information, I don't think we can judge how well the Note Well is working currently. Paul
Re: maybe it's getting real
On Sun, 3 Jun 2012, Dave Crocker wrote: Subject: maybe it's getting real Sitting in a pub in the Tiergarten metro station, in Berlin, today, I checked whether there were any open-access wireless points around. There weren't. It's very unfortunate not sharing bandwidth is getting real. Paul
Re: a favor from the list about Jon Postel
On Tue, 8 May 2012, Bob Hinden wrote: https://www.facebook.com/jon.postel I just tried going to this page and it says it doesn't exist. Has the problem been fixed? Looks like it. An hour ago i could still report the page, which I did (and prob many more?) Paul
Re: [dane] Last Call: draft-ietf-dane-protocol-19.txt (The DNS-Based
On Mon, 7 May 2012, Stephen Farrell wrote: The draft is for TLS, but it occurs to me to ponder.. would similar approach work for IPsec IKEv2 as an alternative to verify endpoints? IPsec is in the WG charter, [1] but there's been zero energy for that so far. I believe the chairs plan to poll the WG about that kind of thing once the current spec is out the door. So, if you're interested in that, sign up to the WG list. Related to these are RFC-4025 and draft-kivinen-ipsecme-oob-pubkey, and I do think there is a need to update the RFC to allow for the new raw pubkets in IPsec using SPKI and wrap it up in a dane like specification document, and would be willing to help. Paul
Re: [dane] Last Call: draft-ietf-dane-protocol-19.txt (The DNS-Based
On Wed, 25 Apr 2012, Phillip Hallam-Baker wrote: The browser providers do not hard fail on OCSP because doing so would require them to wait for the OCSP response within the TLS handshake and this is considered an unacceptable performance degradation. And with the current ocsp.entrust.net issue, that would be a two day performance degradation? There is also the privacy issue. But all of this is off-topic. Section 4 of the draft mandates a client hardfail if the DNSSEC trust chain cannot be obtained. This is essential if the client is going to use DNSSEC to establish certificate constraints just as certificate revocation is an essential part of the PKIX model. But no browser provider can expect to succeed with a product that simply stops working when the user tries to surf the Web from a coffee shop. hotspot detection for temporal DNS failure/spoofing mode is what browsers need to support/implement. It is no different then the fix they needed when we opened our browser at a coffee shop and all tabs destroyed themselves reloading into hotspot login pages. Since the coffee shop problem is not intentional we might imagine that it will eventually go away. But this puts DANE in a deployment deadlock bind. Nobody is going to fix their coffee shop routers until there is a need to and that need won't exist until the coffee shop routers are fixed. I suggest you run with dnssec-trigger software for a while and then come back to this assertion. We do not need coffeeshops to fix anything, we need better DNSSEC integration on our laptops and phones. Rather than mandating hardfail or any particular client behavior, the specification should simply state that the client MUST conclude that the DANE status of the certificate is invalid and then leave the client to decide on what course of action to take. This will depend on the circumstances of the particular user and the client provider's assessment of the reliability of the DANE data and might range from do nothing to send a security policy violation notification somewhere to hardfail. In all IETF protocols, there is the local policy overrides, yet we don't add it specifically to every MUST in the protocol documents. Additionally, the browser can fail the connection and terminate the TLS and provide the user some feedback with a local policy override, and then the brower complies to both the hard fail requirement, and your 'too big too fail' argument. Contrary to the assumptions of the specification authors, hard fail is not the best option. It is not even the best option in the case that the users are dissidents. Tell that to the chrome users in Iraq that are still alive and not in jail getting tortured. If anyone is going to sacrifice the one for the many, I sure as hell hope it won't be protocol designers. But you can be sure that Iran, Russia and China will be doing so the minute any client started to make use of DANE. These countries can (and will) make use of a client hard fail to ensure that people don't use browsers that might be used for 'information terrorism' or freedom of speech as the rest of us call it. Sure. Any data can be blocked. You work around the block with tunneling and then use the actual DANE information for your own protection and safety within the tunnel. Suggesting the block means you might as well not add security in case there is no block, or you can break through it, is wrong. But the DANE approach is too dogmatic to succeed. All your arguments against dane are equally valid/invalid for OCSP with hard fail, which you seem to be a proponent of. I fail to see the consistency in your reasoning. Paul
Re: IETF to Meet in Toronto!
On Tue, 29 Nov 2011, Andrew Sullivan wrote: On Tue, Nov 29, 2011 at 03:53:14PM +, Dave Cridland wrote: Welcome to Toronto - ranked 7th most popular place in North America amongst a non-representative self-selecting group of technical people. Obviously, not enough Canadians from outside Toronto were asked. Everyone in the country loves to hate Toronto. There are enough Canadians outside of Toronto? Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Lawsuit against IETF/SIDR/RPKI? (fwd)
Anyone have more info on this? Paul -- Forwarded message -- Date: Thu, 17 Nov 2011 10:34:54 From: Vesna Manojlovic be...@xs4all.nl To: p2p-...@lists.puscii.nl Subject: Lawsuit against IETF/SIDR/RPKI? X-Spam-Flag: NO You've heard it here first ;-) But it's still only a rumor... (does any of you have more news about it?) Aparently, few big carriers in the States are preparing a lawasuit against RPKI creators, since they are funded by US government, _and_ are mandating the system that the ISPs will need to implement... so - anti-trust suit? Conflict of interests? etc... I could only find some old news about this: http://www.networkworld.com/news/2010/121510-feds-internet-routing-security.html That's why it is very important to continue with the development of the alternatives to the routing security... BTW, I got a ticket for 28c3, so -- see you there! Ciao, Vesna -- p2p-...@lists.puscii.nl discussing the distributed, web-of-trust BGP security List admin: https://lists.puscii.nl/wws/info/p2p-sec Archive: https://lists.puscii.nl/wws/arc/p2p-sec ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Use of unassigned in IANA registries
On Fri, 14 Jan 2011, Phillip Hallam-Baker wrote: I suggest that the IAB consider a policy for registries that requires all cryptographic and application layer code points to make use of an approved extensible identifier format, with the two approved forms being URIs and ASN.1 OIDs. -1 Not technology agnostic. Variable length instead of fixed length A single byte or two bytes can work for anyone with any technology, now and 50 years from now. The main impact of this would be felt in cryptographic protocols. Instead of having separate private use code spaces being maintained for IPSEC, DNSSEC, TLS and PKIX, each of the protocols would be extended to allow the use of ASN.1 OIDs (where these are not already used) for private code space. It would be up to the developer of the algorithm to assign the OID. It's too late for that now anyway isn't it. The code path is there, and if you want to be compatible you have to implement it. Adding a second (complicated!) code path isn't going to help anyone make it easier. The advantage of this approach would be that the 'vanity crypto' problem would largely disappear. Particularly if the IETF/SAAG took the approach that it would only recommend algorithms after it was demonstrated that a very substantial community were either using catch-22. How can a substantial community use them before it has become a real standard? Let a hundred flowers bloom and then Darwin can take care from that point on. I prefer my crypto more intelligently designed. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Historic Moment - Root zone of the Internet was just signed minutes ago!!!
On Fri, 16 Jul 2010, Tony Finch wrote:
unbound requires trust anchors in DS format which is somewhat more
convenient, though you still have to edit IANA's XML to convert it into
master file format.
You can also use DNSKEY statements in unbound:
~ grep trusted-keys /etc/unbound/unbound.conf
trusted-keys-file: /etc/pki/dnssec-keys/production/root.conf
~ cat /etc/pki/dnssec-keys/production/root.conf
trusted-keys {
. 257 3 8
AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=;
// key id = 19036
};
Paul
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-hethmon-mcmurray-ftp-hosts (File Transfer Protocol HOST Command) to Proposed Standard
On Wed, 12 May 2010, Joe Abley wrote: I'm actually slightly surprised that anybody is considering enhancements to FTP in 2010. I would have thought that given standardised alternatives which are kinder to firewalls and more secure the logical next step would be to publish guidance that advises against using FTP, outlines the reasons why, and points people towards more suitable protocols. Unless I'm missing some use-case where FTP is actually superior to (say) HTTP, or SSH/SFTP? Agreed. It is irresponsible to patch up the ftp protocol to enhance its life span. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Advance travel info for IETF-78 Maastricht
On Tue, 30 Mar 2010, Iljitsch van Beijnum wrote: The chipkaart costs 7,50 euros but the train trip between Schiphol and Maastricht is 5,85 euros cheaper with the chipkaart than with a paper ticket so you still come out ahead. You can get one from the ticket machines I believe but it probably makes more sense to buy one at the ticket counter and ask them to charge the card with the right amount of credit so you don't run out too soon or get stuck with too much left. Using the counter will cost you 1,50 extra right? So not sure about coming out ahead. You will also forget to check out causing your card to be drained immediately. Been there, done that, have the empty cards... I'll compile detailed instructions in july. Today there was an article about faking the cards on dutch news, but the article vanished. Could be a prelude to April 1st. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Mon, 1 Mar 2010, Tony Finch wrote: DNSSEC is already deployed in 12 top-level domains Add a half for .uk :-) It has a deliberately invalid DNSKEY this week, full deployment next week. There is more then the 12 in itar. From the top of my head: .br .us .museum and .pt, and of course a large part of the reverse (all RIPE zones) and ENUM. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On Thu, 25 Feb 2010, Tony Finch wrote: On Thu, 25 Feb 2010, Martin Rex wrote: What does DNSCurve additionally provide compared to a combination of traditional DNS with IPsec? DNS-based keying. RFC 4025 - A Method for Storing IPsec Keying Material in DNS Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Thu, 25 Feb 2010, Nikos Mavrogiannopoulos wrote: Ssh without secure public key distribution mechanism is not really secure cryptographically. In general, public key cryptography is scure only if public key distribution is secure. Well as far as I know ssh works pretty well today and this model can be easy made verifiable (i.e. secure as you say) by the administrator verifying the keys of upstream. It already is, using DNSSEC. dig +dnssec -t sshfp www.xelerance.org ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 5, ADDITIONAL: 1 ;; ANSWER SECTION: www.xelerance.org. 7200IN SSHFP 1 1 F79BDD2C882A9AC575198D507DE89D9B38145F00 www.xelerance.org. 7200IN SSHFP 2 1 B0B26D4895F3628AA721DAA0DB1B8236AFF02BF2 www.xelerance.org. 7200IN RRSIG SSHFP 5 3 7200 20100306233849 20100220075947 58970 xelerance.org. HgME4vnp12/NhZKRUP7YVrSs6aXPeUvaWSoZ1FIS1Mk/8o9qIQgSb8k3 nC9LiQ8HjwGgVf7T2fSywvvW2KrlnFg8geJPSuMPEFXA41eXLUcmHHxr YQNfxkNnoJPz1iayk9tPjhKtfGwQuoL+hWiGUpnnjBKKU8hiCww4UjN4 yMo= And from man ssh_config: VerifyHostKeyDNS Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to “yes”, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to “ask”. If this option is set to “ask”, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The argument must be “yes”, “no”, or “ask”. The default is “no”. Note that this option applies to protocol version 2 only. See also VERIFYING HOST KEYS in ssh(1). Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote: I would like to see us create an assumption that a given machine will only use recursive resolution services from a specific trusted source. Trust no one. More and more devices will do their own DNSSE validation, and just use caches to get the data. That's the beauty of DNSSEC and one of the two main bottlenecks of DNSCurve (the other is requiring cpu for crypto on every packet) This in turn requires us to add some features to the protocol as we need to add mechanisms for access control. There is already access control possible, eg TSIG/SIG(0). Just no one seems to use it on the stub resolvers. We also need to make some changes to get around widespread DNS hacks used to support roaming WiFi provision. Most of those have moved away from DNS already and just hijack the IP port 80 stream instead. [Oh we are so not close to being done with deployment here. If turning on DNSSEC means the typical Web surfer cannot get their WiFi access at Panera without reconfiguring their machine then DNSSEC is stone cold dead.] The fix for this will come from the browsers, who have to deal with this situation anyway to avoid your 20 open tabs from reloading into a portal page. Rather than using the approach in DNScurve, I would want to see something like the following: * When a new machine is brought up the configurer is asked which network they want it to be a part of, identified by a DNS name. This will be the place that the system will use to look for the trusted DNS resolution service. Since I use 8.8.8.8 I would enter 'google.com'. The default could be taken from DHCP * New RR to allow a machine to locate a trusted resolution service for the network and authentication protocols supported. The initial bootstrap could be taken from the DHCP service. * Key agreement mechanism that allows the client to establish a persistent binding represented by a kerberos style ticket * Packet encapsulation mechanism that enables a kerberos style ticket to be entered into client request packets. Seems much easier to me to store 1 DNSSEC root key and do it yourself. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: What does DNSCurve additionally provide compared to a combination of traditional DNS with IPsec? They appear to have an interest in actually listening to real world requirements. Of course a combination of DNS and IPSec would be a better solution. It would have the same flaw. You cannot expect to ask various DNS servers in a row perfectly encrypted DNS data, then start an encrypted browser session to 74.125.77.19, and expect people not to know you just went to gmail.com. DNSCurve might have obfuscated some of your queries, but any eavesdropping still knows exactly what DNS you looked up and where you went to. Once you realise encryption of DNS is not really possible, what is it that DNSCurve offers that DNSSEC does not? Nothing. And previous postings have illustrated the long list of shortcomings in DNSCurve over DNSSEC. It is not that difficult for Vint Cerf and Steve Crocker to get Microsoft to put checkbox support for DNSSEC protocol into their product. Getting a feature added to a Linux distribution is even easier. But there is a huge difference between doing that and getting a commitment to support it. How many TLD's does it take for people to finally say DNSSEC is adopted? See www.xelerance.com/dnssec/ for a google map. At the moment this is being left to DNS registrars, most of which have no idea what a CPS or a CP is and have no interest in finding out. Many IETF people are active in the DNSSEC Coalition, a group of DNS experts that is helping them solve that problem properly. The Registrars are not left to die. Far from it. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote: But SSH would be much better if we could integrate the key distribution into a secured DNS. See previous post. Already done and running. And self-signed SSL certs would be better if we could use hash values distributed through a secured DNS to verify them. Yes. The CERT/CERTQ record is still a bit of a problem and needs some work. If DNSSEC succeeds, the domain validated certificate business will have to either transform or eventually die. I think that for most CAs, the business opportunities from SSL+DNSSEC are greater than the opportunities from the current DV SSL business. DNSSEC cannot deploy unless the registrars have cryptography expperience, the CAs have that experience. If you ask security researchers, it has been proven that CA's sacrificed security for profitability. The CA model has failed to work. 2 second validation based on email, md5 based * root certificates signed, etc etc. The last two years saw a significant amount of attacks against CA's, and CA's have seen their profit margin fall to near zero, so even if they wanted to, they cannot increase security (you ask me a confirmation for my cert, I'll go to this other ssl provider that doesn't). CERT's in DNS(SEC) put the responsibility of the cert within the domain of the customer. If they care, they can do their security. The time of outsourcing security to CA's is over. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: OpenDNS today announced it has adopted DNSCurve to secure DNS
On Wed, 24 Feb 2010, ty...@mit.edu wrote: Of course, the Certicom folks didn't listen to me back then, and I doubt any of them would listen to me now Didn't RIM buy Certicom (trumping Verisign) ? I'm not sure who owns the patents and who owns licenses and whether the new owners would allow their use freely and unrestricted. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today announced it has adopted DNSCurve to secure DNS)
On Wed, 24 Feb 2010, Tony Finch wrote: On Wed, 24 Feb 2010, Shane Kerr wrote: DNSSEC declares out of scope: * the channel where DS records get added to the parent Is that actually out of scope or just not specified yet? Out of scope. It is the bootstrap problem. Though with RFC-5011 and perhaps draft-wijngaards-dnsop-trust-history-02 the above bullet might should probably read were initial DS records get added Once you have established the first DS record, you should be able to rollover without losing the path of trust. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Wed, 17 Feb 2010, Phillip Hallam-Baker wrote: One of the big fallacies of DNSSEC is the idea that providing clients access to the unfiltered authoritative DNS source is the same as securing the DNS. That was the case when DNSSEC was designed, today most endpoints would prefer to opt to connect to some sort of filtered DNS with malware and crimeware sites removed. most? That's quite the claim. If so, then opendns and friends would be much busier rewriting our DNS packets. The biggest DNS security vulnerability is in the information that is input to the DNS publication service. Most hijacking schemes have been due to attacks on registrars. I thought the most used hijacking schemes used dancing hamsters or nude Britney Spears promises to install a new version of SYSTEM32\etc\hosts. In fact, it was so bad that Microsoft even hardcoded their own update servers IP's in their own DLL's. I have only heard of 2 or 3 attacks via registrar accounts. I've heard of many more compromised caches and hosts files. But I look forward to your substantiation that most of us prefer our DNS to be rewritten for security and saving us from typos by redirecting us to advertisement servers (malicious or not) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The point is not to protect the DNS. The point is to protect the people. And that means that maybe you don't want your machine to resolve every domain name. That sounds very much like the tapping/crypto debate. You may not secure your communications because we're using its weaknesses for your protection. Not securing DNS because some people are using it for something completely different, namely a filtering service, is not an acceptable solution. But besides that, services like opendns can still fetch and validate DNS, and then continue strip it and rewrite it for those endusers that prefer such a service. DNSSEC does not change that at all. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Securing DNS Re: IAB statement on the RPKI.
On Thu, 18 Feb 2010, Phillip Hallam-Baker wrote: The key point is choice. Just as some people CHOOSE to install products such as Norton Anti-Virus that stop certain applications running on their machine, the typical Internet user should probably CHOOSE to use a DNS service that has the known crimeware sites eliminated. Should they also CHOOSE for a porn filter. And a filter on politically sensitive words? Where does our job end to let the user CHOOSE their censorship? And again, you make it sound like DNSSEC is taking away that choice, which is clearly not the case. The point is that the particular obsession with 'end to end' solutions means that we loose the ability to deploy architectures that provide greater protection against the attacks that actually matter. It prevents hacking the protocol (for good AND for evil). And that is a good thing. DNS hijacking is a very rare type of attack. No it is not. It depends on your environment. I'll grant you that its more likely you'll end up on a phising side then caught in a DNS spoof, but that does not validate your opinion of not rolling out stronger security just so people can play games with protocols. And as Mark showed, there are legitimate ways of piggypacking filtering services with DNS using EDNS options. Securing the mapping of DNS names to IP addresses will not provide a major reduction in expected losses due to attacks. It will greatly improve security by providing a hierarchical distributed signed database. You will see many new applications leveling this new option. We already have domain validated SSL certificates that meet that need quite adequately. You haven't been around in the last year? When we had SSL attack after SSL attack? A 2 second email verification for a valid for the entire world certificate is not what I would call quite adequately. The value in DNSSEC lies in being able to establish a coherent network based system of security policy distribution. Sorry, I am not sure what this means. But if it is another application of distributed signed data, then yes, it is another case for the adoption of DNSSEC, not for critisism that it would block some filtering technique, which it doesn't) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [IAB] Request for community guidance on issue concerning a future meeting of the IETF
On Fri, 18 Sep 2009, John C Klensin wrote: I am concerned that, if there is some incident --completely unrelated to IETF-- that someone associated with the host or hotel might overreact and decide to interpret, e.g., a discussion about mandatory-to-implement cryptography, as pushing too close to the politics or criticism line. Those concerns are not different with other countries, including the US. A few hours after 9/11, once I was over my initial shock, I started downloading all cryptography software I knew was hosted mainly in the United States. We are far from a universal faith in any national government. Pre-emptively excluding countries based on culture, (perceived) bias, or other non-technical and non-organisation arguments is wrong. So if the visa issues are not much worse then for other countries, and an internet connection not hampered by a Great Firewall, I see no reason to single out China. Perhaps appropriate people could inform about organisational matters with others who have more experience, for example the IOC. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Retention of blue sheets
On Fri, 31 Jul 2009, Brian E Carpenter wrote: I think that we *care* about IPR disclosures and that we *hate* the idea of people observing IETF activity and concealing relevant patents. So having a record of WG attendance is important; having a record of mailing list membership would be the same. We want to make sure that people can't falsely plead ignorance in case of missing IPR disclosures. That means keeping attendance records for many years - at least for the lifetime of a hypothetical patent. Though blue sheets have no security. They can only be used as evidence for someone being there (after verifying handwriting). The blue sheets can never proof someone was NOT there. Neither can the IETF payment system. Someone could pay and then not show up (because of last minute legal advise against showing up for example) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DNSSEC is NOT secure end to end
On Wed, 3 Jun 2009, Christian Huitema wrote: Also, it is actually possible to improve on DNSSEC by introducing additional knowledge. If two domains have an establish relation, their servers can memorize the relevant public keys. If a host has a relation with a domain, it can memorize that domain's public key. This kind of peer-to-peer improvement makes the domain-to-domain or host-to-domain DNSSEC service immune to attacks by nodes higher in the hierarchy. How do you handle key changes? How do you determine if the key change is performed by the domain holder or an attacker? There is no reason for such a leap of faith caching. In fact, with SSHFP records, we can also nail down that leap of faith for ssh finally :) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end
On Tue, 2 Jun 2009, Masataka Ohta wrote: For my domain: necom830.hpcl.titech.ac.jp, hierarechy of zones have hops of ., jp, ac.jp, titech.ac.jp and hpcl.titech.ac.jp. The authority hops are IANA, JPNIC, my university, and my lab. Though you may have direct relationship with IANA, JPNIC is the third party for both you and me. Yes, security of DNSSEC is totally hop by hop. Just as DNS was designed to work. hierarchical. If you want to add additional protection because you don't trust your parents, no one stops you from using a DNSSEC capable resolver that has DNSSEC zones configured directly, without relying on the parent. I can't preload 50 million keys. I cannot build trust relations with 50 millions domains. Just like we could not preload 50 million nameserver pointers. Hierarchy is the strength of DNS, not its weakness. DNSSEC allows you to specifically bypass the hierarchy for whatever zone you want. The only real question is, how does Masataka Ohta scale? My suspicion is that you don't scale to 50M domains, and that you will be forced to outsource some of that trust. DNSSEC does the outsourcing of trust distributed to the same people who are already responsible for the data you're about to trust. And note that even if you scale to 50M domains, I don't, so don't expect me to setup a trust relationship with you specifically. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Masataka Ohta wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNSSEC is NOT secure end to end (more tutorial than debating)
On Wed, 3 Jun 2009, Mark Andrews wrote: You can, for example, bribe a personnel or two, against which there is no cryptographical protection, which means PKI is weakly secure. You have never heard of a Hardware Security Module? HSM doesn't stop the wrong data being signed. It just stops it being signed on machines other that the designated servers. The context was the false security of DNSSEC and the third party trust. Obviously changing the raw dns data is possible both with and without DNSSEC. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS over SCTP
On Fri, 29 May 2009, Alessandro Vesely wrote: transport security is pretty meaningless in the DNS world which operates using a distributed caching system. One has to trust each cache! Your solution to protect the DNS is just trust everyone? Given that it is pretty easy to predict a subset of the queries a given server will issue in a give time frame, using SCTP can improve reliability better than adding another 32bit random number. The source port randomization patch is not DNSSEC. DNSSEC is much more then a 32bit random number. Please read the RFCs. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS over SCTP
On Fri, 29 May 2009, Alessandro Vesely wrote: It's what the patch has reinforced. SCTP is more secure than the patched bind, yet easier than DNSSEC. where easier means update all the root and TLD servers and load balancers and what not to support DNS over SCTP. While DNSSEC is supported *right now* on that infrastructure. I would not call that easier at all. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DNS over SCTP
On Fri, 29 May 2009, Masataka Ohta wrote: Though there seems to be some confusion that DNSSEC security were end to end It is. , below is an excerpt from an authentic document by David Clark on how PKI, including DNSSEC, involves certificate authorities DNSSEC involves no certificates and no certificate authorities. You know this. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 75th IETF - Hotels
On Wed, 15 Apr 2009, Randy Presuhn wrote: Do we have an RFC for how to format phone numbers? ITU E.123 would be what you want. http://www.itu.int/rec/T-REC-E.123-200102-I/e Clause 2.8 hints at those annoying parenthesized things, and 7.2 makes it clear it's not an appropriate notation for international numbers. And for the next RIPE meeting remember any 7 digit phone number means Amsterdam :) Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Fri, 28 Nov 2008, Andrew Sullivan wrote: That said, I don't want to make light of the end-point problem, since TSIG between a stub and a recursor isn't a trivial problem today either. Moreover, since end nodes in many environments get their recursor's address(es) via DHCP, and since that path is pretty easy to compromise, the whole edifice rests on a sandy foundation. Nevertheless, I just want to be clear that having every end node in the world doing RFC 4035-and-friends validation is not the only path to useful DNSSEC. It's worse. Before you can start validating on your own, or use some trusted remote TSIG accessable resolver, you are likely to need to accept some spoofs to get past the hotspot authentication. Then you need prevent your browser from caching them too much (they do fastflux protection), and your own potential resolver needs to dump the answers once it has a real IP link to the real world. I don't know of any method to both allow hotspot access and fully use DNSSEC. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Sat, 29 Nov 2008, Mark Andrews wrote: It's worse. Before you can start validating on your own, or use some trusted remote TSIG accessable resolver, you are likely to need to accept some spoofs to get past the hotspot authentication. Which is something the IETF should be providing / promoting a standard alternative for. At present normal protocol operations are being hijacked to do this. Browsers could then have a HOTSPOT button which just looked up this information, for example. I'd be very interested in trying to come up with something for this within the IETF to standarize hotspot cooperation. Paul ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Thu, 27 Nov 2008, Michael Richardson wrote: You are. It's all ready. DNSSEC can be done in the plenary by changing the recursive servers. It's pretty close to being completely apt-get/yum/pkg_add able as being on. What's missing is someone to decide what are the set of TAs to use... Even that is done with autotrust and dnssec-keys packages. The only thing that needs to happen is for someone at the distribution to flip the switch. (dnssec-keys package allows that for Fedora/RHEL machine by using a simple dnssec-configure command, including DLV support)[*] The problem is really that there are not many signed zones out there that are reachable. As I talked at IETF-73 with people such as Roy and Sam, there is not really any benchmarking one can do. One can benchmark DNS and one can benchmark crypto, but benchmarking DNSSEC is not the sum of those two. Without the additional signed zones, the IETF Plenary testing really just becomes a much smaller version of a bind/unbound test at a large ISP. We'd be better of asking COMCAST to give a presentation about their experience enabling DNSSEC on their resolvers. And I think testing key rollover during the Plenary might be too disturbing for the plenary itself if it breaks. Paul [*] That and hardware crypto acceleration is basically our DNSX Secure Resolver appliance due Q1 2009. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Proposed DNSSEC Plenary Experiment for IETF 74
On Thu, 27 Nov 2008, David Conrad wrote: However, with that said, I personally believe the IETF network should turn on DNSSEC validation in their caching servers and the IETF secretariat should sign the IETF-related zones. I can't think of any reason why this should not occur at this point. I agree. And they should push their keys into the ISC DLV, and at IETF enable DLV. But in general, everyone at IETF to should do this, not just the IETF secretariat. Paul ___ Ietf mailing list Ietf@ietf.org https://www.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 Fri, 28 Sep 2007, 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. That's why you want your own caching resolver on your laptop. But I guess hotspots won't work as well with that. Then again, the whole captive portal by hacking up DNS packets needs to go away when DNSSEC deployment deems that interfering inappropriate. Is there some IETF work going on to standarize captive portal bootstraps? Paul ___ 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 Fri, 28 Sep 2007, Dean Anderson wrote: 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. A comcast person recently complained on PPML that there wasn't enough RFC1918 space for their internal network. Time for them to migrate to IPv6? :) Paul ___ 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 Fri, 28 Sep 2007, Joe Abley wrote: 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 If you are a worldwide organisation, you want to connect to the nearest VPN point, and not your home vpn point. This is done by customising DNS answers (eg bind views or akamai like setups). The last thing I want is for my Dutch branch, to connect me to the company vpn in The Netherlands, when I'm in the US, crossing the atlantic twice. You only start to use the internal company's DNS server, after you have connected to the VPN - if only to resolve internal network only machines. Paul ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
