 Thank you. Hello. Okay. Yeah, so thanks Pedro and thanks very much for the invitation. So yes, in this talk, I intend to present some ongoing research on TLS and HTTPS and the number of project is double address. So I first have a few slides describing broadly what you are trying to do then you have a demo. They will go into more details about cryptographic algorithms and crypto protocols. So needless to say HTTPS and TLS are critical. So the the actuality there is that in fact more and more people are consolidating around fewer protocols. So doing your own protocol is considered an idea. So everyone ends up using standardized protocols and TLS being the easier to use. It's maybe running something like trillions of connections every few days. In fact, most of the Internet traffic is now encrypted using TLS and it will become a mandatory with HTTPS2 and moreover, there are lots of other things like VPNs, voice, emails protected by TLS. So it's quite a complex system at the same time from especially from a verification view point. It has the big advantage of being relatively small. So there is some cryptography, some protocol, some PKI and in the protocols there are crypto protocols and application-level protocols, but nonetheless, we can hope to implement it all in tens of thousands of lines of high-level programming languages, which makes it, we hope, a reasonable target for full verification, which will not be the case for a SEO browser or a full-fledged operating system. It's also quite as is well-known quite broken and in fact it has been, we have seen a succession of attacks, discoveries, improvements and fixes over the last 20 years and the issues range from most practical but boring ones like buffer overruns or failure of memory safety to implementation design issues such as problems in state machines, so logical flaws in implementation to misunderstanding about how the different bits fit together and it must not be the case for the PKI. There are also some specific issues due to cryptography with weak primitives or primitives that used to be okay and now are broken and plenty of such channels. So more fundamentally, one of the big issues of the ecosystem is that the security is quite often implicit. So there is not a clear well-agreed precise notion of security for TLS or HTTPS. And maybe as a result of that, APIs tend to be low-level and quite dangerous and even in some cases we discovered some flaws in the standard, so for the triple uncheck attack for example, if you implemented the standard you are subject to the attack. So the practical situation is that we have mainstream limitations that get patched regularly. So if you look in last year for OpenSSL, there were 33 CVs resulting in two patches. So it's a few amounts. So it's reasonably safe to say that OpenSSL has never been safe so far. There was always some open attacks in there and well, we should be able to do better. So what we propose to do is to rebuild a stack, HTTPS stack, one component at a time, with strong machine checks of safety and security for every component. So at the same time we are, and that's maybe half of the project, which I'm not going to talk much about it today, but we are developing verification tools, programming language and compilers who support that effort and by co-developing the tool, we are hoping to improve both to the point where we can verify something at this scale. Finally, and in contrast, maybe to some of the work building reference implementation, we would like our components to be usable. So we are aiming for things that are verified, formally verified, but also reasonably engineering, not to demanding in terms of resources and reasonably fast so that they constitute a reasonable alternative, not just something formally verified. So we have a composite team involving essentially four labs, so three labs at Microsoft Research and one in Paris at Inria, with a mix of systems, security, cryptography and programming and verification. So one question you may ask is why are we still looking at that problem? In a sense, TLS is just a secure channel so that has been well-studied and solved maybe a decade ago, maybe a bit more and so something to keep in mind in the talk and that I tried to illustrate as we go and is that there is a cryptographic viewpoint to the protocol, but they are also quite different and conflicting viewpoints and the lack of communication and synchronization between those viewpoints has led to many persistent difficulties. So let's start with a cryptographic viewpoint first. So we have and that's essential for the design, but we get papers, typically, that look at one aspect of the protocol at a time and to get something readable, simple and tractable, they tend to ignore all the other details, have another relevant for that particular property. And so we get something that is nice and simple and intelligible, where you can actually convince yourself by wrong that the proofs are correct. But they do not compose and if you try to put all the components together and get all the security properties, there will be lots of details that are going to get stuck in there and in our experience in particular, we expected we were able to reuse existing cryptographic results, paper results in the work and in many cases we could reuse the ideas and the methods and the proof techniques, but not quite the results because we need slightly stronger assumptions or an extra oracle or some cryptographic agility or some joint assumptions in places. So in any cases, what is pointed to as the reference for the design is not quite good enough to check even the cryptographic protocol as standardized and used. At the other end you have the RFCs and RFCs are specifications that they are, it's English, so it's very informal and moreover they focus on the wire format. So the main point is interoperability, not quite security and things are getting better, but still security is considered, it's not specified. So you have a section that says security considerations and they discuss things to be careful about or to think about when you implement it or when you use it, but it's very far from a precise definition of what you should verify as a security property. Then we have the viewpoint of the implementer, where the main issue is typically not cryptographic security, but more mundane issues like memory safety and integration and how to handle graceful errors and also how to have a system that can be that is operationally secure, that involves a lot of care about being able to upgrade and to maintain the system and to evolve it over time. And finally, we have the user of the protocol who tries to use those standards and implementations, but because security is loosely specified and because the APIs are quite low level, in many cases they end up misusing or misconfiguring the system. So they were a very nice paper by Vitaly Shmetikov and his colleagues a couple of years ago showing that 80% of people using TIS libraries were getting the configuration wrong, so that any certificate would be considered as valid no matter what the subject was in that certificate. So it's very superficial, but it validates 80% of the deployment. It's much more serious than cryptographic vulnerability will be. So as you may know, we have been working on TLS for a bit longer. So we started with me TLS in 2013. And there the goal was a bit different. So we really wanted to understand why the protocol was secure and to build a reference implementation, not something directly usable. So we tested the reliability, but certainly that performance. And it was only up to TLS 1.3 and there were quite a few limitations. So we were excluding the actual cryptographic primitives and construction. So we were really sticking to the letter of the RFC. Also, the proof was machine supported, but not fully mechanized. So we had for the main cryptographic argument for the handshake and for the record layer, we had paper proofs. And in some cases, the synchronization between the two was quite delicate. And finally, it was good enough to test it in particular use it to look for attacks systematically. And that was one of the way we found most of the state machine attacks. But it was not good enough to be deployed. And in a sense, developing a verification and using only to find bugs elsewhere is a bit disappointing. So this time we want to get the tools right so that we can actually deploy what we are trying to build and verify. So the way it works is we are consolidating a report on a new programming tool chain based on the programming language that is oriented for verification. And that is an F star. So it's a language I'm going to review a flavor of that language later on. And we use that language as the one language for coding everything. So we have the implementation code, including the level code. You also have the specifications. We have security definitions. We have cryptographic games. We have cryptographic constructions. And you also have the proofs. And so everything is packaged together, can be verified together. And then from that, we can conduct verification. And once we are satisfied that everything that is specified has been checked, we can erase the proofs and the specification and just extract lower level code. So we get to CC++, but we will not be able to conduct the proof and the modular reasoning directly at the level of C++ and sort of. So nonetheless, we realize that CC++ is unavoidable if you want to integrate with the ecosystem. So we actually spent a lot of time generating high quality readable code because we expect people to be able to conduct independent reviews at that level even if they don't understand the formalism we have. And at a lower level, we interrupt with the rest of the system. And so we have some testing. We have been running interobality for a few years on TLS-1.3, for example. But in summary and before we switch to the demo, what we build is a single model plus implementation with formal support. And we get two things out of it. One of them is that we can validate the design because we take an informal design and we formalize it as something very detailed, which is an executable spec in a sense. And at the same time, we get a concrete implementation where we can work in performance and get the security properties that we get on the design done to the implementation of the protocol. Okay, so I have a brief demo. I hope it works. I'm demoing two components of the system. So METLS, which is our implementation of the TLS protocol plus all the cryptography, the cryptographic primitive that are used to run TLS as a cryptographic provider. And so for this demo, I'm showing an integration in Internet Explorer. So we redirected calls from Internet Explorer so that METLS will be used instead of the default cryptographic provider so that we can experiment with TLS 1.3 and zero RTT using GE as a user interface. And as a server, we picked NGNICs, which is one of the fastest web servers. And similarly, we replaced its cryptographic component that usually is open SSL with the one component with verify TLS and verify crypto. And we also added support for tickets so that we can experiment early with tickets and resumptions for TLS 1.3. So here is the demo. So it's not okay. I'm not going to detail that too much, but it's Internet Explorer running with the debugger attached so that we can monitor the code to METLS underneath. And I'm using that because otherwise it will just work as usually just display pages. So if you load this page with lots of pictures, it's going to open many connections and do the multiplexing on top of that. And except for the debug information, you wouldn't be able to tell we are using or implementation or another. It's just fast enough at this level. So you can see at the top that, okay, if you look at the window below, if you are looking, we can see that we actually try to negotiate TLS 1.3. But in that case, we fail to negotiate 1.3 with our server, which is also implementing TLS 1.3. So that's our test server that has been around for experimenting with TLS 1.3 running NGX in the background. And so here we end up with 1.2. And the reason we do is because my client is using the 20th draft of the standard and the server is using the 21st draft of the standard. So I realized that this morning. So to show the actual zero RTT, I'm going to use the command line demo. So here I'm running OpenSSL as a client. And I open a TLS 1.3 connection to my NGX server running Meet TLS. And the first session establishes a ticket. And now I can, if I can find the right command line, yes. So I can then use the ticket that is established to open a fast connection. And there we can see that early data was accepted. So the very first request that was sending the first message on the network was processed as part of zero RTT. Because both ends could reuse the information in the ticket to establish keys without any additional entries. Okay, so that was the demo. That's quite minimalistic. So the next, what I want to show is what we do for verifying implementation of cryptographic algorithms. So that's what your level programming and functional properties of algorithm. And as a starting point, I wanted to show some typical code that you can find in OpenSSL. So that's a code for implementing. I think it's a too. And it's a mix of assembly and parallel, which is not quite what you would use for verification. And the reason is, of course, that people want to get the maximum speed out of it. So in OpenSSL, there is code specializations and different assembly for something like 50 different platforms. And it means you're using these kind of scripts, and it also means introducing bugs from time to time. So I'm going to show you what we do instead for one simple algorithm. So that's Poly 13.05, which is one of the fast, modern, one-time Macs that is used in TLS for authentication. So it's a multiplicative Mac. So it works by encoding your data into a polynomial, into the coefficient of a polynomial. Then you evaluate it at a random point and you mask the result. And it's quite secure. So, and those mathematical specifications are very simple. It fits in a couple of lines, as you will see. The implementation is more complex because it plays lots of tricks to go fast. So it represents numbers using multiple limbs, and it tries to save on the number of reductions and carry propagations that you do using different tricks. So it means that at the same time we can get a specification in F-star. So that's the first bit of F-star that I'm going to show today that fits in this screen. So it's literally a couple of lines. While we can also have an implementation that is optimized on that text together with the proof of a few thousand lines of code. And provided you understand and you agree with the specification, you don't have to look at the code. The verification is going to check that this is what is implemented by this optimized code for the platform or it's going to return to you an error at compile time. So let's look at the spec. So that's F-star syntax. So we define our prime. We define an element as a natural number that is smaller than the prime. Then we define addition and multiplications in that field. Then we have a noncoding of word. And then we have a recursive function that just evaluates the polynomial recursively. And that's what we are going to use and mask in the protocol. So why bother? Well, Poly 13.05 is relatively new. So new implementations are being added to existing implementations. And just in last year, there were three bugs, including one vulnerability report in OpenSSL, in the implementation of that particular feature. So one of them is a buffer overrun, which is boring but very dangerous. The others are just incorrect results due in particular to subtleties in the assembly code to do carry propagation. So instead, we are in F-star. But we want to have full control over the code that will generate. So in fact, we design a subset of F-star that is intuitively the intersection of F-star and C so that we get to a program at a low level and link with assembly code if need be, but still benefit from the full verification framework. And of course, we build a compiler so that once we have written and verified something in F-star, we can securely compile that done to C. From C, we use existing compilers, which is a big risk, but that's the one you are willing to take for now. There is actually a certified compiler named Concert built by Inria. And that's what we use for our formalism. So we prove that we compile to the semantics of C as used by Concert. And if you want, you can use Concert instead of GCC or MSVC to compile your stack. But if you do that, you are going to miss some optimization. So there is a performant cost in using a fully verified compiler. So concretely, here is, okay, it's not that readable, but I'm not going to read the lines, so don't worry too much. So that's one routine computing the last polynomial added to the Poly 13.05 computation. So that's F-star with the specification and the implementation. And it compiles to this, which is, if you could read the details, just C code, but with very clear correspondence in the operation. So in effect, we are mostly erasing all the specs and the proofs elements to get back to see. In fact, you can see that there is the code that is just copied verbatim, except for inlining some of the constants. And then we have memory safety specification that guarantees that all the pointers that are passed in and out are accessed as they should and that they are live when they are the reference. We have a math spec that relates to what I have shown earlier and that says what is the specification of what you are doing in terms of unbounded precision mathematical integers. And then we have a proof that applies to lemas to convince ourselves that what we do in the code matches the mathematical spec. So it is correct, but is it fast enough? Well, the good news is that after quite a lot of work optimizing both the compiler and the source code by my colleagues, we can match or even exceed the performance of the best in return implementation coded in C. So here you have the numbers given in cycles per byte. And as you can see, we are slightly better and even much better than OpenSSL for portable C implementations, notably for curve 2559. We are not as fast as assembly yet. So if you are willing to use platform-specific instructions, then we can't compete by writing code from F-star, compile to C. But for that, we have domain-specific language that does portable assembly and that gives you even better performance at your verification cost. So the tool is named Vale. It was presented last week at Eusnix. And the principle is the same. So here is the six instructions in the OpenSSL implementation. So here we just use exactly the same instructions in Vale, although they can be manipulated and assembled using procedures. And that was the instruction where carry propagation was initially missing, one of the three bugs I mentioned earlier. So this code is essentially unchanged and will be generated exactly as what you would use in OpenSSL or any target implementation. But you do have a mathematical spec plus memory safety specification telling you what the math is and also what registers are being affected by what you are doing. And there is also some explicit proof annotations to convince the prover that you are indeed complying with both the memory safety policy we claimed and the math specifications we gave at the beginning. So the design for that Vale language, so Vale stands for verify assembly language for for rest is quite interesting. So we embed the semantics of the platform in F-star so that it is platform specific but easily retargetable. And we treat the specifications and the description of the processor as part of the TCB but on the other hand the source code and the Vale tool that generates the code and the proof can be interested because the result of its work is going to be checked using F-star verification. So and performance is unsurprisingly very good so we match we can match any assembly that will compile on x64 probably we can prove it is correct. And here the number are slightly better but I will not read too much into it. I think it's a slight difference in the coding conventions that we use but by such chance we get the best performance for things like AES where using specific hardware acceleration is critical and where we will not be able to compete just writing SQL. Okay so that concludes the part on the cryptographic algorithm themselves. The next step is to look at cryptographic protocols and security rather than just correctness and safety. And for that a big part of our work has been focused on TLS 1.3 which is quite an exciting revision of the protocol so you I'm not going to say much about TLS 1.3 at all but it's the result of an intense and quite strenuous discussions involving cryptographers, engineers and many users of TLS. It's more modern it removed a lot of the bad cryptography that led to the use assumptions for TLS 1.2. It has fewer round trips and so it should yield significantly better performance as well as stronger security. So for us it's exciting because new implementations are required for all and so the fact that we are developing implementations from scratch is less of inconvenient and at the same time it's very important for us to complete as much of the verification as we can before the draft turns into a standard because it is still or it was still relatively easy to make changes or to improve the protocol and it's going to get incredibly hard so for triple and shake attack the time to patch the protocol with the mandatory extensions was three years which is just too long. So what the status is so as I said it was quite active and complicated process so we are at the 21st draft and we were at the final call but we went back from final call to do a bit more testing before going back to final call so in short it's almost ready to be turned into an RFC but not quite and it took much longer than expected. Also from our viewpoint several proposals that we made were implemented in the standard and we think they lead to stronger security they certainly need to stronger guarantees in all the models we have considered and so they include findings from our work until it's 1.2 and also more smaller scale designs against don't buy resilience and fine prints in the new standard so interestingly we also introduced a new attack in one of the drafts by fixing another but gladly we fixed it before maybe I think it for after one month it was fixed so this happens but we have to we will not trust ourselves with most of the changes otherwise. So where do we are in terms of implementation so Mitziel S is coding in FSAR today it has been running and cooperating with several other implementations for one year we implemented many variants of the standard so we are at TLS at the draft 1.3 it's still partly verified so we still have to complete an integrator work on verifying the handshake which is also coded in Okamal I'm not compiled to see yet so what I'm going to focus on today is work that we did complete for the record layer where we generate C code and we have completed verification for that part linking to the verified crypto that I presented earlier. Okay so I have a few slides showing what we mean by actual cryptographic verification in F-STAR and the goal of those slides is to convince you that what you are doing in F-STAR is not so far away from what cryptographers will do typically on with open on paper proofs using a game based code based reductions to convince our fellow security of their system so so we so we don't have functionalities instead we have actual implementation module so each box represents an F-STAR module which implements some functionality with some well-defined interface and so we use them for everything so for the implementation itself but also for modeling games and cryptographic assumptions and we use the very precise type interface of F-STAR including the mathematical specifications if need be and also modeling of stateful effects to capture what these primitives are doing and also what security properties we expect and so the the idea is that to capture in the formalism at the level of the interface all the properties you are going to rely on cryptographically in our proof so I have a very basic example to to clarify this method which is to look at message authentication codes which is hopefully the property that we want for the poly-1305 algorithm that I've shown earlier in the talk at least for a single message so if we look at the interface of a mac library it's not going to say much about security at all so it's going to have a function for generating fresh keys a function for making messages and the functions for verifying messages and it may specify the length of the tag or the length of the key but it's not enough to reason about security so instead we write an ideal interface that captures the the essence of security notions that you are that you are going to rely on or if you are constructing something trying to establish and so for mac in these specifications we are relying on a log so we have a log which is ghost it it doesn't exist at runtime but nonetheless we can use that log to specify what ought to happen with a perfect implementation of a mac so when we generate a new key we said that the log for that key is empty when you make a message we add to the log the message together with its tag and when we verify the message the result is exactly or has to conforms with the result of the lookup in the ghost log that you are maintaining and so if you think of it it's very close to a ufcms security in fact you can show that it coincides with data and it's great for verification because once we have this log and we can reason about it we can reason about the log at the other end of the communications and that's sufficient to do conduct or protocol level proof it's not so great from realism because we know that tags can be guessed so our type system would reject any implementation that may fail because the tag can be guessed and so so we have to do a bit more before we are able to use that nice specification to continue with the high level proof of the protocol so to do that we also use fstar to program a game and so we have a game that defines ufcms security you know so it's quite the classic definition except that it's for mic instead of signatures and so in the game we generate a key we also have a log so it's essentially the same log and you have an oracle for encrypting messages and the attacker gets the oracle and tries to produce a forgery and then we check whether it is indeed a forgery by verifying that it works and also checking that it's not in the log so that just a naive transcription of the game that defines ufcms and now from that game we can we can reduce deviations from the ideal interface that you like to use to verification to an attack against that game so that goes as follows so we have a concrete protocol it's an rpc we have a mic implementation that is assumed to be ufcms but only computationally so we introduce an ideal setting that you are going to jump to in a single game step and we have a filter that is going to use the log to correct all the forgeries and because we correct the forgeries we have the nice unrealistic spec so we can verify everything and conclude the proof of security for the full protocol by typing however we still have to go back to the real world and so we can also check by typing that anything that composes with the radial mic interface is actually a valid ufcma adversary and that the real system is secure except with the same security loss as the one incurred in the game that defines ufcma so that's a very simple example but that's the basis for most of the proof that we do in f-star so we don't do any deep cryptography but we can compose existing and you can formulate and compose existing game-based notions of security for all the primitives used using tls for example so for example i'm going to show get into more details about the record layer so there we need more than authentication we need authenticated encryption and we can write a game that defines authenticated encryption as you would expect and we can transcribe that into a game written in f-star and capture its security by typing again to go once we have defined that game move to a world where we can use step shaking and automated verification to propagate the guarantees given by this this game so the constructions we are going to do is for the record layer so it involves combining a mac and some encryption so here i'm not going to give you the details for it but i wanted to give you the details for something that you everyone who already know which is encrypted and mac and so in that case we have two modules with that require some cryptographic idealization so we first idealize the mac as i've shown before using the ufcma assumption once we have that we can verify by typing that we comply with the in-cpa interface because we are never going to decrypt a message that wasn't encrypted before so the encryption is by lookup not by actual decryption at which points we match the interface to idealize the encryption and then we wish we can idealize and by combining the two we can verify without any new security assumptions that the uncridden mac constructions give the guarantees associated with authenticated encryption and so that's the general structure of the proof so we have a module that captures any cryptographic assumptions you are making and then you have a systematic way of composing them using flags to control idealization so technically we are going to verify the code no matter what the flags are because we don't want to verify separately each of the intermediate games in the proof so the proof goes for all the games that are going to be spanned in the proof and then to conclude the proof at the top level we just need to switch the flags one at a time to conclude so which is completely generic within that setting so okay so let's go back to TLS so the regular for TLS is the same except that there are lots of standardized complications in particular there are many keys there are many algorithms there are many constructions there is also a fancier model for key compromise where both algorithms and keys or intermediate secrets can get compromised and then there are engineering details like fragmentation padding and state so it's probably worth doing because although it's less if maybe more mundane than verifying the handshake it's a place where there were historically lots of bugs in TLS moreover it was at the explicit request of the IETF which were which observed that there was no security argument for validating the new proposals in 1.3 and so being able to validate something that complies to the letter of 1.3 was perceived as valuable on its own and indeed we could we were inspired by existing papers but we could not apply any existing papers directly to get the security of the standardized record layer so how does it work well the record layer does multiplexing and it multiplexes between multiple keys and multiple sub protocols and so at the top you have multiple sub protocols you are multiplexing their contents using whatever key is available at that time and especially in 1.3 many more keys are introduced so you have intermediate keys for the handshake and you have also a mechanism for ricking so you have to live with this idea that you are going to have a stream of stream of keys a stream of messages exchange on a succession of instances of your authenticated encryption primitives there is also a new format that makes a multiplexing above the encryption and decryption meaning that the content type is read on within the packet and it adds a bit of privacy and also pragmatically it enables the encrypted uncheck to masquerade as an application data which is important for early deployment and so in our implementation we build the top level interface using nested modules that implements a new feature at the time so we have the sequences of multiple strings driven by the handshakes we have the multiplexing of contents within each stream with padding and length hiding then we have a stream encryption with packet numbers then we have an authenticated encryption with additional data and below we have multiplexing on the choice of the prf and the choice of the mac algorithm and that's the last thing i'm going to describe in details in my presentation okay so we are at this level we are going to verify and implement stream encryption for tls so that's the main modules in our implementation for it so that involves some symmetric crypto as well as a few modules for the record layer so i'm going to give you as expected the security definition then outline the constructions the new constructions for tls then obtain concrete security bounds then discuss what you did in terms of verification and what you get in terms of performance so for the definition i don't have a noracle based definition they have a nice picture instead but it's it's equivalent so here we assume the key is established and we model ideal encryption by using this log that is so convenient to reason about using tools like f-star so instead of encrypting we sample ciphertext and we stuff it into the table and for decrypting we just look in the table if that corresponds to something that you want to be for and we return that instead so we switch from red which is the real one to blue that is the ideal one that lets us continue the proof and you want to show what the security loss of doing that for the target constructions so now we look at the standard and luckily there is much less variety in the choice of ad construction than before in fact there is a ccm but it's not used that much and if you look at the others you have a choice between a gcm and chat chat 20 poly 14 or 5 which both have roughly the same use the same construction the same proof structure so in fact our implementation and the proof is mostly shared between the three cipher suits we verify for tls 1.3 and the two cipher suits we verify for tls 1.2 which are slightly different in their what is explicit and what is kept implicit so this is a simplified picture of where it works it's not very surprising so we have a plain text which is arbitrary size so the last block may be truncated we have a prf and we use the first output the the first output of the prf to generate a one-time key that we use to build this the efficient multiplicative mac so at least part of the key has to be used only once for that message and then we put the additional data in front we put the the cipher text next to it we multiply all of that together and we have two final blocks one for the length of the plain text and additional data and one for the authentication tag so in terms of assumptions we rely on a one-time mac assumption so it's like a ufcma but for a single use so we have a variant of our specification that deal with that case and the good news is that we get very strong probabilistic security there is no computer assumptions for that bit for ciphers there is a choice between a yes and chacha 20 and for a yes there are multiple variants and they are we just assume a prf assumption that it is a prf and in the case of a yes we incur the cost of switching from prp to prf so then we write our implementation and we verify it and so what we get is a proof of safety so there is no buffer overrun or privilege escalation just by running your code which is the least to expect we prove functional correctness which meaning that what we are the byte that we output are exactly those matching what is given in the available specification of the algorithm then we prove security by reductions to the prf assumption I mentioned with and we derive concrete bounds by adding the epsilon on paper corresponding to what happens in the code so right now fstart does not enable you to formally reason about concrete probabilities so that the computation of the concrete bound is done on paper on the proof that is structured and verified using your tools so interestingly that involves quite a lot of different proof obligations and so I'm not going to detail of them but I just want to mention a few so as we go down in the stack to build the TLS so at the top as we have seen earlier in my presentation most of the effort is about functional correctness for algorithms like ASR chat chat but there there isn't much to do it just it just shuffles a bit there is a deeper proof relating to a simpler math specs for things like the multiplication in the gawa field for ASGCM and for polynomial and the prime field polyethylene of five so there are there is thousands of lines of implementation revampments of proofs to show that we match the algorithm at the next level most of the proof is about abstracting the details like the lengths and that we don't want to the proofs to depend on for the rest and also about cryptographic agility so TLS has cryptographic agility everywhere so it's and in that case we really want to be able to to prove that there is no bad interaction between different configurations that you made shows and that for example as was the case for TLS 1.2 it's not possible to reuse the same key materials with different algorithms which is at which point solvents are of internal security but here there is no such thing it's actually worked quite nicely then we have the layer of security idealizations where we have two addition steps one for one cm and one for prf and on top of that once we have the ideologue we can reason about how the messages are assembled fragmented reordered and and cut from fragments to blocks and so there is quite a bit to show in terms of injectivity to show that what is authenticated is enough to authenticate the full stream then there are three loops to deal with the fragment loop the block loop and the block loop and the authentication loop for the authenticator from this point the rest of the proof is much more about TLS engineering and has to do with multiplexing by the degree king and also the new feature like zero RTT or 0.5 RTT so as I said you obtain concrete bounds so when that mirrors what was already documented in other papers up to a few details that are specific to TLS 1.3 and because here we just have to idealize module we just have to sum the epsilon there is one thing that is interesting here is that for agcm because there is a 128 bit output of for the block we are there is arguably a chance of collisions as you in case you use agcm with a single key for a very long time and so that was debated a lot on the itf main list in fact we computed that since TLS provides its own RIKI mechanism you can automatically RIKI using what's already in the TLS standard to optimize and get a much nicer controversial bound by just deciding to RIKI every 2 to the 24 records in the rigor layer and RIKI is very lightweight and it's probably important to RIKI even faster than that just to get a bit more forward secrecy for your connections. So as I hope is quite clear at that point this is not just a proof of the design we actually verify the actual implementation that I used to run the demo earlier in the talk and we get reasonable performance it's not as good as the performance from the unit test I have shown earlier so we are still working on it and so for example at the top there is the time it takes to transmit one gigabyte of data and you can see where we are right now so we used to have OCaml as a backend instead of C and OCaml is a high level language which is very bad at byte level manipulations and so you can see that we lose several orders of many to just using your high level language instead of C and the optimized algorithms in C so that's that's done that was a very important step so this compares all implementation integrated with the proof together with using OpenSSL and you can see we are still a bit slower but I expect most of the discrepancy to disappear once we integrate better the latest verified algorithm from tools like fail to or verified security stack so for example we are now at just eight cycles per byte for implementation using a portable implementation using yacle star which is a bit better than OpenSSL at least until you start using xc for optimized much faster implementations so there is also verification cost so that that proves wasn't easy in particular because it goes down to every detail to be standard compliant and but it's very modular and reusable so we can build upon it and it's very easy to add variants or variations of it you can see that the proof consists of putting explicit specification and auditions that get erased as we compile to C and so but because we also use metaprogramming to do inlining and to specialize the code in C in fact we erase the proof between line and diva and express what you do in a lower level language so the the the size of the code before and after compilations are not that different oops sorry about that so in term of time so that's not the manual verification time it took us a few months to get there and to get everything in place but once everything is in place this is the time it takes to verify as part of continuous integration so every night we check that the differences in producing the tool don't break the proofs that you already have and it's at that point it was a bit below two hours now it's more like one hour but it varies on a daily basis and so we are putting a lot of engineering effort to maintain our proof and to make sure we don't break things as we improve on that feature both the protocol and to the language but that's that's quite a significant engineering effort to to get there and then to maintain it on an ongoing basis at the same time provided we get that ongoing we can make a change and two hours later you have a full verification again and in fact most of the proof can be factored out because each module is verified completely independently so it's it's not that bad from that viewpoint all right so time to conclude so so in this talk I presented what you are trying to do with HTTPS we think it's okay we know it's quite complex and critical but you also think that it's small enough to be in range of cryptographic verification at at the level of details that gets into the standards I did not mention much related work or colleagues as part of this talk but as should be obvious by now this relies on a very deep collaboration between cryptographers system researchers programming language researchers and verification specialists and that's that's quite a lot of fun we also have new tools I said very little about the tools themselves but we have interactive tutorials we have papers there are lots of details out there if you want to check them out and I hope I have convinced you that we have a method to get a safe functional darkness and cryptographic security for a useful standard compliant system code so here are some pointers so the code is the code and the papers everything is available online in particular if you go to a salon you will have lots of tutorials including some cryptographic tutorials explaining what it means to use the tool and giving you a way to start with the tools if you are curious okay well thanks