It looks like you're having connection troubles. Reconnect now.
01/13/2021 13:56:22
31c3-talk-6397 Latest text of pad 31c3-talk-6397 Saved Jan 13, 2021 |
Hallo Du!
Bevor du loslegst den Talk zu transkribieren, sieh dir bitte noch einmal unseren Style Guide an: https://wiki.c3subtitles.de/de:styleguide. Solltest du Fragen haben, dann kannst du uns gerne direkt fragen oder unter https://webirc.hackint.org/#irc://hackint.org/#subtitles oder https://rocket.events.ccc.de/channel/subtitles erreichen.
Bitte vergiss nicht deinen Fortschritt im Fortschrittsbalken auf der Seite des Talks einzutragen.
Vielen Dank für dein Engagement!
Hey you!
Prior to transcribing, please look at your style guide: https://wiki.c3subtitles.de/en:styleguide. If you have some questions you can either ask us personally or write us at https://webirc.hackint.org/#irc://hackint.org/#subtitles or https://rocket.events.ccc.de/channel/subtitles .
Please don't forget to mark your progress in the progress bar at the talk's website.
Thank you very much for your commitment!
======================================================================
Thanks. Good afternoon. I hope everyone's had a great Congress. We're getting quite close to the end and it's been a lot of fun for me and it's great to be here. I'm s I'm from the Electronic Frontier Foundation, and I'm here to talk about a project that we've been working on actually for about three years in some secrecy. And it's really excellent to have this public and to be able to talk about it and to be able to share our ideas and our plans with everyone. So there are a lot of acronyms in this space and this is really only a tiny selection. And I just wanted to start by letting people know if there are people who don't work with certificates or with Web encryption a lot the really most fundamental acronyms that occur the most. So the protocol that we used to use as a security layer on top of TCP was called the SSL when it was invented. The proper name today is TLS. That refers to the same protocol and it's more recent versions. And of course, when you put that on top of your underneath your Web connection, you've got HTP. We've also got the format of the certificates for exchanging the public keys that we use in these connections. That's called X five or nine. The infrastructure that that forms the basis of is called the public key infrastructure or pecky and the entities that. Publish that sign, the certificates within the PKK are called certificate authorities or case there are many more acronyms out there, but I'll try not to use too many of them. So this is a technology for us as privacy advocates that is really fundamental. That's really important to them that we've been advocating for a long time and we started from a place where people had this sort of Web security folklore, that you need a secure connection to your website if the user is entering financial data like a credit card number. And that's really weird because credit card numbers are not really that sensitive. There are a lot of other things that are obviously much more sensitive than a credit
card number. But the folklore persisted for many, many years that that's what this technology is about. That's where this technology is needed, that you use it when you're accepting credit card numbers and otherwise not. And in the last few years, the Web community has said, OK, also, if the user is logging in, we need to protect the username and password. And OK, after the user has logged in, we need to protect the authentication cookie. So gradually there has been an expansion of the recognition that this technology is important. But I think we need to go much further than that. And I don't really think that I have to convince this audience of that. But I think we need to convince other audiences of this that we need a much stronger vision, that the things around us, our communications networks, are actually attacking us all the time on a large scale routinely, that these networks are untrustworthy and that we need to protect our communications against them for many reasons, for many threat models against many attackers in many different situations. And there isn't just one reason for that. There's a whole panoply of reasons why we ought to think of networks as untrustworthy and why we ought to think of network protocols as needing to protect communications against the networks. And plain HTP was never intended to protect communications against the network in any way. It's totally unsecured. The information is totally in the clear. The network operator, everyone along the path has the full ability to spy on everything that you do and to modify it and to inject things. So just to be concrete and this is just a quick representative sample, not the full set of reasons why we want secure connections. We've got issues like skyjacking and location tracking. So if you have a cookie, it might be an authentication cookie. It might just be a tracking cookie. If someone else can see that cookie, that cookie can be repurposed to steal your session, to impersonate you or just
to recognize that that's you. And we heard last year that governments noticed that and that there is a lot of infrastructure that's been created to say, OK, that cookie wasn't meant to be personally identifiable, but it is to us because we know who that person was. And therefore, whenever we see that cookie sent to that site, we know who that is. We know where that person is. We can recognize that device immediately. There are also software downloads. I was just hearing about a really popular tool for creating installation media for Linux systems. And you use this tool and you create bootable USB media. And I looked at how does it get the images for your installation media? And the answer is there's a hard coded list of 261 URLs from which ISO images can be downloaded. According to what operating system do you want to install? What version do you want to install? None of those 261 URLs is a secure origin. All of them are HTP or FTP with no checks on verification and no signature verification. So you're making installation media for your operating system and your tools are going out there and getting your operating system over a completely unauthenticated, completely insecure connection. And you're installing not necessarily what you wanted, but whatever your network operator wanted you to install. And that pattern is repeated over and over again with all kinds of software. People are downloading unauthenticated software and installing it and entrusting their computers and trusting all their communications to software every day. Reader privacy is another really significant one. So sometimes we hear from people who publish websites like newspapers, they say all of the content on our website is public. There is nothing secret on our Web site. We don't need it. Setpiece. The confidentiality of the sensitivity there, as with so many other sites, is not in the secrecy of the content, it's the sensitivity of the association of the reader with what the reader is choosing t
o read. Librarians understand this very well. Every book in the library, of course, is completely public. Anyone can walk in and read the contents of the book in the library. There is no attempt to say that this library books are secret, but the librarians understand it as a fundamental ethical responsibility to protect the association of the book with the reader, to protect the fact of who is reading what. Librarians have articulated this a long time ago, and website operators and publishers need to articulate this to everything on your website. May maybe public your readers have a really important privacy interest in the selection of what they read on your site. Another significant point is content based censorship built into networks, a lot of people are familiar with this through the Golden Shield Project in China, where if you access a website that mentions certain keywords, the Golden Shield will actually interrupt your connection to prevent you from reading about that topic. Unfortunately, more and more countries are building that kind of censorship infrastructure directly into their networks. And so we need as an anti censorship measure to prevent the network operators from being able to see what we're doing and what we're communicating about and with whom we're communicating online. And just recently, we've been hearing more and more about mobile carriers injecting headers and broadband carriers, injecting advertisements into people's Web connections. So your ISP will advertise to you by actually tampering with your Web connection and putting an ad banner in. Or your mobile carrier will say, I want to help sites track you. So I'm going to put in a header that shows who you are. So all of these forms of tampering and these skell all the way up from these commercial motives, of course, to government surveillance motive's where we heard last year at the Congress about governments creating massive infrastructure to actively inject content into people's Web conn
ections as a way of delivering malware, as a way of compromising people's devices. So it's a widespread tactic that a lot of people are interested in for a lot of reasons. So we need a vision of a secure web that can defend users against these things of really routine use of encryption. There are a lot of barriers to this. We've talked to a lot of website operators about why don't you use HD on your site? Why don't you have a secure connection to your site? And we hear a lot of things. And one is the traditional view that it's slow, that it makes it adds latency to the process of establishing a session when the user first connects to the site or that it puts a lot of demands on the CPU of the server. For some people who have a complicated server side configuration with load balancers, there are additional complexities about engineering considerations with key management. But the one that we hear over and over again most often. Is all about the difficulty and the cost of obtaining and keeping up to date and keeping accurate and keeping non expired, these certificates that you need in order to let the browser establish a secure connection to your site. And we've talked to people who are technically sophisticated, people who understand what a crypto key is and they understand what a Web server is and they understand what a digital certificate is and they understand why they need it. People who understand all of that still typically take an hour to actually go through the process and actually get and deploy the cert if it's not something that they do on a regular basis. Obviously, if it's something that you do every day or every week, you become more accustomed to it and more familiar with it and you can get faster at it. But we've heard over and over again from system administrators who only have to deal with this, say, once a year that they have to go and look up a recipe on some website about how do you get a cert. And they have to go through all of these steps, crea
ting a key, creating a certificate status request. They have to deal with the syntax of open SSL command line binary dash. No doubt some of you will appreciate that. Yeah, no doubt. All right. So this is this is a complex process that's really a deterrent to people. And, of course, there's a financial cost associated with it, too. And that's typically a financial cost per subject, domain names. And even then, of course, a year later, it's going to expire and all of your users are suddenly going to get a certain error or you're going to add some virtual hosts, some subdomains that you didn't think of at the time that you didn't include in the search. And users are going to get a certain error in their browsers when they go to those subdomains. And so there's a lot of complexity and there's a lot of purely administrative difficulty in keeping these things up to date, keeping these things deployed, remembering which cues are for which sites, which certs are for which sites. Where does that go in the Web server configuration, all of this complexity. We believe that overall this is the biggest barrier to adoption on the part of people who have an interest in making a secure Web site. And this is the barrier that we intend to address and eliminate. So we've created this project called Let's Encrypt, and this is a collaboration. And we started working with the University of Michigan on the idea. We started about three years ago working on the idea that there could and should be a completely automated certificate authority that can issue certificates to anyone quickly at no charge. And we worked on this project for a couple of years and we happened to learn that Mozilla was actually working on the same project in parallel. So fortunately, we were able to combine forces and be stronger and more effective together and have a single project among these three organizations to bring this vision into practice. And the vision is also that we should be better than the existing CERT
authorities, at least for the portion of the Certificate Authority space that we occupy in every way. We should be cheaper. We should be easier to use, we should be more convenient and we should be more secure. And for our launch, we have commercial partners, Akamai and Cisco. And I don't trust and thanks to them, it's going to be possible for us to have publicly trusted certificates that will be accepted by browsers. So just to be clear about that point, thanks, just to be clear about that point, this is the question that we got the most. Are users going to have to install something in their browser in order to accept your search? And the answer is no. The users browsers will trust our cert authority and its certificates out of the box. And for people who aren't familiar with the intermediate mechanism, a certificate authority can delegate its power to another CERT authority by issuing a certificate that says this other entity is also. And this is something that happens routinely on a large scale. We have another project called the SSL Observatory that showed that, in fact, there are hundreds of entities that have hundreds of names, that list of entities that have had this power delegated to them by certificate authorities. And in fact, normally when you get a certificate for an identity for a website, it's almost always signed by an intermediate certificate authority, not directly by a root certificate. Authority or authority will be cross signed by I then trust, meaning that trust will delegate to us this ability to be recognized as a certificate authority, which means that mainstream browsers will trust our certificates immediately. So within the Kyuki, there are various forms and levels of validation that the certificate authorities perform. They verify or confirm or validate different kinds of information, depending on what information they're going to put in the certificate, the lowest level of validation is domain validation in domain validation, the certif
icate authority says. I checked that the applicant, the person requesting the certificate controls this domain name. And in domain validation, the authority explicitly does not confirm who the applicant is. They explicitly don't say this is such and such an organization based on such and such a city, they say we don't know, but this applicant controls this domain name. There are other forms of validation that certificate authorities do in the UK, such as organizational validation and extended validation, where they do, in fact, say, we're going to go find out about the human being who requested the cert and we're going to put other contact information and other identity information in the search. So an advantage of domain validation is that since it refers to confirming control to validate and control of the domain name, we believe that we can replace the Certificate Authority with a very small shell script. OK, so actually, the industry has a lot of rules, so the Shell script may not be that small, but and it may actually be written and go, but, uh, we have to comply with all of these industry standards, right. As a condition of being a certificate authority. We have to actually go through and have an audit. We have to show what our procedural controls are. We have to show what our technical controls are. We have to show what our policies are. And so we're developing all of these aspects, but. The point that remains is that the process can be fully automated for the most common cases, it can be performed by machines. There doesn't need to be a human being in the loop. And so that's what we're going to do. So just to describe a little further how this works, you have your client this is kind of confusing, like with the ex Windows system, the server is the client, right? OK, you have your Web server, which is the let's encrypt client, which is connecting to the CERT authorities server, using an application that we expect will be bundled with the server operating syst
em or maybe offered by a hosting provider and they speak to each other, a protocol that we're developing called ACME, the Automated Certificate Management Environment, and they talk about the certificate issuance process and the steps that need to be performed. So to simplify the process a little bit, we can say the client says, I control these names and I want to search for them. And the server says, OK, in order to prove that you should do this. And the client says, all right, I've done so, here's the proof. And the server says, all right, here's the certificate, and in the coming case, it ought to be just about as simple as that. Army is Jason structured protocol that's being developed. It was primarily invented by our colleague Richard Barnes at Mozilla and it goes through each step in the process of issuing a search through DV. Just to talk briefly about the organizational aspect, we've incorporated, a California nonprofit corporation called the Internet Security Research Group, or ISG, which is the entity that will operate the Let's encrypt CIA. We're preparing for the audits and the other process, other processes that are required for the build out of ACA. And we're expecting to have the ability to issue certificates to the public around June of 2015. So what we have right now is a technology review. So you can get our code, you can contribute to our code, you can try out our code. But just to warn you, certificate's that you get with our code right now won't be publicly trusted at the present time. We can only issue test certificates, but we welcome people to experiment with our technology and try out our technology. I wanted to talk a little bit about this validation method that we've developed called device and I and we think that device, an eye is stronger in some ways than the mechanisms that a lot of TV guys are using today. The basic idea is that the verifier asks the applicant to post a certain self signed shirt containing certain information that the
verifier provides. The verifier then makes an appeals connection to the server of the applicant and checks that that self censored is actually present and actually contains the requested information. And if you have a live HSDPA site, this doesn't have to interfere with that site. You don't have to replace your cert with the sort of the site because we're using the same mechanism server name indication. So when we connect, we'll ask about a particular invalid domain name. And the self-defined search should be served in response to that request. It doesn't get served in response to other requests. So, again, if you have a live site, we won't interfere with your live site. It can keep working just as normal while we do this verification in parallel. And the bottom line of this is that it proves control of the Web server. It proves that you have the ability to reconfigure the Web server that's listening on that domain to the point of posting new certs. And we think this is a very strong validation method and we're expecting this to be the primary or a primary method of validation. Again, users don't have to worry about that very much because we're providing client software that handles all of this and we believe that client software is going to be very convenient. And that's really an essential part of this vision. We think it's going to be at most this difficult to get your cert and it ought to take. It ought to take less than a minute to get the cert and install it. So I want to show you a video. I want to show you an excerpt from a video that was prepared by my colleague, James Kastin from the University of Michigan, who's the primary author of the client application, and I'll try to narrate it and see if I can keep up with what James is saying in the video here. But this is just a demo of the client application as it existed a little while ago. So the idea is you might have a site and the site doesn't have it. So when people go to that site, they get an error, rig
ht? There's an invalid cert or there's no cert at all. So you have this let's encrypt application and you say Sudo, let's encrypt. This is a warning that the search that you get won't be publicly trusted, OK? It passes your Apache configuration and detects which virtual host you have and it offers to get you certs for all of the virtual hosts that you have. And then it says, OK, I'm generating a key, I'm generating a certificate request and I'm connecting to the server. And actually, while I was explaining that it got the cert and installed it, so it finished. And it actually it actually reconfigured a patsy and then it asks whether you want to redirect its GDP in that Apache configuration, virtual host to its GDP or not. Now, James is going to do this again, showing that if you know exactly what you want ahead of time, there's actually a non interactive mode where you can just say exactly what you want and then you won't be prompted interactively. So he's just saying sorry. Yeah. So he just wants to assert. For encryption example, demo, and it generated the key, generated the request, configured Apache to answer the device and I challenge received the challenge, got the cert, deployed it and reconfigured Apache with a V host that redirects the HTP to its GDP. So now if he reloads the HTP, Apache redirects to its. And so all of this is reliant, of course, on the ability of the client to pass and to write to the Apache configuration and the configuration files of other Web servers. And that's an ongoing effort that we're involved with to try to make this as convenient as possible for people, regardless of what server software they're using. I'm also working on a standalone version which will just get the cert and save it into a file. So if you have some application, some server that you want to install the search into, that's not supported by our software for automatic configuration, you can just get the cert and have it in a file in your directory and then you can d
o what you want with it. So we will have a standalone mode that doesn't require you to let our software edit your Web server configuration live. But when it does edit your Web server configuration, it has a very careful configuration file backup mechanism and check pointing and roback mechanism. So it's not going to change your configuration file and not give you a copy of how it was before, you know. And we care a lot about the security of the cert system. In fact, a lot of people working on this project are people who've done previous research and previous analysis about concerns about the safety of the Certificate Authority system and concerns about the safety and security of it. Yes, we're very well aware of the risks of mis issuance. We're very well aware of the concerns that certificate authorities could get tricked into issuing something that someone could try to legally compel them to issue a inaccurate cert, that someone could try to hack them and steal their key. All of these are concerns that are certainly very much on our mind and we're not trying to minimize them or sweep them under the rug. We think that CEOs have a big responsibility and we want to be very careful with that responsibility. We think that transparency is a really important part of this within the context of the existing system. And so we're likely to adopt something along the lines of Google's CERT transparency system, where all of the certs that are ever issued by the authority are published publicly, and where we can actually say that if the certificate has not been published publicly, it should not be accepted. And there are other mechanisms that we're looking at and talking about in terms of transparency, in terms of being able to say to people, why did we issue that search? What sites have we issued? What do they say? Um, we're also very interested in exploring ways that we can decline to issue things that there is some reason to believe that we shouldn't be issuing. And so one pol
icy that we're exploring is if there is a valid search already for a particular name that's still within its period of validity, we may say that we won't automatically issue a new search for that name unless the applicant can prove that they control the private key that's in the existing search. And so then we could say, OK, well, if there is some HSDPA site out there that's working fine right now, we're not just going to issue a search for that name to some stranger who comes along who doesn't control the property of that valid functioning HSDPA site. And there are other mechanisms that we can use where domains can say we don't want your to ever issue a search for our name and we can respect that request. So, again, we're very concerned about avoiding this issue and exploring technical means that we can use to mitigate the risks of mis issuance. We'd like to be really widely integrated so that this is a really routine thing that people can use conveniently and expect to have them to rely on. So we'd like to be in every server operating system. We'd like to be integrated with every Web server application. We'd like to be integrated with every hosting and application platforms. So we'd like to have a situation where when you sign up for a hosting provider, the hosting provider gives you a single click or maybe zero click mechanism where you'll get a valid search from us if you want one. And of course, our protocol is an open standard that's likely to be submitted to standardization at IETF and you can implement the protocol in your own software. You don't need to use our software to request or obtain a cert from RCA. And so if you are or work with a hosting provider and you don't like our client or it doesn't fit your architecture, you can write your own client. Right. You can do what you like. You don't need to directly coordinate with us. You don't need a contractual relationship with us. You can just get these certs from us by speaking our protocol to us. And we h
ope that people will do that. If you are an organization that finds this valuable and wants to make sure that it can exist, we welcome financial sponsorship. But that's absolutely not a condition or a requirement of integrating with us in any way. It's just something that you can do to support Internet security. So that's actually about it, I wanted to acknowledge these are the folks who've been working on the original technical concept with us from Mozilla, from EFF friend from the University of Michigan. And of course, as the project has developed, we now have even more colleagues from these organizations and even some volunteers from outside who are working on developing other aspects of the CIA and other aspects of the technology. So it's a great collaboration. You can go take a look at our code, help develop it, help test it, help critique it. Um, we'd be very grateful for public involvement. So thanks very much. And I think we have actually quite a bit of time for questions, because I think that was only half an hour, but I know people tend to have questions about this project, so I'm very happy to hear them. So I thought you would speak a little bit longer. Yeah, but thank you. And I think that actually a lot of questions. So maybe it's a good thing that you have left or some time for this. So is there a question from the Internet? OK, let me start with this. OK, first first question, does this only work with Apache? So it depends what you mean by work with us. So in terms of the ability to do what we see in the video where you run the program and it gets the cert and then configures the cert on your website automatically, in the current version of our software, Apache is the only thing that we've integrated with yet in that way. And so today you would only be able to have that automated experience with Apache. We're actively working on integrating with Engine X and of course, we want to integrate with every other Web server. So we welcome other people to hel
p write that integration. There's no technical reason that it can't work with any and every Web server. It just requires us to write the code that deals with reconfiguring the Web server in an appropriate way. And that code, unfortunately, will be different for each and every Web server application. OK, before we go further, I see that we are sitting right at the moment, but we have learned that people try to stand up and go out to the kitchen. If you need to do so, please be quiet and don't speak. And we will continue with succession. I think I start with I don't know who was first. I think I go one. Yeah, that's you. Yeah. OK, there are several questions. The first one, is there a possibility to revoke a certificate and what bring all the other commercial theories about your work on. I'm actually sorry that I cut off the demo video so quickly, maybe I'll put that back on while talking about this, because the next thing that happens in the demo video is let's encrypt dash revoke. And it demonstrates revocation, which has actually already been implemented. Revocation is actually just about as quick as issuance. In fact, it may be faster because you don't have to test, uh, you just have to prove cryptographic control of the name of the subject's key and then you can revoke. So, yes, revocation is already implemented and is, of course, a very important part of the public key infrastructure. And I don't think that we've heard directly from any of the other case, I saw that one person from one of the other CEOs posted on a public mailing list when this was first announced, something like, um, well, I assume they're going to comply with all the industry rules. Right. Um, and so far, that's the only comment that I've heard from others. Yes. OK, well then I think to. Thanks. Great stuff, I really look forward to this ruling. What are the rules of the other partners, Akamai and Cisco, in this work? I think that their main role at the outset is providing financial sponsorshi
p because they think this is important. I'm hoping that they'll find it technically useful as a thing that will help their customers, but their initial role is just allowing it to happen financially. Great. More people should do that than the fall. Um, can I issue a certificate that's only valid for a few days so I could forego the entire vacation mess and do it that way and issue new certificate every few days? So we have a lot of interest in the proposals for so-called short lived certificates, where some people view that as an alternative to XP. And I'm sorry to throw out another acronym that's not in the chart, but there is a lot of difficulty about how in practice browsers should check whether certificates that have been issued are still valid and a mechanism was created for that. That doesn't work very well. Um, is that an attacker can defeat, uh, and so an alternative might be issuing certificates that have a very short period of validity and that might be much more convenient, relatively with our technology, because we have the ability to install the new certificate into the configuration on a regular basis. We would have the ability to provide automated renewal and automated installation and updating of the certificate. So I think that's something that could be achieved more easily. We have not finished making policy decisions about how or whether short lived certificates will be used in our system. So I can't actually answer the question except to say it's something that we find quite interesting. And then there's another question from the Internet. Yeah. Is there a plan to address uses for certificates other than titles such as SS Age certificates to enable peak usage with S.H.? I don't think that we'll be able to do that before we address the primary case with the webpage. I, I think that if this model proves to work well, as we think it will, then I Asaji would be very interested in figuring out whether there are other parts of cryptographic infrastruct
ure that we can help provide for the Internet. I think this case is going to be our first test case and this is where we're starting. When we go to the three, not sure if you know that currently World Wide Web consortium, technical architecture group, so the tax preparers publishing the finding about ETPs recommending it, do you find it useful to document it? And if there's already some collaboration about what to include in such note? We're really grateful to the TFG for making that recommendation. We think they are totally correct and very timely and not sure what else to say. But I appreciate that they said what they said. And I appreciate that a lot of people in the Internet standards community are really starting to say that cryptography is a fundamental, essential part of Internet standards and technology standards. And it's not that you design something and then you make the optional crypto version. A few years later, the crypto and the privacy features and the security features should be a part of the network protocols and the communications protocols from the beginning. Yeah. I think people here agree to this, OK, then I think the six. First, thanks again for the project I'm really happy about. So with this first word and also support certificates for non web like EXPE, SMTP or whatever. Yeah, so we've had some discussions about that. Um, it appears that right now in most Tillawi implementations, the same certificate will be accepted for any application. In other words, the subject entity is just a common name for the domain name and is not explicitly bound to a specific protocol or limited to a specific protocol. Maybe it should be according to some security arguments, but it's not. And so you have the ability to take a certificate that was issued for a Web server in some sense, if you want to think of it that way and use it for an exemption for use it for a mail server. And we expect that people will be able to do that. If someone wants to write a patch t
hat actually installs it in other servers that you have on your system, that would be useful functionality. I think a common case for people who only run something like an exemplar server is that they would run the standalone client, which would temporarily start a listening process. Listening on Port 443, the CIA would perform the validation with Port 443 and issue the CERT and then the cert would be saved as a file, which the system administrator could then install in another service. But again, if people want to help make that process more automated, we'd love to have that help. OK, then the five. OK, thanks for the talk. Do you plan to support wild card and multi domain name certificates? So for multi domain name. Yes, we support that right now and it works great. You just request all the names that you want in the server and it validates all of them. And we actually have some additional features. For people who expect to have to reissue the search with more names or fewer names in the future, there's a technical way to avoid repeating the validation for each name, every time you make changes to the search. Wild cards are a more difficult case. We don't really know how to use the validation mechanisms that we have now to perform a validation that would be meaningful and appropriate for issuing a wild card cert. It's a question that's come up quite a bit, and I think that the answer is right now we don't know how to do it. And so right now we are not going to do it. And if someone wants to propose a mechanism through which we could safely issue wild card certs, our board of directors would be willing to consider that mechanism. One thing that one person said at a prior talk about that is that if we can reissue a certain automatically in less than one minute with a different selection of names, perhaps the argument or the necessity for wild card service decreases. If you say, oh, I have a new virtual host. Well, that's all right. I'll just take 30 seconds and add
that to my cert. OK, then the question from the Internet. Are you aware that Tara Rescorla coauthored a standard that contained and a back door? So I'm definitely aware of that report, and I don't know a lot about the details of that, but Eric is a very active person. So the reason that someone is asking me about this is probably that Eric is someone, I think, on this slide, who's one of our colleagues who's working directly on this project with us. And Eric is someone who's very active in Internet standards, is the editor of The Standard and the chair of the Task Working Group, and has a lot of experience with all areas of Internet standardization. So I don't know the circumstances surrounding that incident, but my impression is that Eric was asked to edit that document as a result of his role as the chair of the Task Working Group, and not because he thought that that technology was a technology that he personally recommended that everyone use as much as other people working in Internet standardization have ended up with their names as editors of a lot of things like John Postell, who didn't personally invent each and every standard but was called upon to edit them and to issue them. Then the phone. How does your effort relate to using certificates from DNS, as in DAINE, and what do you think about that? Is that something that might come into play in a couple of years? Maybe so. A lot of people have been interested in putting cryptographic using DNS and there are a lot of mechanisms for that. There are different schools of thought about whether it would make sense to replace certificate authority issuance with. Intense SEC delivered keys or, um, whether you would use it sort of to limit whether you use it as an alternative or whether you use it as an additional mechanism to confirm the information in the search. Um. I mean, I guess the answer is that we don't have a specific technical plan about how that relates to our work, and it's obviously an important develop
ment. Certainly if there are defense mechanisms that are relevant to issuance decisions, then we ought to know about them and we ought to take account of them, as I say. Then the question from to so thank you for this work, I really like it fully automated systems have a tendency to feel badly and well. You've taken out two of the non automated parts of CERT issuance. So the human interaction and the financial commitment, do you feel confident that you've prevented any bad failures? So I think different people envision different failure modes, I mean, some people envision a failure mode like a private key compromise of the CIA and then some people envision that failure mode, like someone succeeds in obtaining issuance. Um, I think that existing DVE series run the risk of mis issuance if someone is able to compromise the site. Because someone who's able to compromise a seat can perform the D.V. verification steps as if that person were the legitimate operator of the site. And so there is a risk of mis issuance there even today, right? I think that we are confident that. We won't make that kind of risk systematically worse, the CIA system always has the weakest link issue. If you can compromise any CIA, you can get that CIA to miss issue for any name, even if it's entities that have had no prior relationship whatsoever, as in the Senate, are compromised. For example, there was no prior relationship with Google, but they were able to issue for Google. So there's this really fundamental weakest link issue. So I think what we can say is that with respect to the revalidation, we don't think that there is a way in which our design makes things any worse. We think that our validation and our transparency is stronger than existing Devco. Then from the fall, you're already removing the hazards for getting the cert and deploying it and so on. And would you please also remove the hazards for creating the debris records and maybe automatically of some flag, just create the recor
d, which somebody can copy to his name server configuration? I think that would be very valuable. Um, it's often not the same server, the like the Web server and the DNS server. And so the I guess you're just suggesting creating the configuration that someone might then import to another machine. So I think that would be great and I would welcome someone writing a patch for that. Then again, from the Internet, is there a limit of requested sign certificates per domain or limit? What's that a limit of? Requested sign certificates per domain. Well, I don't know if you can ask for clarification back to the person or not, but is the question like how many times you can ask for a new certificate related to a particular domain or in a time frame? So. I don't think that we have any policy developed about that right now. Then the six. Do you think that the CIA did you think that Sharat horses were trying to idea of Africa and gift certificates for free to their users or. Sorry, I didn't understand the beginning of the question that who would do that share horses like one and one are? Oh, they shared hosting providers. Yes, yes. We would definitely really like that. And we would consider it a very appropriate and desirable use of our services if those companies would integrate with us. And we would love to have conversations with any and all of them or second best. We'd love to be surprised that when we launch, all of them have actually already written it and it already works. So the first best case is that they tell us the second best case is that we launch and then we find out that people go and get a shared hosting account and they got a certain from Let's encrypt, looks like someone integrated. So I see that you're wondering what we have to wait. Um, OK. It's a six. OK, then the five things, first of all, yes, you can use Web services certificates for mail service. I'm doing that with DOT SSL certificates. And then my first question is, how does the long run finances loo
k like? For example, when are you going to accept private donations? And the second question is, will you document and publish the infrastructure this year? So the second question, I'm not sure which parts of the infrastructure will be publicly documented, the certificate authority code itself. Or at least a candidate version written in gold has just been published last week on our GitHub account, so if you look at this GitHub URL, you can find in some sense the code itself. There are obviously other parts of the CIA infrastructure, such as network configuration and data center configuration and so on. And I'm not sure which of those parts will or won't be published when they're finalized. Those parts are not not decided yet. The other question, I guess, was about the long term finances. And so we really encourage people, if you. Are an individual or an organization that cares about this, um, we welcome people to sponsor us and become financial partners. As you alluded to, we don't have a mechanism for individuals to donate right now. And I think that that's something that's likely to appear after the US government decides on our tax status because that determination is still pending. OK, can we have, again, a question from the Internet? Can I issue a search for a dot onion domain? That's a great question. I just spent a long time at ATF in Honolulu talking to people about that question and we didn't answer it. And there are a lot of folks talking about that on the browser forum, uh, mailing list. So I find that question absolutely fascinating and I don't know the answer. And then the three. So did you plan to include multiple networks views into the verification of the clan certificate, for example, when you have some DNS cache poisoning our local network attacks? Yes, so just to restate the threat, if someone is applying for a cert and is able to compromise part of the DNS or part of the routing infrastructure, it would be possible to redirect connections to a fak
e version of a site and then the verification would be performed with the fake version instead of the true version. And so one possible mitigation for that is to perform the verifications repeatedly from multiple locations on the Internet so that it's more difficult to use a single localized routing attack or a single localized DNS attack to cause the validations to validate something that's fake. And yes, we do plan to do that. We had an earlier proof of concept version which used Tor to perform multiple validations so it would perform one directly and then one or two via tor via different exit nodes that were located in different places. I don't know whether or not we'll use Tor as a part of the validations in the future, but multiple validation is definitely an intended part of our design for exactly that reason. And then the one do you see that there is some threat against your project, considering that infrastructure to people and also your organization is located in the United States? I think that actually about eight people have asked me that. If the Congress already had, I welcome the question. It's a very common question and a very common concern. You know, there's a lot of mistrust for the US government and the US legal authorities, probably deservedly. And I think one answer is that every certificate authority is located in and operates in some jurisdiction. And there are many reasons to be concerned about each of those jurisdictions. There is a trusted certificate authority in the People's Republic of China that's operated by a Chinese government linked entity. In fact, we made a chart and we found that there are certificate authorities operated according to their self-description, in approximately 50 different national jurisdictions, and each of those authorities can issue search for any name. I know that the United States is one that people have a special concern about, and it's the one where we're going to be located. We're not going to be located in
all 50 of those jurisdictions. We're going to be located in the United States. I think there are basically three reasons why people might feel that this isn't as bad as they first fear. One is that the project, perhaps unlike some other cert authorities in the United States, is run by a group of privacy and anti surveillance advocates and activists, some of whom work in a law firm with over a dozen attorneys who are very interested in directly fighting the government in court over surveillance authorities and powers. And who would I think, uh, one of them can correct me if I'm wrong, but. Volcom interesting opportunities to go to court to. Yeah. So one of our attorneys confirmed we would welcome the opportunity to go to court to challenge the government's ability to compel us to Massachusetts and so on. And we may have more enthusiasm about that kind of fight than existing CERT authorities in the United States. I didn't mean to miss issuing of certificates or something. I rather meant to terminate your operation in some way. Oh, I'm sorry. I just assumed Miss Issuance because that was the threat that other people had mentioned. I think that operating a certificate authority seems to be lawful and a lot of people do it. And there seems to be some it's a common line of business for people to be in. And I'm not aware of legal problems that have encountered in terms of their right to exist and to discuss. Then the two. Thank you. Do you have a recommendation on how to lobby shared hosting providers to pick up your service quickly and cheap? That's an interesting question. I'm hoping that general competition and awareness helps with that, that some large provider may say, all right, well, now this is, uh, free or just one percent extra or something as a result of this service. And then others may say, all right, I guess we've got to do that, too. I have certainly spoken to one large hosting provider that was very interested in integrating our service. So I think that the
re is a likelihood that that will happen. And I had a suggestion from someone at the Congress to try to attend a major hosting conference that happens in Europe in the spring. And so I'm hoping that will attend a hosting conference and try to spread the word there. Do you think a letter or email template for a request to the shared hosting providers might help, as a lot of them equal looking letters tuning in may help? So, I mean, I would prefer in this context to start with approaches through individual engineers rather than having sort of a petition, because I think it is something that they'll start by viewing as a commercial and a technical proposition. And I think we can try to approach them at an organizational level. And then I think that competition will help quite a bit with that. Then the fall, um, I wanted to ask if you have maybe for about working together with the existing CIA is like, for example, Cassard, because if I look at CIA sort of certificate or class one, certification is exactly the same what you are actually currently doing and maybe with your scripts you are a little bit advanced, but why not work together? Um, so. I really appreciate the search school and other people's goal of making the certification infrastructure a free service that's equally available to everyone. I think that's exactly the right call and that's something that we need. And that's a reason that we're doing this project. Um, and I would welcome people who want to cooperate with us in some way to get in touch. I think CSIRO in particular has a particular model and particular infrastructure that is different in some ways from what we're doing, although similar in some ways and similar in terms of goals. But I think basically we've developed a very specific path that we want to get done quickly and start issuing quickly. Um, so we're pursuing the creation of this new idea because we think that that's a fast way to reach the goal of issuing publicly trusted search to the pu
blic. But if there are folks who have experience in this area through case or otherwise, who have proposals or ideas, whether technical proposals or proposals for collaboration, they should definitely get in touch with us. Well, uh. Could I say something more? Oh, come on, hear me. Yeah, OK, good. Now, um, well, as far Myers, as far as I are currently aware of the new system at that is currently being written and there are quite a few changes in there and that will be more or less, I'd say, in a few parts of it, and that one could maybe just put it all together to one project. Well, I think we should definitely talk about it. OK, then the six. I have two questions, the first question is, when you reissue certificates or add extra domains to these certificates, does that include changing the private key? That's the first question. Well, I don't. I think I've ever thought about that. I mean, there are other people who are working on the protocol who presumably have thought about that. Um, the common case that we were thinking of for changing the certificates without repeating all of the validation is keeping the same private key and adding or removing names. And in that case, we think we can skip performing the validation of control of names that have already been validated. If you can prove continuity that you're the same entity that contacted us before that we did that validation with changing the private key might turn out to be a big enough change that we would want to repeat the validation to avoid the risk that it's actually a completely different entity coming in from scratch. OK, so sorry, I have a second question that ties into that if you are continually creating new certificates with the same private key, the revocation process becomes more complicated because you have to revoke every single previous certificate that was issued with that private key if the private keys is compromised. So that leads into my question of how are you planning to maintain a scal
able available revocations system where OSPI has low latency and chorales? There's there's a lot of traffic that comes along with hosting these services. How do you plan on building a network infrastructure that's able to withstand that in an affordable way? So with apologies to my colleagues, I'm really glad that I'm not responsible for creating the ISP responder because I really don't envy people who have to create EXPE responder's. Having said that, we're we know that we have to have a lot of hosting capacity to serve HSP. We're going to have to estimate what that will be and figure out where we can get it. And I think, you know, when you make changes, presumably when we issue a new cert will automatically revoke the old one. But that does indeed create a lot of potential ASSP traffic and a lot of data. So I agree that it's a large scale challenge, and I hope that my colleagues find a great solution to scaling it. OK, the last question, because the time is up and you had to have an hour for questions. Answers is from the Internet. Have you guys been working on any proposals for restricting a particular certificate authority to a particular top level domain? For example, a European SEIA, only four domains in Europe. So I think in terms of the threat, that probably would have been a good measure to have in the certificate authority system at the outset and to more closely tie the people who issue the domain names in the first place to the cryptographic distribution process, because as people point out, they're the ones we treat as authoritative for the question of who controls or who owns the name. And so if they're the ones who know who owns the name, they're the ones who can tell whether someone who wants to post a public key is, in fact, the owner or not the owner. Having said that, that's not the system that got created back in the 90s, the system that got created back in the 90s, although it has extensions that do allow you to create name constraints by defaul
t, has no name constraints at all. And so I don't think we see a direct reason or a direct path for us to create or implement such name constraints. Um, for the the general question of preventing issuance for a particular name, um, on the part of the name holder as opposed to on the part of the registrar, there is a mechanism called CAA, which I think is quite interesting and which we may implement, which is one mechanism where you can say I only want this year to issue certs for my domain name. I don't want any other to issue them. That's something that the individual domain name Holder has to do. But it could be a useful security mechanism, at least at the level of preventing misjudgments, attacks. OK, that was successful and I think is. Yes, forget the.
