OK, thanks. So first of all, briefly explain why we need DNS second instead of the regular DNS, though most of you people probably already know that. We'll spend some time on how it actually works. I'll explain how to use it with bind. Then I'll show you how in the Netherlands, there's an experiment going on on how to actually deploy this. There's a shadow system running that actually works fairly well, and hopefully will be integrated with it in the year into the standard NL3. And then I'll talk a little bit about the tools on how to manage a lot of DNS secure zones. In part two, after the break, I will talk about opportunity encryption, what exactly it is, how you can install it, how you can protect yourself with it. And I'll talk a bit about WaveSec, which is our solution to actually encrypt all your wireless traffic, which we'll also be deploying here at Defcon. So if you want to be secure from all the weird people out here, definitely listen to the WaveSec bit and secure your laptop. So one of the problems with DNS is that basically everybody is involved. It's not something you control yourself. You only control part of it. But how people get to you is completely in other people's hands. This is an example of www.freesone.nl. I've just picked the organizations I've found while sort of traveling the organizational view. And we can see that there's a lot of places where things can go wrong that are completely outside your own control of your own zone. It starts with the root registry. Whoever it is today changes every few months. Internet, Verisign, IANA, whoever it is. Then we get to the root servers. Many people, there are quite some root servers out there. They're more than 30 now that they're using Anycast. There are a lot of things that could go wrong with the root servers that are generally reasonably OK. And we get to the CCT-LE servers where things can go wrong. In this case, for the .nl, we're talking about the domain registry in the Netherlands. Then we get to the bit where your packet will have to go through all the BGP routing structures, which unfortunately is not yet protected by any good secure mechanism. So packets can get lost there before they even reach your zone as well. And then we finally get to the register of the Fris1.nl and the reverse space where things can go wrong. And then you get to the ISP of Fris1.nl, which in this case is actually me. And then we get to the registrant. So in short account, about 23 organizations, plus everybody who can mess up the BGP routing, that can actually get to your domain or perhaps hack into things before they get to your server.  So this is a problem that needs to be fixed. And DNSSEC is meant to fix this. So this is a quick overview of actually a query. I didn't do the layout very well, I'm sorry. Basically what happens when you ask for a www.fris1.nl, you'll get to the IP <IP_ADDRESS>.<IP_ADDRESS>. And if you look at how it actually works from the start, your laptop uses a file if it's using a caching name server, as the root servers, which is a hardcoded list, gets a root server, asks for the name server for .nl, gets an IP number, grabs some glue, continues, gets to the domain registry, which is in Amsterdam, gets another IP number and some glue, continues on, gets DNS record for Fris1.nl, gets NSXDNet.nl, plus some glue, and then finally, that name server actually has the answer that we want. www.fris1.nl is at <IP_ADDRESS>.5.7.9. So these are about eight questions plus three, if you want to verify all the glue that you get to forward servers. There are a lot of things where this can go wrong. To sort of categorize the vulnerabilities in DNS, there are roughly two kind of vulnerabilities. One is the integrity of the data, as somebody actually is somebody messing it up while it's in transit, as somebody doing a spoofing fake packets, filtering out, sending other things, that's one part you need to protect. The other part is the guy who's answering to my query, actually the guy that's responsible for it, and it's the guy that's supposed to answer the query, or is it just some weird guy on the blog. So these are some of the things that you need to secure that are somewhat addressed by DNSSEC, not all of them. First, you have the DHCP server in your network. Once you get your IP, you have to know that you're actually talking to the right guy. You'll find out here that that's often not the case. You have to trust your resulfer, which might be difficult as well if your resulfer is half a planet away. You have to trust the communications to the resulfer. The resulfer has to be secure. And also the name server to name server communication actually has to be secure so that if changes are made, that it propagates properly and is protected. The DNS spoofing can actually happen from the internal side, but also if a server on the other end of the planet is hacked, it can just give you other answers. If a name server is hacked of whatever, ican.org, then it will just give you valid answers. But it might not be the people you would expect the answer from since they're hackers instead of the real people. OK. To the sound technician, apparently on my right, the people have difficulty hearing me. So if they can do anything about it, thanks. I don't think there's much I can do here. So any more questions that I missed, or can I? OK, I'll go on. Yeah, yeah, yeah, go on and ask questions. But if I missed it. OK, just OK. So we have to secure the client resulfer communication. So I'm sure nobody's here using any resulfer that's not on their own laptop. If they're really going to be in deep shit, you can just not trust any resulfer out there. The best thing to do is to just run your resulfer, probably DNSSEC can wear a resulfer on your own machine. That verifies all the queries, because you absolutely have no clue what's being rewritten during the time on the network. The security communication is between two name servers. Depends on what you want to do. If the zone itself has been secured with DNSSEC, then you don't carry too much that things go over the wire in plain text because they have signatures that do it, and you don't really need to further secure it. If somebody would tamper with it, then the signatures are wrong, and you can actually detect it and not serve the data, or the client will detect it and not believe the query. So even though it's strictly not necessary, once your zones are secure, you can, of course, still secure it somewhat. But there are other ways to do that as well. And of course, you have to be sure that your server is very secure as well that it's not hacked into. There are basically two ways in which you can secure the name server communication, which is also used actually for client name server communication. One is T-SIC, the other is 6.0. T-SIC works with pre-shared key and was like a sort of mini DNSSEC when people started out writing this stuff to secure the name server to name server communication. It wasn't very popular. Most people just secured the IP layer, set up an IP stack tunnel, or actually didn't worry about it, or use SCP to propagate those own changes. So T-SIC's not very much in use, probably it's not very useful, especially since it's using pre-shared secrets. You definitely cannot use it for clients to name server communication. The other one, 6.0, is based on public key cryptography. You can actually use that to secure some things much better. That's especially useful for dynamic updates from your laptop to update reverse tree. So DNSSEC basically comes with four new record types. The key record, which is the key used to sign everything, the SIC record, which actually contains the signature, the next record, which I'll come back to later, but it's used to securely say that something does not exist, and the DS record, which is meant to, which is used to build a chain of trust between parent and child. And there's a new flag in the query answer that's the authenticated data flag, which actually tells you whether or not the query was resolved securely. So mind you, do not use it, do not put any trust in it because it's just a bit and it's not protected by any signature so anybody can set it. So just see it as a debug flag only. So this is the standard syntax of the key record. It's the label first, the TTL, IN, key, then we get the flags, protocol, the algorithm, the key material. You can see here it is the key record for freeze one an hour. You can see it's protocol's DNSSEC, you can see the key material in there, the algorithm, it's fairly straight onward, be aware that you can have multiple keys, which I'll come back to as well. The only thing to note now is that they've restricted the use of the key record, so any protocols you're supposed to only use the DNSSEC and not any other value, so it's only type three is allowed. This is the signature record. The types covered, algorithm, number of labels, original TTL, expiration and inception of the signature. It's very important that there's actually dates in the signed signature, sorry, in the signature, because otherwise people could do replay attacks. If you sign something and someone stores that record and uses it a year later, it would be valid because you've signed it if you're still using the same key. So to prevent replay attacks, it's not enough to just have a TTL and expire it, you actually have to say the signature's only valid between this period of time. Again, you see here there's a signature over the two NS records. Also signatures are also based on the type, so if there are two NS records, you'll have one signature over all the NS records. If you have five MX records, you'll have one signature over the five MX records. Then we've got the next record. The next record is basically pointer to the next alphabetically sorted record in the zone. Why do we need to do this? The problem is if somebody is querying for a record that doesn't exist, how do we tell it like this record doesn't exist with a signature? We basically need to sign our answer. It's not enough to say, well, the record doesn't exist, go away. We need to actually say, here's a signed piece of data that says that the data you asked for is not here. So the way that people came up with it is to actually point to the next valid record in the zone. So if you look in the example you see alpha.freezone.nl is the next record that comes after that is gamma.freezone.nl. And the records that are actually in existence for alpha are NS, SOA, MX, SIG, KEY, and NEXT, which I guess the NS record I should have left out because alpha's probably not the name server for Freezone.nl. So now, if somebody's asking for beta.freezone.nl, they'll actually get this NEXT record back, which of course has a signature. So this signed record then says, you've asked for something and it fell somewhere in between alpha and gamma, but we don't have it, it doesn't exist. So now they know securely that beta.freezone.nl does not exist. Update from December is that the key record was limited to only use the key record for DNSSEC. So they decided to split up the key records because they were afraid that there were too many application keys going to end up in the APEX of a zone, so they decided to use a different key type for all the applications. Not everybody was too happy with it. I don't think it's really necessary because there won't be that many keys in the APEX of a zone, maybe an SSH key, an IPSEC key, and two DNSSEC keys, but that's about it. So yeah, well, the ITF decided on this by consensus, so we're stuck with it. So basically key records are only usable for DNSSEC. If you want to do something else, you'd have to make your own application key, which many name server software versions will not support yet, or you have to stuff everything in a TXT record and use your own format within the text entry, which is actually what we've done for FreeZone. So this is an example zone, I'm not sure if people can read it all the way in the back. This is a stripped-down version of FreeZone.nl. You see SOA record, two name server records, an A record for the website, and one MX record. So this is the unsigned zone. This is what it looks like when the zone has been signed. First of all, you see that the entire thing had to be sorted. This is, of course, because the next record has to point to the next alphabetical record, so first thing you do when you're signing a zone is actually sorted before assigning all the entries. So you'll see there's a SOA record, there's a signature over the SOA record, there are two NS records for the signature over the NS record. There's only one MX record and the signature. You'll see two key records, not one, but a signature, and actually both of those keys have been used to sign the key record, so you'll see another signature. I'll come back to that in the next slide. And you'll see the next record pointing to www.FreeZone.nl and the signature, and then we see the entry for www.FreeZone.nl, and one thing to note is that the next record for the last entry actually points to the first entry, so you see that the next record for www is actually FreeZone.nl, the Apex again. So now we have a secure zone.  The parent should securely delegate to the child zone. However, the parent does not have a key to sign anything, and in fact, the parent shouldn't sign anything anyway for the child, because it's the child's responsibility. Where in the regular DNS, you would get a non-authoritative answer saying basically, well, go try here and don't hold me responsible for it. For DNSSEC, you have to be slightly more secure, so you have to basically go there and then somehow we will give you a pointer to check whether you're actually there. And that's where the DS record comes in. What you see here are all the entries for FreeZone.nl at the top level, nl domain name server. You'll see two NS records, and you'll see a DS record, and you'll see that the DS record is signed. So what is the DS record? The DS record is actually a hash of the key of the child's zone put into the parent's zone. The hash is signed saying that the parent believes that that's truly the key of the child's zone, and you'll see that it did not sign the NS records for the name servers, because that's absolutely no clue about that. The only thing it knows is that wherever you end up with, if the hash of that key is the thing that's in my DS record, then you're at the right spot. Sorry? I'm sorry, I can't really hear the question very well. But this is part of the nl zone file, what you're seeing now. So these are the only pointers to FreeZone in the nl zone file. Actually, there's one record missing, which is the next record, which points to the next entry, whatever, g something. This is what's in the parent. I did not discuss yet how the parent actually knows what to sign for the DS key. That's something that has to happen either out of bound or in bound. There's some protocols for that, but I'll get to that a little bit later. So once we have this delegation in place, we can just chain everything together. So the nl key in use is actually also signed and used by the top level, by the root server, which has a DS record over the nl key, if everybody would be using the NSSEC, which unfortunately they're not yet. So we have to come up with a way how to deploy this partially when half of the world is secure and the other half is not secure. So the way to do this is to basically say, this is a key, this is the entry point for that key, and we trust it from here. I see that the key record in the below is actually not very visible. But basically you have a trusted key statement, which you'll probably see in the next slide as well. Basically configuring your name server to say, this is the key for dot nl, and we trust everything from it below. So everything should be signed using this as the start of the chain of trust. So one of the problems we then have is, okay, so we have a key and we secure everything and everybody trusts our key, but what if something goes wrong? Keys have to be recycled at some point. People can just start some super cluster on trying to brute force your key. We don't want to use two large keys because we're gonna have to do lots of CPU and extensive operations. Keys can be stolen from the machine. Lots of things can happen. So at some point, no matter we like it or not, we'll have to replace the keys. So how do we do this? The parent needs to be securely informed. So we can't really automate this and say, hey, this is our new key, go ahead, use it. And then there's also problems with the key records are of course cashed in out there. So at some point we need to make sure that if we change the key, that people do not have the old key while they have the new key and they can't verify the signatures anymore. And one big problem there as well is that you want to make sure that there's the least amount of interaction between the parent and the child, especially if it's out of bound action. You don't want every month to call up your domain registry and say, hey, I've got a new key, can you just verify it over the phone with me? So they came up with the concept of separating the tasks of the delegation. So to fix the DS record, to change the DS record, use one really big key that's secure. You don't need to communicate as often to your parent. And one zone signing key for your own zone, which you can just recycle whenever you want without informing your parent. So basically there are two keys, the zone signing key, which is fairly small and a key signing key, which is a little bigger. These bit values are, it's what's currently used in the experiment. A time will have to tell where they're not, it's a good practice. So one way of these two keys, how does it work? First we've seen the normal situation. I've tried to abbreviate it here a bit. The parent has a DS record, O for the key signing key. And the child has the key signing key, the zone signing key. And then the key signing key actually signs the key signing key record, the key signing key and the zone signing key. And then the zone signing key actually signs all the data in the zone. So now if somebody does a query, it will first find these keys, it will find the DS hash of the parent, come to the child, check the key signing key, find the matching hash, trust the key signing key. Then it sees that the key signing key is actually signed to zone signing key. Then it trusts the zone signing key. And once it trusts the zone signing key, it can trust everything signed with it in the zone. So now when you want to do a rollover, you want to change the zone signing key. First thing you do is you have to add the second key signing key. No, sorry, the second zone signing key. Then you sign it with the old key. When you leave it in the zone for a while for things to propagate. And then when things have propagated, you just remove the old key and you make sure you sign it with a new key and you're all set to go. The key signing key rollover is a bit trickier because now we have to talk to our parent and say you have to change the DS on our key. You can have a look at it. It's fairly complex, but there are tools out there already that actually more or less automate this for you. Some parole scripts actually do this. It's a two-step rollover. First, you add the keys. Then you sign it with both keys. Then you make sure that you update the DS. Then you wait a while and remove the old key. So when there's an unscheduled key rollover, you basically, once your private key is stolen, you have a problem.  Make sure that you're ready if something like this happens. So have an emergency procedure ready. One trick that's come up is actually put a spare key signing key in your zone which is just a signed piece of data. And actually put the private key in a vault and assume it's whatever your name server you're actually just signing machine is compromised. Just delete the whole machine, grab a new machine, grab the fresh key and use that. And just talk to your parent about a quick DS change. And then you're all set to go because the key's already trusted out there. Also, since we're using the trusted key statement in the name server, everybody who uses you as a secure entry point should need to be notified that your key's been stolen and they need to remove that because otherwise they keep trusting the key. Okay, so now how do I actually deploy?  Sadly, the bind development has gone rather slow. So you still need actually to lay the snapshot from December, configure it with SSL support. If you're using Linux, you'll unfortunately have to disable threat support because it's completely broken. Compile and install it, make sure you're uninstalled. Preview stuff or install properly over it. If you wanna tools to test things, do not use the host command or the NSlookup command. They're really old. If you really like the host output like actually I do, that's why I still sometimes use host command. You can use dig plus multi-line and then you'll get a more or less similar looking output and you can actually, in the snapshot, there's also support for digrc file. You can put this in your digrc file and just start using dig instead. If you wanna check the NSSEC, use the plus NSSEC parameter to do secure resolving. If you just want the data without the checks just to verify that the data's in there, use plus CD flags in your query and you'll just get the data without the checks. Like if you don't use that flag on something's wrong, you'll just get surf fill. You have no clue what's going on.  And there's one big issue. We ran into as well at some point, but bind eight actually is too clever. What it does is if it sees that the signature expired or the inception date is wrong or your time on your server is wrong, it will just remove that data from the zone file. So if you start experimenting now, sign your zone for 30 days, then forget about your experiment. Then in 30 days from now, if you're running bind eight, your zone will be empty and people will have problems. So either use bind nine or make sure that your signatures don't expire. No, as far as I know, the only software currently supporting all the DNS stack and the DS records only bind snapshot. If there's any other software out there, please let me know and I'll test it immediately. But so far, as far as I know, bind is the only software out there. Yes? So your question is about how to handle caching of keys? All right, the question is if data is cached, what do you do when the key is stolen? Well, first of all, apart from the cached, there's also the signature lifetime. So if you keep your signature lifetime low, like say one day, then it doesn't matter how long it stays in the cache, after a day it will be invalid. If you actually use a long signature time, then you'll run into the problem that yeah, if all the cache data is out there, then you might have a problem, only if the path of trust is not broken before. Like even if that's cached, if they do a proper check on the entire chain of trust and you've changed your key and the parent has changed to the S key and they actually ask for that data, then they already know that there's some other data there. So automatically that what's in your cache is invalid. Okay, so the actual commands to secure your zone file. Clean as a key gen and then the parameters for algorithm, bit size, zone name, you'll get some output back telling you what key number, what key ID is there. The first command is for, the DIN as a key gen command doesn't really know the concept of key signing key and zone signing key. So you don't see any difference here in the generation of keys. You just see that we used 2048 bits for the key signing key and 768 for the zone signing key. And we'll end up with two files, the dot key and the dot private file, obviously the private file should be very secure on your own machine and the dot key file is actually something you put in your zone. So you could cut the key file into your zone, increase the serial number and then actually use the DNS sign zone command to sign the key as illustrated there.  And you can test it with multi-line DIN as a command. So in the Netherlands, this has already been deployed in a shadow system by the domain registry. You can go to secrack.nl.netlabs.nl and this is an example of how you actually talk and create a DS record at the parent.  What it will do is it will do a query for the key record and you can decide which of the key record is the one that needs the DS, so which is the key signing key. You select it, you hit submit, some email is sent to the proper context that pulls from the WIS database and actually it creates the DS record and the next day your zone is secured. Obviously for the people who've paid attention, they've now seen a big problem, but I don't see any hands raised yet. Okay, this first query that's being done by the registration system can of course be spoofed. So they need to work on preventing this but that's also why there's the extra mill step there to secure it. This is just an example implementation. They need to address things like PGP Secure, the updates for this. They've also written an application to actually do a key rollover at the parent.  This is how a resolve query looks and answer. You can use the two machines listed there to do your own testing on secure resolving. This machine is set up to accept the queries from everywhere in the world. You'll see here a query for actually an old example, fnl.nl. One thing to notice is that you'll see the AD bit being set, so this was actually authenticated data. This is all fine for one zone. How do I handle a lot of zones? There are some standard pro tools written to net DNS stuff and there's some new things written to the net DNS stack, which probably the DNS stack main tools have been slightly renamed in a different hierarchy. Some of these are pre-released by all of Goldman of Ripe. Not all of it is public, but just talk to me and I'll give you a copy and you can test it if you want. These pro tools actually support all the things I've talked about so far. Some commands you can use, main key DB is actually a shell. You can just type in everything with command line completion and everything, or you can just type it all on one line, which says that here's an example. So it's a great key to just type that and it keeps the key separate in a separate file structure apart from your zone file, which means that you can easily roll over stuff and change your keys without actually having to manually edit your zone file. So it keeps your zone and your key separate. And once you sign it actually adds the two bits together and creates a secure zone for you. Then you run the DNS signer and then you can also do the key roll overs. So there are some changes in the organization that you'll need to be aware of. Of course, you do not want your signing machine to be your name server. If you keep all of these secure, all of the private keys on your name server, the next brute exploit for bind will still kill all of your extra security. So it's very important to have a separate signing machine sign the data elsewhere and then upload it to your name server and make sure that your name server have absolutely no rights to your signing machine. It should just be one way communication, which means that even if your name server is completely hacked to pieces, they can only use regular DNS, but they could never use another DNS sex signed zone data to hijack your zone. But it's actually a really cool feature. Your name server can be completely hacked, yet still they cannot send you anywhere else. Don't let the SIG records expire. If you're using complex system like MySQL databases to have customers edit the zone with their own zone, you'll have to write your own glue where it's actually fitted in. So now we've secured the DNS, apart from having a secured DNS, how do we, what other applications are out there? After the break, I will talk about what we believe is the real first application using DNS SIG, which is FreeSwan. Basically, it can do opportunistic encryption, meaning that it can set up IPsec tunnels based on keys that are in the DNS zone. And then of course, if the DNS zone is secure, then you can just spontaneously set up IPsec tunnels to anyone who supports us in the world without having had prior contact whatsoever. For anybody who's maintaining more than a few static IPsec tunnels, this is really something you wanna use because it ensures you massive deployment of IPsec tunnels without having to configure every single tunnel. If you're interested in this, come back after the break. Another application people wrote a while ago to test was the open SSH support, basically put the SSH key in the DNS zone and support it. Unfortunately, nobody's maintaining it. It was written for open SSH 2, I think. So maybe someone can convince the BSD people to update this. The DHCP software actually has some support to send keys over DHCP, which we'll be using for the WaveStack stuff here at the conference as well. If you wanna secure your wireless, come talk to us and we'll show you how to use the DHCP software to secure your last mile here. And there's some next walking software written. If you remember the next record, it points to the next piece of data in the zone. So basically you can sequentially query a whole zone and get the entire zone data. Some people are worried about that, especially the domain registries who basically do not publish lists of the entire domain.  People don't like that. And there's still no browser plugins, no mail clients that actively support DNS sectors, no POSIX support written or defined. That's something that needs to happen now, but that's not gonna happen before people start deploying it on a name service. There's some references here for people who want to look up. The write reference is actually a really good manual if you want to experiment with it yourself. These are all on the slides. You can find it later on. So I'm more or less ready for the break. How much time is there left? We have left 10 minutes, okay. So are there any questions at this point? None, okay, well I'll show you my little script that I wrote then to secure. I'm basically running a copy of our signing machine on my laptop. So if everybody wants all the keys of us, then they should really try and hack into my laptop. Of course it's not connected to the net right now, sorry.  What I did is I wrote just a little shell script. I don't like pearl. Basically increase all the serial numbers to the current date and hour and then you'll see that I've run the sign command. There's a little bug, I have to do one manually because it's a really big record and apparently there's somewhere in the process there's a bug in it. Basically to give you an idea of how fast, actually how slow all of this is. These are about 150 domains that's now running. My laptop is about a Pentium 3500. One thing I found out that I had actually, like my battery life is really, really crappy, but when I was in a train running this for the first time, I actually found out that there's something that you run out of even before battery power, which is random. When you're on a laptop, you really have that random. So there you see the error for the exodine at an L zone. That's the only, there's a really big TXT record we use for the opportunity encryption and it can't really sign it. Now you see it's starting to sign all the zones. It's actually much slower than it normally is. Oh, there we go. So no questions. And we're gonna have a slightly larger break. So if people are interested in setting up the NS2 and IPsec tunnels to secure the wireless, I'll talk to you about the opportunity encryption bit after the break. Thanks. Apparently there are now more microphones and you should be able to hear me a little bit better. If not, just let me know. Okay, so now part two, opportunity encryption. The reason I personally got interested in DNSsec is that I really want host to host and encryption. Just I basically want IP to basically standardize to IPsec. I want everybody to talk IPsec. And no way we're gonna do this with manual configuration. So we have to have something that just works automatically. Basically what we're going to do is we're going to put keys into DNS and use that to talk securely. And of course we can trust the DNS because we just secured it. And we will deploy this here during the conference in the WaveSec way as well. If you have any questions on how to use this, do come to me. We really need to deploy this as soon as we can. Okay, so I'll quickly talk about the basics. What's opportunity encryption? How you can protect your network with it or your servers. How to install and configure it. The config part should be really easy. We've done our best for that. And then we use an example implementation on how to use opportunity encryption to protect your wireless. So IPsec in a nutshell, it consists of two parts. First, we're going to get a private channel that we're sure that we're only talking to one guy and not three guys in the middle. And once we know that we're talking to one guy using the helmet key exchange, we're going to actually ask who this guy is and if he can prove that he really is who he claims to be. And that's the part two thing. Of course, as you might guess, we're going to use DNSsec for that part. So to quote myself, the goal of opportunity encryption is to have IPsec connections without prior arrangement to exchange information with parties you've never knew before, allowing mass deployment of computers on the internet to talk securely and privately. This will mean that anybody who is going to e-stop will have to do an active attack on you instead of a passive listening attack, which is much easier to actually find out. Also for, we'll end up with a service who do not know how to do opportunity encryption, so there's also a way how to, we can just add a server that will do it for the other people that don't know it. You can actually use an OE security gateway to protect, for instance, your Windows server from. So one of the things to prevent a mental and middle attack is to actually have a third party you can trust to get the information from. We'll use DNSsec. So how does this work? First, we're going to put a special record in the reverse tree, in the DNS tree for our IP number. The example that you see here is the key from my desktop at home. It has <IP_ADDRESS>.<IP_ADDRESS>. And it says, and it takes the record that says, I can do IPsec, opportunity encryption. My gateway is this IP number, which is the machine itself, and then the key follows. And of course, this is signed by a signature record. The DHCP server on client, the ISC server actually supports some of this stuff, sending it back and forth to actually establish this even when I'm turning on my laptop in this network here. I will get some random IP and I can actually update my reverse. It doesn't partially work here because we're in added, but we've worked around this by tunneling our own slash 24 in here. So people actually get WaveSec up and running later on, actually have a real IP. So if both parties have the key in the DNS, they can query it and set up a tunnel. So you don't always control your reverse. Actually, most of us do not control our reverse unless we have servers. So we had to come figure out a way how to do this when you have no control of it. So we can't work around it. There has to be one guy in the connection that actually controls this reverse and have something in there. Once you have that, the other guy can just have something in the forward. I guess I'll go away with the blame. So what we can do is we can put our key in the forward. This example here shows my laptop via XT-NetNL, which has a key in the forward. In this case, we don't point to a security gateway because we don't know which IP we are. So the entry right now is 127-001, which basically means ignore me. And again, I put my key in the DNS. XT-NetNL is signed, so it's pretty secure. So now, if my laptop puts in a random network, gets an IP and I go talk to my servers at home, which have all the support for what we need it, I just tell them, hey, I'm via XT-NetNL, grab the key from the DNS, and then we can talk securely. One thing to note is that actually, if I turn on my laptop here and my server for some reason decides to talk to me first, my server does not know that I can do operatives encryption because my IP does not advertise that. So it will send a packet in a clear. Once I get it, and I send an answering packet, then of course I will notice that the remote server can actually do OE and set up OE, but it's a really odd situation when one packet actually flows in a clear. So one problem of operatives encryption, of course, it takes some DNS lookups. And for some servers, that's really too much of a load, especially busy web servers. So there's a way to actually do only passive OE, which means that do not try to initiate OE to everybody who connects to you, but if somebody connects to you using OE, then sure, let's go ahead. And this is actually what we use on for instance the FreeZFound.org website.  If you do have OE, you will get a nicely encrypted secure channel. So we're going to use, this is a form of OE to protect the wireless. This is a diagram of basically what we're setting up here at the conference. We've got the internet, we've got our local network, we've got our laptops. We use, we send a DHCP request that actually contains our key in the request. The server, our own DHCP server, which we added to this network, sees that somebody's asking for OE, and it will next to the regular DHCP server also send an answer, say sure, you can use this IP number, and actually you can use this WaveSack server to do opportunity encryption. And my client, my laptop will receive both of these DHCP answers. I will prefer the opportunity encryption one. It will get the key from the DHCP server from the answer as well, and has both keys to start and initiate a connection to the WaveSack server. Once it initiates the connection, the WaveSack server, which when it gave the IP number to the laptop, actually also put the key it got into the reverse. So it actually knows the key as well. So it knows its own key and the laptop's key. So both parties know both keys and they set up an intersect tunnel, and my laptop will tunnel the default route through the tunnel, which means that even if I'm talking from my laptop to another laptop within the same wireless network, I'm actually talking through tunnels. There were some people who did a man-in-the-middle attack on the DHCP part. If they're somewhere here, I would definitely like to talk to them. Because I just heard about this like a couple of months ago about the utility air check which actually plays, I think a man-in-the-middle DHCP server. So it's really interesting to have those people talk to me. And to answer those people's problems with it, how do we defend against this? Well, the good news is that the DHC working group at the IETF decided to use DNSSEC to secure the DHCP. So once those standards start getting used, we actually have a sort of trusted way to do DHCP and this man-in-the-middle attack is no longer possible. For now it is. So if these people are here, I would really like to see my laptop being a victim of this. So most people at home have like one IP number and they often ask us, like, can we use opportunist encryption? It doesn't work. Actually it does work, but you have to be very careful on how you set it up. Most people do netting on the external interface because it's easier to configure just anything that goes external netted to this IP number. However, if you're doing IPSEC, IPSEC is meant to protect packets from being rewritten. So actually you cannot rewrite those packets. So you have to be sure that you're using net on the internal interface at home so that you first rewrite your packets to your external IP number, then use IPSEC to continue to talk to the world. And probably you won't control your reverse of your ADS set or cable model provider either. So you have to use the initiate only version of opportunist encryption. The IPSEC world, at least in the Linux world, IPSEC has been rather, we've had a rather interesting two months. To make the political issue really short, the people who wrote Frishan believed that a decrease from their government that did not go through the parliamentary process was a problem. Basically US government can kill export of crypto at any time. Therefore they did not want US citizens to write a code so that US government could never claim any full control over it. The Red Hat people being mostly US citizens didn't like that they wanted to fix bugs if they could so they didn't include Frishan. So there was this stalemate that happened for a couple of years, which is now basically being broken by the Red Hat kernel people by basically making their own IPSEC stack. We're talking to them, we're hoping that we can keep everything working. There are patches out there which should integrate really quickly in the next couple of weeks that makes all the extra opportunist encryption hooks that Frishan put in the standard IPSEC to also be part of the new Linux kernel IPSEC stack. So everything I'm saying here should work for either stack, whether you use Frishan or whether you use the new kernel stuff it should just work. And hopefully it also makes porting it to BSD a lot easier. So what do you need to support the extra opportunist encryption extensions? First of all the kernel part which I just talked about. Second you also need to have some support to do the DNS lookups once you get back as to see if you can actually get the keys from DNS and start things from there. So far the only ID that's supported is the Frishan Pluto. Hopefully this will also soon change and then some support for Raccoon will be added. You need to have at least access to one forward zone to put in your key so that you can do initiate only our opportunist encryption. Preferably not some dynamic DNS thing but like your real-owned zone which would be a lot better to use. Most people who want to experiment with this actually have one zone so that should be fine. And if your ISP is going to filter out a lot of stuff then you're in trouble. You should have Ike ports open, UDP 500 mostly and ESP. So how does the opportunist encryption work technically on Linux? Basically all of this predates net filter in the two four kernels. This was written for like the two zero kernels so there's no nice net filter hook-in. Basically what happens is we wanted to catch all the packets before they go out so that we can do crypto on them and see if we can actually set up a tunnel to the remote end. So we need to catch all packets. If we can't get a tunnel we just pass them through and if we do get a tunnel we just first set up the tunnel and then fling them through the tunnel. So how do you catch all packets? Well, the Frishon people came up with a really clever idea. Just grab the default route, cut it into smaller parts so that their preference is higher and grab all the packets. It's the two green lines you can see in the route command that says the first half of the entire ISP space flinging into the IP sacrifice and the second half of the entire IP space flinging into the IP sacrifice. So basically you replace your default route with a more specific default route. For people who don't use the IP command this is the old route syntax. So then of course we need to sort of know what's encrypted, what's not, what's the problem. Do we have a tunnel to the other end? I've tried to put all the states in one picture here. First you'll see that my desktop is running OE on the first line. It says trap all packets going from this IP and into anywhere, which means trap the packets, see what we can do with it. The second line you see a pass E route. This is what we call an E route, an encryption route. So a pass here, a trap means do something with it. A pass means we cannot do crypto with it, just let the packet flow. The tunnel actually means we've set up a tunnel and the IP listed on the right side is actually the gateway. Remember, if you do OE you can also do OE to another server. So if you wanna protect like a Windows farm with a Linux box, then basically my laptop would set up an OE connection to the OE gateway to the Linux machine there and then it would decrypt and be sent to the Windows farm. So on the third line you can actually see that dot 77 is the security gateway for dot 10 and my laptop has a connection to it. So packets from dot 17 to dot 77 are encrypted. They're decrypted by dot 77 and sent to dot 10. We see another pass route, which is to my name server dot two. And we see the next one is a hold route. This is an interesting one. Hold basically means we determined we can do crypto. We should have an IP sector up but for some reason it's not working. So we don't want to fall back into the clear because this guy obviously advertised that he can do crypto. So something's really wrong and we just don't want to send packets. So hold the packet and until the situation gets fixed do not send anything in the clear to this guy. And the other two are just more examples of established tunnels. So to refine this a little bit better, Frisuan starting from version two support something called the policy groups and makes things a little bit easier to say, okay this guy's been misconfigured for so long. I know he advertises he can do crypto but he really doesn't. So I just send it in the clear and you can just put them in a clear file and it will just always work, always send clear or you can do the other way around to say no matter what's being advertised, my own super secure network should always be encrypted and if not just completely block it or which should be your default is try to be private but if that fails, it's okay to do it in the clear. So how to install Frisuan? Most distributions actually already have Frisuan support, Debbie and Susan, Andrea, Connectiva. They all have binary RPMs you can just install because the political issues, Red Hat doesn't have binaries yet. We just make binaries for all the RPMs that Red Hat ships so if you wanna just install binaries you can just go to the URL mentioned there and install it on your Red Hat machine. Every time Red Hat comes up with a new kernel we make matching modules for this or you can install it yourself from source. So if you really want to install it from source just grab the software, make sure you have the GNU Mathematician library installed, GMP, Devil, you need to have the files. Make sure that you build a kernel. Most people come to us when they can't build it and they have other problems because they're using a Red Hat kernel, they're using another kernel, something doesn't work, or actually the kernel just doesn't build itself. First build a standard kernel, then apply the Frisuan patches. There are various ways of doing it. If you just want modules you can do make old go which will just use the same defaults you just used on your previous build on a kernel just add the IPsec stuff as modules. For some people who wanna next to OE do other things like Netroversal, even though Netroversal with OE doesn't work yet. If you need NetT support, Netroversal support, you also have to, there's a patch in UDP patch which actually patches the kernel itself, not any modules. So you actually have to build the entire kernel, not just the modules. But for just OE this is not necessary. So for 2.5, the last few weeks you've been playing with it, there are definitely a lot of bugs that needs to be fixed, but for the alternative IPsec stack it sort of works. Basically, make sure you get the latest patches and just build a use line with make programs and don't build any kernel stuff. So once you've installed it, if you haven't installed it by RPM which will do most of these things for you, you will need to create the DNS records needed for the opportunity encryption. You can, first you generate your secret and your host key with the command list there. Then to make it easy, if you just use the IPsec show host key minus minus txt and then the IP number that's your security gateway, you get the entire DNS record that you need to give to whoever's maintainer of the key or the forward, the reverse or the forward zone. So we make it really easy to just cut and paste your key. Do cut and paste it and not edit it because many people make mistakes when editing it. There's some issues with spaces and bind that are really annoying. For people who directly want to pass to the ISP, you can use the IPsec milky command or you can just directly send it to your ISP and say, give me this record. Though for FreeSound 2, we've made it even easier to use OE FreeSound 1.9, that's what's shipped on most of the distributions. So I just put this in here. This is the only configuration you need to actually get an opportunity encryption tunnel set up on once you've installed the binaries. You make a connection called me to anyone. You basically say, my outside world, you use the interface of my outside world as the interface to do crypto on with the left is the default route. For the right, we say, do operative encryption, do authentication by RSA-SIG and just start this connection. This will use the OE based on the IP number, so on the data in your reverse, so that if the other side queries the text record for your reverse, it will work. If you're doing the initiate only one where you actually have your key in a forward, not the reverse, you need to specify the left ID. And then you need to specify to add and then fully qualify the main name where the record can be found. The left ID then gets used to the IEC negotiation. For FreeSound 2, we basically configured everything for you. It's basically, we just try every few seconds to see if there's the proper DNS records for us to use and if it is, we just use it and we just try to do OE. So the only thing you basically need to do is install it. Mail the key to whoever can put it in a DNS zone file and that's it, you're all set to go. There's nothing you need to do. If for some reason you want to disable it, you can do auto is ignore to stop that connection. If you just initiate only version, unfortunately you need to redefine the connection yourself and add the left ID a bit again. So now to what I think interesting bit, the WaveSec. Now if you want to use WaveSec here and encrypt your local traffic, what do you need to do? First you need to get a patched version of the DHCP. Unfortunately the IEC DHCP developer, Ted has been very busy and it's not really maintaining it. He has these two patches from us waiting for half a year and he still has to apply them. Grab the patch, recompile your DHCP server on client. Add the configuration listed below, which is just, it's a file you can download from the WaveSec org site. So don't worry about it. You need to set up a DNS so that the DHCP serve access permission to change the DNS records for the reverse so that when it gets the key it also puts it in the reverse tree. You need to know somewhat how dynamic DNS updates works. Check the URLs below or grab an example configuration again from the WaveSec site. Since the WaveSec servers actually need to do crypto on multiple interfaces, you specify the interfaces. So instead of using the percentage default route you specify whatever interfaces they're in use. Unfortunately we still need to define every single connection on the WaveSec server, which means that we have to pre-define everybody who can connect. So for a slash 24, you actually have to make 250 connection definitions. We're working on making this nicer, doing it in a nicer way. One problem we have is jump-starting. How can you do a DNS sec, or how can you do lookup keys when you don't have a tunnel yet? Or when you're negotiating the tunnel? So the easiest way we found is to just let port 53, the DNS and the ICMP and the IC negotiation package just flow through outside of the WaveSec tunnel. These are the IP tables rules actually do that. Otherwise your connection attempt will be stuck in another connection attempt and you won't get through. So for freeze run as a client for the WaveSec machine, you also have to get a patched version of DHCP. If you're running Red Hat, make sure to delete the older client, the DHCP CD, so that is not in their way. Be careful that the lease files are stored differently, so make sure you delete all the lease files. For older versions of Red Hat, you need a patch to the if-up script. Red Hat 9 and some of the battles before 9 actually support DH Client, but just don't install it. So once you've installed it, you can just use the standard scripts. And we need to configure the DH Client to actually do all this OE stuff. So once you insert your card, DH Client gets started and it actually starts to set up the WaveSec connection. We do that by using a dhclient.com file. Some of the stuff is generated for you automatically. You just use the command hyperexure-hostkey minus minus dhclient and put it into your dhclient.com file. Stuff should also work for FreeBSD in Kame, though it needs a lot of manual configuration still. If people wanna try it, come talk to us for these specific details. Also, of course, Microsoft Windows would be really nice to support as well, except that they cannot grab the keys from the DNS and then use that. So we have to figure out something else. We're thinking of doing something here with X509 certificates and X509 patch to FreeSwan. If we find out something, then we'll put it up on the WaveSec box. Again, talk to us a few if you wanna experiment with Windows. We think we should have something running in the next few days, but we don't know for sure. So how do you test your OE setup? Because one of the important things, if it doesn't work, if you set it up wrong, you will just have no connections to the world. So there are many common mistakes people make. We try to catch them in the command hyperexure-hostkey which verifies your setup. This is an example where you see that the key has not been put into the DNS. We check for some common mistakes, like is IP forwarding enabled if you have two interfaces? If you're using NAT or masquerading on the machine, are we sure that we're not destroying the IDsec packets? It's generally a good test run to see if it works. Another way of testing OE is actually to go connect to the machines that support OE and see what they tell you. There's one machine currently, which is called Untappable, actually in the NL, that actually has all the DNSsec support as well. It's an example that I show here. I have connected, I've pinged the machine, and then I tell that to the go for port, then the go for port just gives me all the output. And you can see that I actually had, when I did this at the IP number<PHONE_NUMBER>, and I was actually in a properly signed DNSsec signed zone file. And so that machine knows that my RSA identity that was put in the key in DNS actually came from a secure DNS.  Some other test sites that should support OE, more and more sites are using it, so this list will become longer. So there's still some problems that people run into when they use OE. The first problem is that once you start OE, and you wanna set up a tunnel, you need to do a DNS request. Usually that DNS request starts the initiation of yet another tunnel. So for a few seconds, while you're not able to actually go to your DNS servers, everything will fail, and you need to wait for that failure to be complete, and once they're passed around to your name servers, then suddenly all the other connections can actually be set up because then you get DNS answers. So once you start pinging, don't worry when it just doesn't work immediately, just check your log files and see if it works after a few seconds. FreezeFence still has some problems integrating properly with the scripts from various distributions when a card, the laptop PCMCA card is inserted and removed. We're working on getting that better supported. People also often make mistakes in getting the keys into DNS, like I said. Spaces, there are some spaces in the text records that work around a few bugs and older versions of bind, but people tend to either not grab them or leave them out or miss paste them. So be careful when you're cut and paste. Another annoying bug is that, apparently there's some issue. If DH client has run from the command line, everything works, but if it comes from a kernel generated event, like the hop-lock stuff when you insert your card, on some machines, for instance, my laptop, we're getting errors on P open and P close, which we haven't found a reason for. And due to the update on the ITF use of the key record, we had to change some things since we're officially not allowed to use the key record by Psec anymore. So that change went into freeze on 201, which means that 200 cannot talk to 201, so if you're running older servers in the OE, make sure you at least use 201, which knows how to talk to older machines. And problems we've also seen is people who have just too many tunnels inside each other, and then you get either fragmentation or empty view problems. If you run into that, and it especially happens when you have like PPP over ethernet or ADSL tunnels or PPP stuff, usually when you're provided with really yucky things, make the packets a little bit smaller, usually problems go away. So for like, we'll really do our best to generate a log message that actually makes sense for every single event that happened. So the log files are really to the point when they point out an error. So really try to check your log messages. It's really in there, what's wrong. Run the IPsec verify command I showed before. Disable all the firewall rules to make sure that your firewall is not blocking packets. And if that really doesn't help, you can use IPing to see if your ISP filters QDP 500 to prevent you from running IPsec. Make sure to stop freeze one when you do that because otherwise freeze one will grab the port. And if all of that just doesn't give you the right answer, there's one thing you can do is that's run the command IPsec bar, which will basically point, it will put all the state of your IPsec subsystem except for your private keys on your screen. And if you just put that on a website and ask people on a mailing list or the IC channels, they will look through it and they can probably see what the problem is. One very important thing to do, people see the Clip's Debug and the Plural Debug variables and enable that. Then those people are posting 10 to 15 or 20 megabyte files with debug information that the people helping you on the ISC channel really do not want to read. The debug functions are only for developers, so please do not use them. It's not going to give you more information that you need. So if you want to try out openness encryption, if you want to try out the WaveSec, grab either me or Ken Bantoff here in the front, we'll be gladly helping you set up your IPsec tunnels and secure you from all the evil hackers here at the conference. So I hope people will see the value of end-to-end host encryption and see that openness encryption can really reduce the administration task of setting up a massive amount of tunnels, whether it's inside your organization or just to out to the world and to the internet. We hope that BSD will soon support this as well. We're talking to some people and so let's hope that basically in the near future everybody is talking encrypted and we're all safe from evil hackers or evil governments. So are there any questions? Then I guess I end early. Okay, thank you very much.


Rwy'n dechrau i'r unig. Fy hoffi'r hynny, ddyddai'n ei ffrindio'r ffrindio'r cyhoeddfeydd ar yr awdurdod yr oedd y byddai. Fy hoffi'r ffrindio'r byddai'r byddai'n gwirio'r cyhoeddfeydd yn ffrindio'r cyhoeddfeydd y byddai. Roeddwn i'r cymdeithasol ysgolwyr Sally Ann Hart ac fe gyda'r cyhoeddfeydd. Rwy'n rhoi'n ddim yn ei gweithio'r cyhoeddfeydd i'r cymryd ac yn cyfrofi'r cyhoeddfeydd. gymaint iawn ychydig yn ôl yn cymennu. Mae'n du'r ddod wnaeth yn gweithio i gwybod a bod ni'n ddigwydd i'n gwybod. Os bydda'r defnyddio'n amser, ddim yn y cwm Llywodraeth Salianne Hart, ac fyddwn i'n dweud ar y Llywodraeth MilŽbwrn. Mae Ymddag ymlaen i'r iawn ymdag yn Llywodraeth Anne Bradden. Ddod yn yfun, mae'n lilwodraeth Anne Bradden a rwy'n dweud o'r dweud ar y Llywodraeth yn Llywodraeth MilŽbwrn. Yr cyfeir yma. I am Cwmser Mark Owl, as you've already introduced me, and I represent the U-Papwith and Caxon Ward. Cwmser John Williams. Good morning, Chair. I represent Fendin and Folbourne. I'm also the lead Cabinet Member for Resources. Cwmser Peter Fane. Cwmser William Jackson Wood. Peter Fane Shelford Ward. Thank you. And Cwmser William Jackson Wood. Good morning, William Jackson Wood, from also the Shelford Ward. Thank you. I can confirm that the meeting is current. We have the Head of Transformation, HR and Corporate Services, Jeff Memory with us in person today. Good morning, Members. And we have Helen Cornwall, HR Service Manager. Good morning, Members. And also we have Ian Senior representing Democratic Services today. Good morning. Are there any other officers online joining us today? And can I invite Cwmser Heather Williams to introduce herself today? Good morning, Chair. Good morning, Members. Heather Williams, I represent the Wardens Ward. Thank you. So we come to item one on our agenda, which is Apologies for Absence. Ian, can I ask if there are any other Apologies for Absence today, please? Yes, we have Apologies from Councillor Sinita Hans Raj and from Councillor Richard Stobart. Councillor Peter Fane is subring for Councillor Stobart. Thank you. Item two on the agenda is Declarations of Interest. Do any Members here have interest to declare in relation to any item of business on this agenda? And if an interest subsequently becomes apparent later in the meeting, please would you raise it at that point. Thank you. Moving on to item three, the minutes of the previous meeting. This was held on the 28th of June. Do any Members wish to make any amendments to these meetings? Councillor Bradman. Thank you, Chair. I just observe on page five at point four and elsewhere, the policy is referred to the hybrid policy. And I think it should be hybrid working policy because many things can be hybrid, but we're talking about working specifically here. So I think that should be noted. Thank you. Any other comments on the minutes? I have just a small one on paragraph five. It's the penultimate line. There's an extra word. It says officers advised that the data was came from standard reporting. I think it said that the data came from. So I just need to admit there was. So can I take approval for these minutes by Affirmation Members? Agreed. Agreed. Thank you. Item four on our agenda is the staff health and well being survey. This is an information item regarding actions taken and areas requiring further action. As a committee we are being asked to note the report and Jeff I understand that you'll be presenting this item. Thank you, Chair. Yes, this report details the results of the staff welfare survey. There were two surveys undertaken. The first was in August 22 and the second survey was after the initial three month trial of the four day week. The survey is quite detailed and for a number of areas compares how people were feeling in the council with a data set that's measured across both local authority and private sector employers so that we can identify not only how people are feeling, but how that relates to how people are feeling generally in the country in relation to their work. The two surveys show a significant improvement in the welfare of staff across the two surveys. Although it has identified that some areas of improvement were greater for some groups of people than others. So the HR team has been looking at how we can address those areas where the improvement hasn't perhaps been so great. The really positive thing though is that across almost every single area we've seen some improvement. The survey was undertaken by a private company and the results were anonymous. Although we were able to get group results, we as a council didn't get any individual results. So people were free to express any concerns and be honest about how they were feeling. I think that's reflected in the results that we've got here. Overall it's a really detailed survey and we're able to break the information down into a lot of different cross sections. So as I think members will have noticed by reading the report, it includes not only gender, but the amount of time, for example, that people have been working here, whether the members of staff have a disability, whether they're working full time or part time, and enable some quite detailed analysis. We're continuing to work on those areas where we can see that more effort's needed, but overall I'm very positive about the results. I think either Helen or myself will be happy to answer any questions that members might have. Thank you. Thank you. Thank you, Geoff. Members, do we have any questions? Councillor Anna Bradman. Thank you. I'll have one for Helen if I think probably. It relates to the measure intention to leave, and if we just look at right at the very beginning, for example, on page 14, we're looking at 2022 versus 2023, and the intention to leave in 2022 is scored as minus two with some pink colouration on the charts, and in 2023 the intention to leave is scored as plus nine, but it's green, and that seems slightly counterintuitive. So could you just explain what that marker actually means, please, or maybe how it's calculated? Yes, thank you. So the way that the survey is demonstrated is a score below or above a median score. But because this organisation is independent and they survey a number of different organisations, what they do is benchmark it on a median of all organisations. So, therefore, a dark green colour indicates a positive result, so that the scores are above where a median score might be in terms of an intention to leave. A light green indicates a typical result. The pinky kind of colour, light red, indicates that maybe there's some area of caution there, and the dark red kind of indicates that that might be a risk factor that needs some more, you know, looking into to see what might happen. So where you've got a negative score, that means it's that many points below the median score, and where you've got a positive score, it means there's that many points above the median. Thank you very much, that's helpful, because I think the numbers are a bit confusing. Thank you. Can I just invite councillor Dr Richard Williams to introduce himself and just join the meeting? Thank you. Thank you, chair. Apologies for that. Councillor Richard Williams, Representative Whittlesford, not normally a member of the committee, but I've come along today. Sorry, I didn't quite catch that last bit. I said I'm not normally a member of the committee, but I've come along today. I've noted. Thank you. Councillor Mark Howell, do you have a question? Thank you very much indeed. I've got good work in the report. Page 16 is the one I'm going to concentrate on. I don't know whose answer. I'm a little surprised that we've still got teams to have lots of reds in the 2023 with 44 respondents, especially on engagement. Could somebody comment upon that, please? Is that one for you, Geoff? Is the finance service one? I think what this represents is the finance team has been under a considerable amount of pressure over the past couple of years of working really hard to get our accounts up to date. Certainly, we're working very hard with them to ensure that they are engaged in the process, and we've produced a guide to go out to all managers, which helps them make sure that they're engaging with their staff. We've introduced team charters, which means that the managers will meet with their colleagues in the team and work out how they best operate. But that is an area that we're continuing to focus on. I have had discussions with the head of finance about the best way of addressing this in his area. We're making sure that whenever we plan any health and wellbeing sessions, we focus on the finance team. Anything that I need to add to that? I think the only other thing to add is there is an ongoing review in that area, which is ongoing. I think that's obviously an additional cause of pressure on the team at the moment, and that's hoping to be concluded relatively shortly. Hopefully that will help. Can I ask another one? Thank you very much. On page 24, you have the length of service and the respondents by their length of service. It seems like to me that the longer you stay, the worse things are getting. But I mean, I'm just being thin. Mainly in the three to six years period. But also others. I'm so sorry. I missed to read that, and that's my apologies there. I can see what I've done there. So sorry about that. I retract that question. Did you say you're retracting that question? Okay, thank you. I just wanted to go back if it's okay to pick up on your first question about the finance service. I'm just wondering if there might be a way for the information to come back to committee on how that's progressing rather than leaving it for another... Yes, certainly. I mean, we'll be undertaking further work with the finance team, and we'll be testing the results of that work. And we'll be very happy to bring that back to this committee once we have those results. Thank you. Councillor Peter Pan. Thank you, Chair. My question relates to paragraph 14 on page 11 in relation to encouraging colleagues to work from the office on a more regular basis, partly so as to reduce the loneliness that some reported in the 2022 survey. Clearly, there are some other factors on which this is reported that could be affected by that. And the emptiness of the office has been, of course, the subject of public comment, including a photograph in the Times on Saturday. But I noticed that at the bottom of this, the reduction in loneliness and so on has been addressed partly by twice weekly vlogs, new teams channels, and team meetings, which could, of course, be either on teams or in person. I just wondered to what extent colleagues are more inclined to work in the office now and whether that is having the impact that was hoped for. Yes, we are here. The number of people in the office will vary depending on the day, the time of year, the work that's being undertaken. But certainly we are seeing more people coming into the office more regularly. I think the average number is around 40, which is a lot lower than it used to be prior to the COVID pandemic, but is more than we sometimes get in the office. What we've been saying to people is that you should come into the office in the most effective way to work, and anyway, there should be team meetings at least once every two weeks, so not just somebody coming into the office once every two weeks, but the whole team coming in once every two weeks to work together with other people coming in more regularly. I know that members of the leadership team are coming into the office to make sure there's at least one of us in every single day, and I know most teams are ensuring that they've got people in the office to cover most days. I remember, but I referred earlier on to the team charters. That's an important part of the way that we're working at the moment, because teams have talked amongst themselves about how they can be most effective. Apart from saying that you have to have those teams meetings, you have to make sure that you're coming into the office regularly, and particularly where we've got a new starter, ensuring that you've got people coming into the office regularly to meet with that new starter to help acclimatise them. We are still giving teams quite a lot of flexibility. We are seeing an improvement in how people are feeling about that, but it is something that we're keeping under review. If we're finding out that that back isn't improving as much as we like, we'll review that and issue more detailed instructions to staff. Again, it's part of the toolkit that we've been sending out to managers, that managing in a hybrid working environment is different to working in the way that you used to work for, and actually managers have had to spend more of their time ensuring that they're doing checking in with people that aren't in the office to ensure that they've got that connection. You mentioned teams that certainly are an invaluable asset, and most of our officers have now also got the ability to contact each other via teams, and we're asking managers to ensure that they're doing that regularly, but we are keeping it under review. If I may, Chair, just to comment that the reference to team meetings doesn't necessarily mean teams meeting. Thank you. Are there any other questions from members of the committee before I come to Councillor Heather Williams? Councillor Bretman. Thank you. I just wanted to look at the data from disabled staff, and very noticeable concerns in 2022, but certainly the report at paragraphs seven and eight I'd clarified that. I really wanted to thank the officers for achieving such a big improvement in 2023, and I wondered whether you could explain if there was a particular thing that you think has made this such a big improvement, age 19 in the grove. I think it's difficult to specify completely what it is because obviously there's a number of different interacting aspects to this, but some of the things that we've introduced relatively recently are the disability passport policy and the work that we've done towards the disability confident accreditation.  Councillor Heather Williams, do you have a question? Thank you, Chair. It's in relation to page 11 and the response to Councillor Peter Fane's question about people being asked to work in a way that's most effective for them, but of course that's quite subjective when you say the word effective and also thinking of the interactions with other people that what works for one person won't work for another and particularly on the element of loneliness. If we use a Myers-Briggs analogy, if you are introverted, then working at home is going to be lovely, you're going to have peace and quiet, et cetera, unless you've got a child running around like I do. If you're introverted, that lack of human contact, that lack of people to get your energy from and interact with is really actually very draining and can have very adverse effects. So I'm wondering, has there been any sort of analysis of our staff as a whole? Do we know what people's preferences are, their natural preferences? Did we do any profiling of our staff at any point so that we could then make reasonable assessments as to what is for the majority? And just on having somebody from each team in the office a day, that is not my experience. And that's on several days when I've come into the building. So how has this been monitored and what can be done in the monitoring of this to ensure that there is a member of back room staff for each department in this council every day to support the contact centre? Thank you, Chair. Is that more for you, Jeff? Yeah, I'll start to move that. Thank you. In terms of have we done an analysis about whether people are introverts or extroverts? No. But we have started doing something called Emma genetics, which looks at how people operate to take in information. There's something similar to that because some people, as you say, are very social. Some people are a lot less social. Some people look like to look at the big picture. Some people need to know the detail. So it's a little bit more detailed than that. It's not spread out across the whole of the organisation yet, but that's something that we are rolling out. In terms of the team chart, is what we're asking services to do is to talk about how they operate best. But of course if people, we're not saying people aren't allowed to come into the office. Those people that get their energy from other people, we're very happy for those to come into the office every day if that works best for them. In fact, one of the reasons that we moved all of our people onto the first floor was to ensure that we had the opportunity for people to have relatively easy contact with lots of colleagues. In terms of monitoring who's in the office on any one day, we do monitor the badges when people come in. But that isn't analysed at the moment to analyse centrally to make sure that there's somebody in from every team. The managers are the ones that are expected to manage that. I'm sure you're right, there have probably been occasions when there isn't somebody in from every team in the office, but I haven't had a lot of reports from the contact centre that they're having difficulty getting through to people. But I'm very happy to talk with my colleagues of the corporate management team and get some more information on how they're ensuring people to come into the office and feed that back to this committee. But we haven't done a centralised analysis of that at the moment. Did you have another question? Yes, thank you. So you said about the badges. Obviously the hybrid working policy requires people to come in one day in a fortnight, if memory serves me well. So how are we ensuring that that's complied with as a council? And I would say we did have an issue, one planning committee not so long ago where we couldn't start because we didn't have a planner in the building to support us. So I'm saying these things are happening. The policy is that there are team meetings once every fortnight.  How often they come in will be decided as part of that team charter. I'll make a note of the fact that there was no planner in the building. It's unusual, there's normally a number of planners in my experience. I think Stephen Kelly himself is normally in four times a week. But I'll raise that with Stephen. Are there any other questions members? Councillor Brandon. Thank you. It was just an observation really. And that was what has impressed me about the approach right from the very beginning when COVID struck for hybrid working was that management made it absolutely clear that members of staff could have as much autonomy as they needed to work as they felt was most effective. And I think that showed a remarkable degree of trust in our staff. And I think our staff have showed how worthy they were of that trust. And I think what we have seen is that broadly speaking perhaps not every element but broadly speaking this data shows an extraordinary degree of happiness, satisfaction, comfort, reassurance with people. Of course there will be individuals and I'm sure their teams are aware of them. But I'm really impressed by the results that have come back from this anonymous survey in 2023. I'm really encouraged. I think it endorses the chief executive's decision to say to people take anything you need home, take any equipment you need, work as you wish. And then we've gradually learned about how to bring people back into the office in a way that works for them. So I think it's very encouraging and I'd like to commend this work. Thank you. Thank you. I just wanted to make another comment really. I'm looking forward to seeing how things progress. There are so many variables in the world today compared to the world a couple of years ago. It's very different. The part-time working that I think was interesting for me as well and I'd like to thank officers for thinking about how we can ensure that the benefits are delivered equally. So yes, thank you very much for the report. Sorry, Councillor Mark Ham. It's not so much a question, but the methodology that they've used now in these two are we going to be changing that because once you change it, it's very different to do comparisons in the future. So we're going to stick to this methodology now. We are. Thank you very much. That continuity is important. And mindfully, obviously, there were questions put in about four-day week because that wasn't there before. So yes, thank you very much. Members were invited to note this report, so noted. Look forward to the next one. Thank you. OK, members, we're moving on now to item number five on the agenda. This is the HR recruitment, retention and absence data. And that covers June and July of this year. Again, we're being asked to note the report. And again, Jeff, I believe you'll be starting to take all that. I'll be Helen. I was Helen. Apologies, my script is different. There's a bridge in the gate. Thank you. Thank you, Chair. So as you can see from the report, there's some positives. And we're starting to record more recruitment data. So we're starting to see some positive results from those in terms of number of applications. We've also started the two surveys in terms of asking questions of those people who have interviewed with us but were unsuccessful and also those people who are in their induction period with us. We are hoping to go on a soft launch for our recruitment module. So again, that will provide us with some richer data in terms of recruitment. And so we're quite positive about the results of those. In terms of the absence stats, certainly the statistics remain consistent within an acceptable range and below our regional benchmarking. And we continue to monitor the detail and reasons and take appropriate interventions and steps where necessary. Thank you. Members, do we have any questions on the report? Yes, Councillor Richard Williams, did you have a question or comment? I did, Chair. I'm just slightly surprised that you haven't gone to Members first. I'm just checking I've got the right report. But yeah, okay. I did have a few points on this one. Just in terms of page two. So we have the statement about the... So page two of the... I've actually got the online version, sorry, I haven't got the papers, but page two of the item report, there is the paragraph in the report to Cabinet of May 2023. And there's at the bottom of that a saving of $550,000, which relates to these nine posts, which has been repeated a few times. Now, it's already been confirmed to me in correspondence with officers that that $550,000 is actually an extrapolated figure. Had these posts been filled by agencies that for a year, it would have cost this much more versus the staff cost. But my broader question is, that's a very difficult figure to use because it just focuses on these 23 posts. So you might fill all of those 23 posts and then you could claim some huge saving, probably of over a million pounds. But if another 23 posts have become vacant and you're employing agency staff to fill those posts, actually you've not really saved anything because you're spending agency costs on other things. And that's why it's not in these papers, but again through correspondence with officers, the amount of actual money that this council has spent on agency staff in January, February, March this year and April, May, June this year, it's actually higher than it was in 2022. And that's the only thing that really matters is the amount of money we're actually spending. So I think if we could just have some clarification really of that point, that okay, it's fine to focus on these 23 posts, but the fact that they're filled doesn't necessarily mean a saving because if another 23 posts, as I say, become vacant and we're filling them with agency staff, we've not actually saved anything. And then just one other question chairs around. I appreciate, I'm taking a bit of time. That's just a clarification question. When it comes to chart number six, in this report and the calculation of the cost, if I understand the report correctly, of absence days lost by cost, has the way that that figure has been calculated changed to account for the fact that if staff are working four days rather than five days, the proportionate loss of productivity from a sickness day is actually much higher on a four-day week than it is for a five-day week because obviously the salary now is being paid over 30 hours rather than 37. So does that figure reflect a change in the way it's calculated to account for the fact, as I say, that the lost day in a four-day week is much more lost productivity than a lost day in a five-day week if we're to believe, which is a whole other story, but let's just say we do for the minute that actually the four-day week results in the same productivity in four days as five days. Thank you, chair. So it sounds to me like there were two things being asked for clarification on there. I'm not quite sure if I'm coming to Jeff or John or John or Jeff first, John. Well, I have the first question. Thank you. And, you know, as Jeff and I say, there's good and bad agency costs. For temporary posts, and I think we've given an example of the work that we've been doing with the Ukrainian visitors, we will fill them with temporary staff. And there is, and within the budget, there is a budget for those temporary staff. Where you're dealing with more permanent posts, especially ones in planning, because in the budget, you will budget to fill them on a permanent basis. So you would expect to fill those staff, you know, those staff would be paid whatever the going rate is in the council. And it's those posts that are the ones that we're concerned about because we're not filling those posts. We're having to employ agency staff, which we would not have budgeted for because we would have budgeted for them to be filled as permanent posts. So the half a million pound saving is the fact that it's those permanent posts that we are filling instead of having to employ agency staff to fill them, which would have meant us having to find another half a million pounds that we hadn't budgeted for. The temporary posts and the agency staff that Councillor Richard Williams is talking about are people that we have budgeted for. So, you know, you can't take one from the other. The fact is that if we hadn't fulfilled those permanent posts, we would still have filled the temporary posts with agency staff, but if we hadn't fulfilled those permanent posts, we would have had to have bought in agency staff that would have cost us over the year an extra half a million pounds on our budget, and that's what we have saved so far. Thank you. Jeff, did you want to respond to the second question? A bit more clarification on what Councillor Williams was asking. There are effectively three categories of posts that we're having to keep track of. One of them is where there was a post that was vacant and being filled by agency originally, but now is the same post, but is now filled permanently, and there are nine of those posts. We also need to keep track of posts where when the first report was written, there was a role and it was vacant and filled by agency, but those posts are now no longer exist. We've been running a transformation programme, and also some of the efficiencies that have come out of preparing for the four-day week means that on a couple of occasions, managers have been able to dispense with those posts and either split the work across other areas. There are two of those posts, and as Councillor Williams says, there's also new posts that weren't vacant when we did the original piece of work, and there are two of those posts. If we were to only count the savings on those nine posts, I think that the savings are about 590,000, so they'd be higher, but we have got these two new posts that have come online, which reduces that level of savings down to about 550,000. We are accounting for them. I'm sure there'll be some other scenarios that come up before the end of the process that we'll have to account for as well, but so far those are the three scenarios that we've encountered. In terms of the second question about the sickness absence days, Helen, is that something that you can respond to? I'm happy to respond, but I don't have the information to hand in terms of how that's calculated, so I'll go back and clarify that point. Thank you. Are there any questions from members on the report before I come to Councillor Heather Williams' comments? Just on these nine posts, the hard fill posts, obviously the organisation is intending to cut the amount of officers by 20%, is that something like that? There's going to be over the next few years, so we're looking to reduce, not via redundancies, but by phasing people out, is my understanding, although inevitably staff will be made redundant if you want to get rid of that many. These nine fill posts, so they post that will carry on past that period, or are they short term and will be making these people redundant? There is no target for reductions. We are looking to be efficient and we're doing service reviews, and while we do service reviews, we will be looking at services and we will be looking to see where the post can be reduced, but there isn't a target of 20%, a fixed target at all. The service review for planning has been running for some time, and most of these are posts in planning. It's difficult to say, because I can't predict exactly what will come, but I don't believe there's any intention to reduce the number of planners, certainly in the planning department. Members were obviously being asked to note this report. Did you have another question? Yes, just that in the budget papers that have been forecast, it is about 20% saving on salary. Any other questions? Members? Our role is to note this report. Can I take it that we've noted this report? Agreed. Again, I'd like to thank officers for pulling the report together. I'm particularly interested, going back to the sick days, when we look at how staff are being and health is affected by the new ways of working, and the model of that as well. So, thank you very much. So, we just move on, Members, to the date of our next meeting, which is Thursday 9 November. Can I just confirm the start time of that meeting? Is it 10 o'clock? 10 o'clock? So it's back to Thursday, Thursday 9 November, at 10 o'clock. Thank you.