Internet Engineering Task Force 105, 21 Jul 2019

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF105-TUTORIALSEC-20190721-1345

Description

TUTORIALSEC meeting session at IETF105
2019/07/21 1345

https://datatracker.ietf.org/meeting/105/proceedings/

A

B

Frickin go ahead and get started: okay, I.

B

B

So we're gonna go ahead and get started, so this I'd like to welcome everybody to the writing security considerations. Tutorial I am Karen O'donoghue from the edge you team and we provide the tutorials the newcomers overview and a number of the other things related to general training in the IETF. If you have any suggestions or comments about things that you think we need to do, there is a mailing list. Edu te am a Jew team and we would welcome any suggestions that you have.

B

Also at the end of this there's going to be a link to a survey. We do actually look at the survey results and so I'd really appreciate any feedback. You have there and if you have any suggestions for future tutorials, you can also put those in there as well. So with that I'm going to introduce that our two speakers for today, Yoav and and linda and good luck with your tutorial.

C

Hi yeah, okay, my name is jeff near Linda, we're both on second year, which is the body that reviews all draft scintillant for publication for security issues, and one of the big things that we do is we review the security considerations section in every draft and we often see a lot of things. We don't like there. So you've come up with this tutorial team, hopefully make the things a little better, okay, so motivation, why do we actually? What do we even write security consideration sections?

C

So the first thing is that security is relevant to all protocols, not just those that come out of the security area.

C

It's obviously why we need protocols like IP, TCP and the stuff that comes out of the security area like TLS or IPSec, to be secure because they're used by everyone there into the cryptography. So there are important stuff, but other protocols also need to be secure. I mean you could have the best security with TLS and still, if you layer HTTP on top of that, if you can still give up all the security yeah yeah, the TLS notwithstanding so tears will not solve all your problems. Specifically, it's not going to solve the issues of credentials.

C

So there's a lot of stuff about implementation and deployment issues that are not covered well in many documents that we get Oh as always feel free to run to the mic and ask questions if, if you want, don't have to wait to to the end so now the security of a system depends not just on using good crypto, which TLS and IPSec will provide you, but also in dispensing identities and credentials and verifying them.

C

So suppose you have the protocol and you decided to use certificates to authenticate all the nodes within the system great, but who issues the certificates? How does the CA that is going to sign the certificate to verify that whoever asked for the certificate whether since the certificate signing request, is actually who they claimed to be? How are the private keys secure now? This part is not really usually ITF domain, but it's also important for the system and when one node connects to another, how does the other node first validate the certificate and then what?

C

How does it validate that the name in the certificate and how does that map to authorization and more motivation? Well, sector review is part of the document publications process, whether you like it or not, you're going to get a sector review so and the security area directors always read the sector review and if you don't respond to the secretary of you, just ignore it well you're going to get blocks or discusses. So don't ignore the secretary views secretary viewers will read your entire document.

C

Usually there have been six hundred page documents that we haven't really read every page of, but we definitely do read these security consideration section. So, please make it the way it should be. So it's not just a good idea. It's the law and by law I mean it's enshrined in an RFC, so RFC twenty, two, twenty three still valid still not obsoleted, has section nine. That's it in in its entirety.

C

All RFC's must contain a section near the end of the document that discusses the security considerations of the protocol or procedures that are the main topic of the RFC. So you have to have it.

C

Piece of advice is write them early.

C

Don't leave writing them to the end of the process, because sometimes when you write the security consideration section, you say: oh my well, this is drew well, we have to go back and revise, and you don't want to do that when you've already decided that the document is ready and you're ready to send it to the is G just have to write this, these sections that are missing the Ayana considerations and these security considers now don't do it that late another thing, if you think that there going to be some contentious issues, ask for a sec to review early.

C

It's a few clicks on the website on the data tracker, especially if you are working group chair, please ask for an early review and they can help okay. How do we get here bit of history?

C

So once upon a time- and you always hear that Oh at this beginning of the internet, they didn't consider security and it's sort of correct and or at least they assumed that the security is either there or not needed, and a lot of RFC did not have security considerations at all in them, and a lot of people didn't think about security when designing protocols, so RFC 22 23, to mentioned earlier required security consideration checksum, and this goes back to 1997.

C

So then people didn't really know what to write and they made somewhere really wrong things in there. So in 2003 we had RFC 3550, that's just guidance on writing security. Consideration section- and this is quite a big RFC- it's a little outdated here, but by now but erm, it's still mostly relevant not entirely, and we try to update it a few years ago and unfortunately, we fail. We can get their mass of people to review and comment and offer text so that effort just died. Unfortunately, so at the moment this is what you haven't.

C

The internet threat model is taken from RFC 3550 and you are encouraged to read that document.

C

Ok, so they even a threat model, as described in RFC 3550 includes that it's about connections going all over the internet and you assume that the attacker may be may be in any place on them and on the path. So the attacker can modify any packet drop, any packet spoof any packet, so never assume that the path is secure. If you want security, you have to do it between the two points, and you should also consider things that have evolved since then.

C

The difference between off path and on path, attackers, it's described in RFC, 74 30, and also consider that the sufficiently powerful taifa Tucker can become on path by pretty much convincing the Internet to get your packets to go through that truly something controlled by the attacker and lots of ways of doing that also considered privacy considerations, which became more important in recent years, see RFC 69 73 about that and pervasive monitoring that we've started worrying about relatively late.

C

That's an RC 7258 in trust. Trust is important thing to consider, because one of the best ways of getting an angry comment on a sector review is saying: node a is trusted. What do you mean trusted? Who trusts it trusted to do what? So, it's always a trust B to do C never just be as trusted. It's never good enough.

C

Even CAS CAS are not trusted. They're trusted by specific people to do specific things, I mean if you look at even at what PKI and that's a lot of CAS there there's the famously there's the South African post office when did I ever trust. This South African post office I never did well Apple and and Google and Microsoft decided for me that these are trusted things so on really trusting Microsoft and Apple and Google to decide well, who is trusted?

C

Okay, well trusted, at least for browsing the web. Okay, so questions you should ask, and all this is material from 3552.

C

What you know how much Dean do you need confidentiality? Do you need data integrity? Do you need per entity? Authentication usually do otherwise you're just sending stuff to anyone on the internet. So are the messages really expected from peers rather from attackers, and are the message really sent from the expected peers and not to attackers right?

C

The security consideration section needs to explain which attacks are in scope and which are out of scope, and why are they out of scope and the texts that are in scope and are those that the protocol is susceptible to and that the protocol protects against okay attacks that you need to consider there's targets even in Walden systems in your data center, such as router and switches that are in cages or well in your data center behind the firewall are susceptible to internet threats because usually can get traffic from the Internet to those nodes and especially that they have ports that are facing external, more vulnerable targets.

C

You should think of passive attacks like sniffing and other cryptographic, attacks and they're common issues, that of shared keys, there's kind of a design pattern or an anti pattern that you have a group of a group of hosts that all have the same key certificates very often mismanaged downwind attacks do now service attacks firewalls. All this and much more in RFC 3550, please read it.

C

Okay attacks to be considered active attacks, active attacks are obviously require more resources, but we have quite a few people who can do quite a few entities who can do active attacks. There's proof in attacks, replay attacks, message, insertions and met in the middle attacks.

C

C

So what has to go into the security consideration section, and the first thing is that everything that tests to that goes into the security considerations. Section has to be about this new stuff that you, that is in your document. If your document is running over IP, you don't have to cover everything that goes into IP. If your document your protocol runs over TCP, then you don't have to cover that either yeah. Unless you're in the transport layer and then you make changes to TCP and then yeah.

C

It makes sense to write what has changed in TCP, but if all I'm doing is sending some kind of content over Jason I, don't have to describe Jason I, don't have to describe HTTP I, don't have to describe IP all that is in other documents. I don't even have to reference them. Just what is new and there's always something new? Otherwise you wouldn't be writing a draft. Why would you so anything about the threat environment?

C

Environment should go in the security considerations, section TCP current that is anywhere in the internet, maybe behind not maybe not, and it's connecting to a server that is in the cloud or in some data center. That's the internet effect model. You don't have to do describe it all over again, because that's that's been described many times already. So if your environment is different, yeah please go and describe it example. Yeah this protocol variation inherits all the security properties of regular ESP. That's the kind of hyper sec and capsulated security, as described in RFC 4303.

C

Okay, this line is taken from a draft that didn't make it to RFC in the end, not because of security considerations. It's from draft shoe tik-tok security for synchronization, it's about protecting I, Triple, E 1588. Now in case you don't know, I believe 1588, also known as the precise time protocol requires consistent, latency down to sub microsecond or sub nanosecond jitter. So when I first heard that I said well, any router is going to give you more jitter than that, and it told me well yeah, but our protocol, it doesn't go through through routers.

C

It only goes to special switches that are have constant, latency and said: okay, this knowing the document does it say that, and this is not the internet if you go through a router you're, not on writing on the internet. So if your environment is that's different yeah, you should say that in the security considerations, everything related to a router is not relevant here, because we don't use routers, okay in scope and out of scope threats.

C

It's fine for a document to leave some security aspects out of scope, but you have to say this so an example. Protecting the endpoint against flooding attacks is out of scope for this document, because we're running over TCP, right and TCP is already covered elsewhere. It should be mitigated with normal network management procedures. Now, usually, if you're running over TCP, you don't even have to say that, because that's true for any TCP. So when do we have to say this? Well as an example, the like the Internet's key exchange protocol runs over UDP.

C

So a few years ago, somebody made a document for Ike over TCP. That makes so ICO for UDP has its own anti flooding thing it's or its own anti denied of no service RFC. All that goes out the window once you run over TCP, because then everything changes. So, if I'm making an IKE over TCP document, yes, I should call out that everything we don't usually do with UDP out the window. This should be handled like any other TCP service. So so, if we changed this for Ike yeah, then we should call it out.

C

Otherwise, no, if you're just making something over TCP, okay, security or anything that has to do with authentication goes into security considerations. So how is the authenticating patient protected and yeah we use? Tls is a good answer. Our credentials generated. How are the credential dispersed to the node, how our credentials and verify is protected, and this is hardly ever obvious. I mean you think of authentication works well in the web.

C

Well, authentication on the web is one way: it's only the service, the clients, usually don't, and it's such a hard problem that there's a whole different standards organization called the C, a browser form that just has the browsers and the cia's the name kind of suggests that meat several times a year, sometimes virtually sometimes physically, to discuss how not to issue certificates to the wrong people and it's hard problem.

C

They still have to meet often so what I'm saying is that authentication is a hard problem and if you're saying okay use, certificates or we'll use passwords, you should elaborate because it's really hard to deploy residual risk if there's still some risk after you have after you've mitigated it with several mechanisms. Call this out a good example from RFC 52 46.

C

That's tell us one point to this: well, there's a paragraph before that that describes how they mitigate some timing and risk of, but this leaves a small timing channel since Mac performance depends to some extent on the size of the data fragment. But it is not believed to be large enough to be exploitable, because the large block size for this Tmax and the small size of the timing signal that's excellent text for the security considerations too bad. It's not in the security consideration section, but at least they got it in there.

C

Okay, risks from foreseen and Mississippi of misapplication or Mis deployment. I mean read your draft. If you think, ok, people are going to implement this or deploy this in an insecure manner. Tell them don't wait until they do some bad stuff. A good example from this document, the shaykhs document. This is document that describes how to use the sha-3 hash functions, often called shakes with PKI.

C

So this is an excellent document that provides us both with a good example this one and a bad example that we'll see later so when using ECDSA with shakes the ECDSA curve order should be chosen in line with the shake output length. Nist has defined the appropriate use of hash functions in SB 878 points force, SP, 800 107. These documents can be used as guides to choose the appropriate key size. In this case, we recommend that you use ID ECDSA with Shaikh 128, with a curve of order, 256 bits and ABCD si with J 256.

C

These are both algorithms that are defined in the document is recommended for curves, with groups order, 384 bits or more now. These curves are never mentioned in the rest of document. They don't say which curve to use, but this is good advice for implementers, so they don't mix high-security shake with a high with a low-security curve.

C

So this is good stuff. This is good advice, and this really should go in the security considerations section so great for them. Now, if you can anticipate people doing something bad tell them, don't let them fail. I mean it's not enough to say this in the working group because the people are going to implement. This are not necessarily in the working group, so somebody gets enough seen when they tell them implement this. They had they're, not privy to all the discussion that went on in the mailing list and in the room, okay and what's involved.

C

This is very important for its engines, call out information that is sent out. One time I got this document to review that we had an extension for protocol that I could included a message with the IP address of the server.

C

This extension sent in the distant to the IP address the name of the person managing his email address and his phone number sending that over the Internet is not the same as sending an IP address, and it could be okay because they'll usually use not to their home email address, not their home phone number, hopefully, but some helpdesk, a phone number, and so that's it might be fine to do this, but call it out you're, not just because the previous protocol was considered good enough doesn't mean that the new information is also good enough to send over the Internet.

C

So if the xeo extension is sending information that was not in the base protocol call this out and say that it's okay, it might be okay, I'm, not saying that sending any new information is bad, just to call it out and we'll see some good in a good example in the pitfalls.

C

So what does not go in this security considerations? Obviously my chocolate-chip cookies recipe doesn't go in there there. So this you could have a lot of slides here, but what we have here is slide about things that we often see in the security considerations considerations a section that shouldn't be there and most the most common one is RFC 2119 language, now I'm, not making a blanket rule that never never put a must in the security considerations, but usually it's wrong in if something is necessary to make a compliant implementation of your protocol.

C

It goes in other places in the document.

D

C

Here's the wrong thing is the unique string value mentioned in section: 4 must be 256 bits, highly high-quality random bits and the RSA key in Section 4.1 must be at least three thousand 72 bits in length and must be chosen using one of the approved methods in SP, 800, 56, B, ok, so what's wrong with that, I mean I, make a compliant implementation, I need to use 3072 bit RSA keys and they need to use 256 bit unique strings. This is not optional. This is not something that should consider.

C

So the right thing is to put those requirements in Section, 4 and 4.1, and then in the security considerations, checks and well say: ok, this requirement in Section 4 is because we're trying to avoid birthday attacks and the requirements in Section 4.1 is the current state-of-the-art. Assuming an attacker is not a good poster in large-scale quantum computer phears. Then we don't really have a a symmetric keys, a symmetric algorithm at the point at this point, so yeah we're screwed anyway, so RFC 2119 language usually does not go in the security considerations.

C

Section motivation: we see that a lot remember that I Triple E a 1588 craft, so here's the rest of the security considerations. This document described modifications or extensions for the West protocol. That's wrapped ESP for the additional application. The approach described does not require requires DSP the endpoints to be modified to support the new protocol. It allows ESP receiver or intermediate node not only to distinguish encrypted and encrypted traffic, but to also identify whether the encrypted packets are the common packets or the time packets by a simple implementation for the transport node.

C

Okay, this is motivation and motivation goes in. The introduction doesn't go into security considerations. I mean we care a lot why you wrote this document, but this is not part of the security considerations and random musing. Remember the shaykhs thing: okay, here's the bad part! The shakes are deterministic functions like any other deterministic function, executing multiple files with the same input will produce the same output.

C

Therefore, users should not expect unrelated outputs with the same or different output, lengths from running a shake function with the same input multiple times, okay and if you're, if you're at the level that you're reading RFC I, should hope. You know what the deterministic function is and it anyway we have people coming writing a document and, oh, we have to write this security. Consideration section and I have no idea what we need to write so random musings and this paragraph was deleted in it in its entirety. We don't mean it.

C

Okay, pitfalls, learn from the mistakes of others.

C

So the thing we see a lot is security considerations by reference, meaning this is the people say well, others have already covered everything important here, so we don't need to, and you see this, the mapping extension described in this document did not provide any security services beyond those described in by EPP RFC's and 5730. They EVP domain name mapping in 57:31 and protocol layers used by EPP. The security considerations described in this in these other specifications applied to this specification as well. Okay, uhm EPP, is a provision extensible provisioning protocol.

C

Obviously extensible because here we are extending it and the extension means is about sending financial information. I mean this customer has already paid so many dollars and we've already provided so much service, so R is so their balance is so many dollars, and this was not in the base protocol in 57:31 and it's in the extension.

C

So something has definitely changed. I mean the base protocol did not have financial information. The extension does so you can't just say everything that everything is already covered by the previous specifications. So yeah, please say I mean it could be okay. It could be okay to send to send the balance over this protocol because it is protected and it is going only to the customer so tell you the customer. Their own balance is fine, I guess, but you should call it out. This is new information that it was not in the base protocol.

C

It could be sensitive in certain secret situations, so you should describe say that it's fine to send it because of all those reasons but say it. Another thing don't do both in one level of indirection if I see well. The considerations for this is are the same as in RFC that go to RFC a and yeah the security considerations. There just say: go to this older RFC and at some point this is too much.

C

So if you have more than one level of indirection, either go even either reference the original document or just write your considerations by yourself, even if you copy and pastes much of it, it at least makes you consider everything: okay, another example: procedures protocols, extensions defined in this document do not affect the bgp security model, see their security considerations, section of RFC, 4742 71, that's BGP, and a discussion of bgp security in 42, 72 and 69 52 for analysis of security issues for BGP quick. So we're talking about an extension to BGP that sends te.

C

That's traffic engineering information over BGP, but this is not all that there isn't. In the section the other paragraph says the T of is introduced in this document are used for to propagate AGP defined information same as in our c 78, 10 and 7471. This TLB represents the state and resource availability of the IGP link.

C

Their GP instances originating these deities are assumed to have all the required security and authentication mechanisms, as described in those two documents, in order to prevent any security issue when propagating tlvs into bgp LS, okay, 78, 10 and 7471 described sending these the same traffic engineering, information in ISAs and OSPF respectively. So these are two different routing protocols and so the they already had defined the traffic engineering extension and now we're taking the same traffic engineering engineering extension and sending it over BGP.

C

So the of the security considerations are the sum of BGP issues and the traffic engineering in ISAs and all OSPF issues. Is that a valid claiming to make well I said it isn't? Because it's not the same BGP is not the same as ISAs and OSPF. Why? Because I Esiason those bf run on corporate networks, usually I'm sure somebody can say.

C

Oh but I'm running BGP in between my phone and my laptop, but usually no, usually I Esiason OSPF run and corporate networks, and every node that is participates in these protocols is owned by the same entity and while BGP runs on the internet, it's your router to somebody else's router. So it's not obvious to me that sending traffic engineering information is okay in BGP, just because it's okay in OSPF. These are very different things. So again it could be fine.

C

Just say it say that these are traffic engineering and we're not and sending him over BGP to somebody else's router does not make doesn't, does not risk the any attack that were aware of. That's fine. You say that's, but you have to say this. Otherwise, yeah you get to discuss.

C

Okay, another thing: we see a lot and the first one here was actually the thing that drove people to wrote to write 30 35 52 is we don't have to do security because security is in some other layer. This comes up in as in just use IPSec, but that was very common in the past. Just use TLS, that's more common! Lately or just use HTTP or IPSec with the I, an SF extension that we're doing now and soon to be published and just use TLS with acne, that's been published for half here.

C

Ok, so each of these requires a lot of instruction to deploy, can just a okay use IPSec and everything is solved. If you want to tell people to use IPSec great, just tell them how, if you want to use TLS, that's also great I mean the word PKI. It looks trivial to use, but that's only because some companies like Google and Apple and Microsoft meet often and do a lot of heavy lifting to get it stored to work for you.

C

So if people, if you tell people to use a security layer great but tell them how- and this is especially relevant for authentication and credentials who gets credentials, how do you provide the credentials? How do you offend against somebody coming to you to get the credential and how do you validate the certificate and another thing is authorization who is authorized to do what the common thing we see in everybody who has a certificate is trusted because otherwise they wouldn't have a certificate.

C

We wouldn't have given him a certificate if they weren't trusted so again trusted by whom to do what. So we have this kind of flat authorization model that anybody who has a certificate is authorized to do everything and authorized to impersonate anyone else and no that's not a good security model.

C

So we see- and we see that look so if you want to trust any certificate holder in the corporate LDAP environment and while doing this protocol for internal networks and everybody has a certificate from the local Microsoft, Active Directory. Well, every user. Every employee of that organization has a certificate from that l-dub. Every every machine has one and that old printer next to the bathroom. It also has a certificate, and if this is a security model, then that printer can do anything within your system. That's usually not a good idea.

C

Okay, there are more specific pitfalls for young models and there's a link there. You are eyes using them to locate resources. There's a section 7 in RFC, 3986 time and replay is always the danger of an attacker on path. Delaying packets or recording Pakistan, retransmitting them broken constraints. Well, attackers read the RFC's, but they're not bound by them. If you, if we have this to bite field, and we have and the RFC says, the number in this to bite field must be lower than 500.

C

This, the attacker is not bound by that they can send a much large number. They can send a string as long as they want within the Jason I mean nobody cares, even if even be I've seen limits the name to just 40 characters.

C

There's some documents, not usually in the ITF saying it's. This is okay for physical security, because we're using Bluetooth and Bluetooth is only. We only works for ten ten meter distance, but you can see demonstrations of people with parabolic dish and they're doing bluetooth with from a distance of kilometer or two kilometers.

C

Just use more more power than the Bluetooth document says that you're allowed to another thing we like is cryptographic agility, I mean if you write a document today and say well, you say es GCM, because that's the that's the algorithm that everybody likes, but then, if four years down the line, we decide that we don't like it. Yes GCM anymore, for whatever reason are you going to come back and write a new document, absolutely in the old one, and then are you going to go and replace all the implementations that are deployed already?

C

Probably not so building cryptographic agility into your probe into your document? If you are doing the cryptography yourself first, if you're relying on TLS 1.3, then good, just one point: three is going to do that for you, but in that case you want to have your implementations able to update the TLS version when necessary.

C

This is a link. Actually, if you download the slides and there's much more there, that's a link maintained by the security IDs and it's about the stuff they often encounter. That makes them issue discusses so read that and you may avoid. Having discusses on your documents, so questions and before you can go to questions, please fill out the survey, because this is the first time we're doing this presentation and.

C

C

It would never catch this. This missing, because I, don't I, didn't I, wouldn't know that all the libraries out there support signatures.

C

D

C

So yeah, but this is a good thing to call out. Yes, of course, if some time, if some day, all the all the libraries are better than wait, then you have no longer relevant paragraph in the security considerations. That's not a bad thing and calling it out may lead your implementers to use a library that that is better in advice for implementers is always in scope for any section in RFC.

E

C

The big thing is that your working group chair knows some people know some security. People very least has access to the security ad and can get someone to review the draft join to join the mailing list. Look at this. We often get this request.

C

Well, this working group there wants some input on so-and-so draft who wants to join the mailing list and look at this, and this is a common thing, and it's done so. That's the first layer after that you can ask for a secretary for an early sector review and that usually gets you an answer within a month or two and the third thing: yeah you'll get it in the secretary view, but that's kind of late.

C

You want to do it in early secretary review or get some assigned expert wait and we'll do we'll do an early review for no acknowledgement section.

F

Implementation and deployment considerations yet with the attacks all.

F

Communication security based, so could you clarify that seeming gap to me, there's a Miss on operational security or an cyber defense security considerations, and just perhaps should this be called communication, security considerations or all those things in scope. But you just where.

C

Are in scope and my examples come from stuff the thing you know: documents that I've reviewed and yeah well. This is true for for IAF documents in general and in the security area, perhaps a little more than it's even more common, that we kind of ignore operational considerations and it happens all too often and yeah. But if you have things that are important for operation and deployment yeah, they really should go there.

F

I, don't know how many people it has to go through if there's some requirement on the diversity of technology or industry, background sure.

C

Part of the publication process after you click after they work group chair, clicks, the submit to is G button is that it goes to all the directorates and we have this list of people who are on the security.

C

Directorate of the same goes for transport and routing and applications, and we have I, think 50, members or somesuch, and each document gets assigned kind of round robin two and a reviewer and they write a review and it goes in a mail to the is g2 the ITF mailing list and to the document, authors, maybe also to their group, to the working group I'm not sure about that. But anyway, this goes to the document offers and that's a review. The area directors of obviously know about it.

C

Every document has this: every sorry secretary of view has this boilerplate.

C

We have reviewed this as part of the sector, efforts to review all documents, the input, the content of this review are meant primarily as input for the security area, directors and others should treat this as any other review in 90f. Last call.

F

C

Not automatically, but there is this process that use that we when we get the list of documents that are going to be assigned, somebody can say: oh I, know about this one, and so I'd rather do my review on this one, rather than whatever random document you're going to assign me and another thing that could happen is that I get assigned something and I can't read: yeah the terminology there and saying I, don't know anything about this. Can somebody this is somebody as we have our own meal and listen.

C

Can somebody else review this so owe you one? Well, it's not perfectly and then there's there's a whole script that makes that makes a for that. Make sure that we don't do too many reviews. So can somebody help me with this and then, if somebody volunteers, they can take the review off of my hands and I'll get another one. Next next round.

A

C

To 46 to s1 to 1.2 had a side channel was about a timing side channel.

G

C

That was one of the reasons why we wanted to revise it a few years ago, yeah there's a lot of things that we didn't think about in 2003 and that we do think about today. Well, privacy considerations and pervasive monitoring that we we didn't think there would be any reason to you. Consider passive attacks, because we, the single attacker, can do, can always mount an active attack.

C

So why even consider passive attacks and there's some of that in the 3552 we just didn't consider at the time that somebody would be would have enough resources to do a passive attack on the entire internet. And now it seems that they can almost do that.

C

Where the ITF will we deal with communications security, mostly, and so, if something requires choosing the the exactly the exact right core within within the host, it's not really something that has to do with communication security same as that. We don't really discuss how to protect the private key within the host, so it doesn't leak out mmm these. Are we don't do everything that has to do with anything in computers? So it's a judgment call whether it is relevant for a particular.

C

And neither is shoulder surfing.

C

Okay, anything else, no thank you and please reply to the survey Thanks.

H

Can you go to the ether pad and put in your name, make it simpler and.

C

If somebody wants to ask whether this falls out under note will I have no idea.