Internet Engineering Task Force 108, 30 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF108-ACME-20200730-1410

Description

ACME meeting session at IETF108
2020/07/30 1410

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

A

Okay, it's uh something in 10 minutes wherever you are, which means the meeting is supposed to start right now and we still need a minute taker. Otherwise we cannot proceed.

A

Do we need to name.

A

A

Okay, yeah one: can you be volume, told to be a minute taker.

A

Well, we didn't hear what you said so we'll assume that it was yes.

A

Okay, thank you uh with that said, I guess we can begin.

A

And so here's the note well, I'm sure you've seen this thing before and um right now, you're all sitting about uh one or two feet away from your screen, so can't complain about the font being too small.

A

And this is our agenda: we've got all the technical differences and scribe and notetakers and notewell, and then we'll go over the status of what's changed since november.

A

Then we'll go over the then we'll have some presentations about dtn draft acne, subdomains, acne integration and something that's more akin to discussion about onion records and followed by any other business.

A

So would anybody like to bash the agenda.

A

Okay, not nothing just not in the room either. Okay with that and we can go on to status.

A

So since we last met, which was in november, uh we had four rfcs published: that's acme, caa acme, tls, lpn, acme, ip and acme star.

A

um We also had new versions of pretty much every uh document that we had because, of course, since we haven't met, met for eight months, then, and everything that wasn't revised is already expired um with that said, um there are also some related draft got updated, that's acne, subdomains, acne, onion, dtn, node id and, in fact, they're taking quite a large part of our agenda. This time.

A

So anything to say about that.

A

So if, in that case, we're going to presentations, starting with the dpn.

A

So that goes here, yeah, so brian.

B

I'm sorry I was muted, so part of the presentation is a general background on dtn and the other part is uh specific to acme. um So we can move on to the next slide. Please, uh for those not familiar the concept of dtn is that it functions as an overlay network on top of some transport protocols, and this is similar in concept to the operation of email with smtp.

B

So a little picture on the right shows how things are are layered, with the bundle protocol sitting on top of some transport convergence layer on top of ip and that tcp convergence layer is one option for how to move bundles around a dtn network.

B

There are other options, but the focus for this acme use and the reason is as we'll discuss on the next slide, the tcp convergence layer. So we're not going to talk about how bundles move around the network just know that they move from hop to hop between bundle, agents and, ultimately, hopefully end up at their destination.

B

So we can go into slide. Three.

B

uh Bundles themselves are, and a bundle starts with a primary block that has addressing information and some metadata about the bundle and then has a series of canonical blocks. One of them is always the payload, the actual thing being transported, and then a lot of them are dealing with processing controls, routing controls, security services and things like that.

B

So again, we don't need to get into too much details other than a bundle is a self-contained unit in roughly the same way that um an smtp message I'm going to use smtp as a kind of a touchstone for some of these things, because the concepts are are similar, so smtp individual messages uh hop hop through the network. Looking for their destinations and bundles do the same.

B

The protocols are different, the encodings are different, but the concepts are similar, um so we can go to the next slide and here we're getting into actually what we're trying to do here.

B

So the the proposed tcp convergence layer, it defines a mechanism for using pki certificates to do node, authentication and the two ways that it's allowed to authenticate a node is either through a node id, which is at the dtn layer or dns name, which is at the the convergence layer.

B

So we already know how to do dns, name, validation in rfc, 6125 and also we already know how to do uh validation in the sense of a certificate issuer validating that I own a dns name. So that's all worked out and taken care of, but the question came up is how do I, how do I, as a ca, validate someone's, claim to a dtn name? Well, a node id, and so a little bit of research was done and acme pre-existing. Infrastructure already has a well-established way to do all of the bookkeeping.

B

That ca needs to do its general purpose, job of making sure that claims and a certificate are valid and that the owners are are known. And so what we're trying to do here is to use that well-defined infrastructure for acme to be able to validate another type of claim.

B

And this is preferred over using some ad-hoc mechanisms that that are manual or require some nuance about. How do you? How do you verify security uh all the things that acme already does properly so next slide?

B

B

So the concept here going back to that analogy to um email, the concept is, is very similar and I even lifted some of the nomenclature from the s mime, acme validation mechanism. So the idea here is that the the bundle protocol has two different top-level types of bundles. One of them is a service payload, and one of them is an administrative record.

B

So what we're doing here is putting this data into administrative records, meaning it's not normal service data. So the idea is that one bundle goes out from the acme server, which is a challenge. Bundle with part of the token that's necessary for validation.

B

The acme server itself provides the second part of the token and then ultimately, when a node receives the challenge, bundle and communicates with the acme client about the the challenge existing.

B

Then it will do the normal processing uh again, the same concept as the email draft uh to generate a key authorization, and it sends a response bundle back to the acme server.

B

um So that's the the core of the situation and there's also some information in the draft that talks about uh using bundle integrity to sign the individual bundles. This isn't strictly necessary in the sense of making sure that a claim can be validated, but it is useful to be able to make sure that bundles pass through. Maybe if we're talking about the this is because we're talking about acme, it really is targeting a an internet type open network. So um we don't want to have implicitly trusted bundles.

B

We want to use bundle security to make sure that the bundles are able to traverse ultimately to the destination and then back to the acme server.

B

So next slide, please.

B

So all that being said, um this draft is marked as experimental, uh because uh not that dtn itself is experimental, but the use of acme to cover this use case is new territory um and also, although uri claims in certificates and certificate requests are not new.

B

um The use of acme to validate a uri is new behavior and the uh the proposal here is not that we would expect all acme servers to be able to do dtn, node id validation, but to say when you need to do uh validation of a node id for security purposes. Here's the right way to do it.

B

So I leave this open then, to questions to the working group about the.

C

C

Hi hi brian, uh I had a quick question. I I don't know if I understood what you were kind of saying exactly so is the thinking that you would have the dtn overlay and then the acme servers that the dtn nodes are trying to reach or on the public internet versus an acme server, that's somewhere in the in the dtn fabric, but that's more of a closed network.

B

So the the original concept was that, if, if you're on a relatively controlled closed network, that you wouldn't need to use an acme type mechanism to uh to just to issue and distribute certificates that on a on a tightly controlled network, probably the certificate authority is integrated with the node configurations and there's some back channel method of of distributing certificates.

B

The the rationale for using acme in this case is for those situations where the certificate authority uh doesn't have that back channel of uh validating things. So the the use case here is for situations where um there's a certificate authority that is issuing certificates to uh you can think of them as gateway nodes that operate over the internet. So multiple sites have gateway nodes and these sites don't have uh necessarily trust channels to each other.

B

So the intent here is to be able to have a I'll say a public ca. It doesn't necessarily mean a public in the sense of the the um anybody can use it, but um just that it's doing validation over a untrusted channel.

B

If that makes sense,.

C

Okay, thanks for that clarification.

A

A

D

Hi uh rick taylor, so I'm actually one of the dtn chairs. um My question really to brian is: what is your intention with the presentation to acme? Is that? Are you offering to put forward this draft in acme as a experimental or informational document?

D

Doing the generic uri claim or we'll just keep this document within dtm? I'm not quite sure.

B

Where we're going so it's it's certainly intended to be kept within dtn. um The the use of the uri claim is new. It just hasn't been exercised before in any acme validation mechanism.

B

So this is a kind of a first come first serve sort of thing, understood: okay, but the the goal is to codify a an explicit and well-defined method to do the job, not that it would be taken up by every.

D

Acme server, okay, yeah understood because I know we have iesg discusses on the the tcp convergence layer that need to be resolved and and acme is a good way to resolve that. uh I suppose my statement to the chairs is, if you want to talk to the dtn chairs, about whether we keep this work in dtn or or whether you want to generalize it and adopt it. I'm absolutely open to having that conversation, and we can take that offline.

A

C

Yeah back again, so, given that clarification about clearing the isg discusses, I'm trying to understand the architecture a little bit more, so the acme servers on the public internet, not necessarily for public use, they would have understanding of the dtn addressing magic that they would have to validate in the uri.

C

Or is this for certificates for the external interface for those gateway, dtn nodes.

B

So the the imp, the an acme server that would implement this draft, would need to be a dtn node participating in a dtn network and have have yeah all of the things in the same way as an acme server. Implementing the s. Mime draft needs to be a trusted. Smtp server, you know with other um other smtp servers using it as a an s mine, I'm not familiar with the exact terminology, but it needs to be integrated with the other s. Mime servers that it's trying to uh validate domains on.

C

Right, no, no, I I I understand now the key thing was I, when you said kind of gateway, I was assuming that it was some multi you're kind of talking about something more multi-home, but the acme servers you're talking about are part of the dtn network in question. Yes,.

B

Yeah yeah got it, but the the intended use case is for those kind of inter-site inter domain.

B

Dtn nodes, where it's the node is forwarding and accepting bundles to other sites or to other domains, and so there isn't necessity there isn't that implicit level of trust.

A

Okay, this is speaking as an individual, so the acme servers are cas and the cas that work for the web. The public web have usually been very reluctant to provide services for things that are not the public web. You know it's hard to even get smtp certificates, let alone user certificates or and pretty much nothing for any other use.

A

So I'm not sure you can expect those cas to provide certificates and or an acme server. That will work with uh this new use case.

B

A

B

With that, and uh that's understood in this and that's why this this last item is that what's being proposed here is the mechanism for when you want to do a thing: here's how to do it and not an expectation that there will be uptake on those web focused acme, servers.

E

Yeah we have the the tn auth tn off list stuff, which is unlikely to be part, hopefully not part of the web pki. It is going forward, for uh you know mobile phones, um so we have. We definitely have precedent within the working group and you know: we've expanded the charter to have a bunch of different challenges.

E

um My inclination would be that if you know, unless dtn strongly wants to own this, you know we collaborate, but I think it makes sense. For you know if the working group would choose acme to be the home for this.

D

So rick taylor, again with my dtn, chair hat on dtn, if I'm honest, is quite a small focused working group, so we not sure we have the bandwidth to handle this without constantly asking the acme working group for advice. So if you want to work on this in acme, we would be very happy.

B

And from my perspective, it's also quite convenient that the scope and the mechanisms of this validation method are so so similar to the s mime, one that they really have all the same bookkeeping and the same really. Security.

B

A

So rich, do we want to try the hum tool for the for this.

A

And I can't hear you at.

A

C

Should we ask how much familiarity we have? The working group has with this document? Have folks read it looked at it.

A

I think we know the answer to that, but I'm willing to ask that question as well.

A

Okay, let's try this so I'm going to start the hum and hum as loud as you can. If you have read or are familiar in some other way with what this document is proposing, I'm starting the hum now.

A

And unfortunately I haven't prepared any canned music. You really don't want me to sing so I'll spare. You.

A

A

Which means not very many hand and or not very loudly so with that I'm kind of reluctant to um ask about adoption, and so I guess please read it and then we'll take it to the list. Yes, alexi has something interesting to say. So, let's see yes, alexey.

F

Yeah, I'm just uh maybe ask who is willing to read and review the document. Even if people haven't read it.

A

Okay, what I do know is to never do that on the hum, so uh please type it plus one in the chat room uh if you're willing to read it within the next. I don't know month or two so that we can then do, and I see one two three.

F

I can add my.

F

A

Yeah, that's cheating, rich okay, so we've got about five people in state they're willing to read it better than nothing. Okay, so please read it and we'll ask on the list in a month or so whether you think it's worthwhile and then maybe we'll do a call for adoption.

B

All right, thanks for your time,.

A

Anytime, okay, uh so with that, the next thing is owen: with acne subdomains: let's come up to the mic.

G

Virtually first.

A

H

Can you hear my audio.

A

H

Okay, so this is an update on acme subdomains and we can flick onto the next slide straight away.

H

It's just a summary of product misadmins is about um the baseline acme rfc allows an acme server to issue search for a given identifier for a subdomain without requiring a challenge to be explicitly fulfilled against an identifier.

H

So in principle an acme server could issue a search for a sub.domain.com where the acme client has only to fill the challenge for the parent's domain um and an acme server could issue search for a large number of subdum inserts and only require a single charge to be fulfilled against apparent domains. This is nothing new here. This hasn't changed since it of 106.. So next.

H

H

Okay, so again, this is just a summary um of the of the call flow. What are illustrates on the left-hand side is an acme client doing a pre-authorization for appearance domain that I've simply illustrated as domain.com.

H

It sends in a new authorization request. Domain.Com gets back to list of authorization, challenges and fulfills the dns text and challenge um and then pull pulse to challenge response and verifies that that's verified with acting server.

H

Then after this pre-authorization has taken place, then it illustrates the client on the right-hand side and step two placing an order for a sub-domain of that parent domain, and the illustration here is just doing um getting a cert for one sub-domain, but there's no reason why a client couldn't continue and um request certificates from multiple different sub-domains after appearing to men, while only completing one pre-authorization for the parent main next slide.

H

So what's changed since 106 and draft zero one and there's some my comments that I and there's some chatter on the mirror since then as well- and those three comments have been addressed. First is uh what this drafter 2 defines. Is a base domain boolean field in the authorization object to explicitly differentiate between an authorization for a apparent domain versus an authorization for a wildcard.

H

uh The second there's a bit of confusion, because because the example I just went through discussed pre-authorizations, but the confusion in the text that this is uh limited and restricted, they're just pre-authorization, but that is not the case, so I'll try to clarify the text.

H

This works for the pre-authorization and explicit authorization inbound as well, and finally, um there's a bit of confusion as well in the matters as to whether this was just applicable to see a browser forum or based on requirements, and it's not is generally applicable to acme and similar to the acme based rfc.

H

um The draft doesn't really state anything explicitly about ca policy, so it could be applicable to cas that confirmed to see a browser forum baseline requirements, but it doesn't necessarily have to be used by those servers. It could be used by different cas that have their own policies or could in fact be used by private cas or iotcas.

H

uh I think next slide. That's it.

H

So next slide what's missing. Is uh security considerations has been missing for a while almost chased tim hollaback on this, but he had um agreed to write this at one of the last itfs and that's the only update the update was just to address your comments from the last time around.

H

um So is there any interesting going next steps here? Is you're interested in an adoption call um or any other open questions around the other? Well, first is standing on red draft two that have tried to address the three. The three major comments at itf iqf106. So any.

G

E

Just a minute to point, as the agenda points out, we had intended to issue the call for adoption. The last time we met face to face my mistake in letting that fall through the cracks.

E

um So there are two questions I guess has any how many people you know who has read the draft who is interested in progressing it working on it, and then we should this time for real. Do the call for adoption and confirm on the.

G

B

A

So we got a couple of people willing to review in the chat room and that's the classical meaning of two.

E

A

I guess, since we were anyway going to do a call for adoption, might as well do it and hopefully more than three people will answer yeah. We like the idea and willing to work on.

A

It so bottom line we'll take it to the list.

A

And with no further comments on this one, I guess we'll move to the next one, which is also one.

H

Okay, so a quick update on acme integration, so we can go straight to the next slide straight away.

H

uh So what this does it just describes. What this informational draft does just describe how acme, based on acme, can be integrated with multiple different, existing client or device certain mechanisms without requiring any changes to the baseline acne specification whatsoever. It just outlines some informational use cases where acme is really really useful. So next slide.

H

So so these are the four main use cases that we've outlined that are captured in the draft. There's a slight update to this on the next slide, but the four main use cases are actually integration with est acme integration with brisky, um which is boot tracking remote key infrastructures.

H

Ask integration our acme integration with a brisket cloud registrar, which is it's risky cloud registrar? Is it's a it's a subset of brewski that what the cloud register defines is how um how the default mode of risk operation when it comes across for a network does not have a register register deployed in the local network. A device can fall back to a cloud register and what risky cloud register does is fill out some details that are missing from the baseline risky draft and finally tip tunnel deep tunneled extent, extensible, authentication protocol.

H

um What I have here as well: I've referenced both t4 of c7170 and a draft that um elliot lear, and I are working on a an emu draft clearly brisky. um Well. Actually, if you go on to the next slide, explains this a little bit more detail.

H

So, what's changed inside tf 106 is the deep and two brisket sections of uh acme integrations have been collapsed into one section, um because what baseline cheap?

H

If you read baseline tape in detail, it's missing some very important uh search, enrollment capabilities that that eric and I have worked to introduce and draft layer, ept briskey, um so we're actually refactoring the t-pop that draft a little bit to focus less on the risky part and more on the certain enrollment parts and two key things that uh that um draft clear et briskey defines is csr attributes tlv, which allows a team server to give instructions to a client and what attributes it expects that client to include in the certificate enrollment request similar to est, and the second thing that the update does.

H

Is um it specifies it a retry interval? So if the server is willing to issue a circuit but isn't able to issue the search straight away, then the server can instruct the client which right after suitable timeout, which is very similar to east enrollment as well.

H

So so these two attributes are missing from baseline t and they're, pretty much essential for doing an integration with acme, and so that's one of the reasons why I've slightly refactored this informational draft to um collapse, the tape and the tip update or the deep risky sections into one section, and I it probably does not make sense to try attempt to integrate acme with baseline, keep at all, um because I think we need the csr attributes glv and to retry tlv for active integrations to be successful like, for example, if the acme server replies with some kind of timeout saying your certificate enrollment is pending, there's no way for a cheap server to turn around and tell a client that your significant romance is bending.

H

um So that's the that's the major dra major change to the draft. Since 106, we just um simplified a little bit and collapsed two sections together. So next next slide. Please.

H

uh The security sections secure consideration is still to do, um but this will be as this is informational and we're not making any changes to any of the the drafts we're referencing it all. We don't expect this to be controversial at all and we're certainly making no changes at all to the reference um security consideration, sections in est, brewski or team.

H

um The the two other drafts will reference the deep update draft, the draft lear, ept brewski and the risky cloud draft as well either the security sections for those are either not complete or they have not been formally reviewed yet, and so I think, we're in our minds we'd like to wait until the security considerations and those two drafts have been finalized and reviewed before we just write and complete the security consideration sections on this information draft, but even saying that we don't expect any controversial here, we're not changing the behavior of any of the reference protocols, we're just stitching them together.

H

So we expect the um security consideration sections just to be a short summary of the of the sections from the other drafts um next slide. Please.

H

uh So we've had limited reviewers on this. Yet um but again it is just information, stitching existing specifications together and not changing them at all, and so what we would like is if anyone on the list is willing to review this running on. The list is willing to provide feedback on this draft and then um michael and rifa, and I will gladly incorporate that feedback.

H

H

E

Oh and I assume, through participation or your your author participation and um have you actually, you participated with the other groups, but have you also reached out to them and got feedback besides, just your sort of authors.

H

Yeah we've uh we have presented this at emu as well, um and they we presented this emu. uh We didn't didn't presented this time around, but we presented our eu 106 and uh we got some feedback for well. Actually, when we presented redeem is one of the reasons why mike brickson is now a co-author, because he was very interested in participating best in singing and we've had some um feedback from elliot lear and some feedback from dan harkins out of emu as well. On.

B

H

And we've incorporated so that could that feedback was probably in private or back channel conversations. It wasn't the matters, but we've we've incorporated feedback from you with the draft already.

E

Okay, that's good, um so it sounds like you're. Not. I don't think it's ready for adoption yet, but it occurs to me that if we do adopt this information, would I think, it'd be the first published informational document um and that we would make a point of reaching out to the others working groups and asking them to review it too.

H

Well, I think this one was, but this one is an itf draft. This was started actually last time around, but we just had a limited number of our concrete reviewers to it.

H

It was just optimism that wasn't the doctor, but this one actually was, and we did have discussion at 106 whether this would live in you or whether this would live in acme and we came to inclusion or maybe that was at 105. but 105 or 106. We we discussed between emu and acme in atlanta and acme.

E

Yes, thanks for the remind the reminder: yeah, um okay, uh so could people any folks who have read this? Could you please do a plus one in the chat, we'll do the same thing with this, as we did with the previous one.

H

It's it's informational, there's nothing controversial new here and there is working code behind this. um I know michael has just mike richard. Has this working already, because one of the reasons why he's eager to jump on and go authors.

E

All right, so we do have some interest, and you have mentioned that the other groups have been looking at this. um Maybe we do time to review call for adoption.

E

You know a week before we do the other, your other draft, since we want to keep them separate, and this one might be further along and simpler to progress.

A

And you can encourage people who don't normally come to acme meetings, to read it anyway and send something to the list. That would also be great.

A

So uh if there's nothing more, I think we can move on to onion routing and roland. Thank you.

A

I

um So this uh draft was mainly um instigated by the fact that the ca browser forum has recently changed. The validation rules for onion addresses, so previously, onion addresses were only allowed in ev certificates, which meant that there was very little interest to have any kind of validation mechanism in um acme, since otherwise ev certificates basically impossible to do via acme. Currently so now that they can be included in domain validated certificates, um it seems like there is some interest, speaking as a representative of a public ca to issue dv certificates containing onion addresses.

I

So this is basically the the draft currently includes a validation mechanism. That, basically, is a mirror of the um existing cab forum, validation mechanism um and a quick explanation of that mechanism is basically that the v3 onion addresses are essentially just encoded.

I

Ed 255 19 keep public keys, so the um the mechanism is quite simple: you you create a csr that contains a nonce provided by the ca announced provided by the non-provided by the client, and you sign that csr using the um the private key and then the ca simply verifies the csr using the public key and the address, and the document has has left out. You can also do validation simply using the existing change tool website website.

I

Validation mechanism, which is in in 8555, is http 01.. I haven't specified usage of that mechanism simply because again speaking as a representative of public ca, we don't really have any interest in uh running a tour stack in our or anywhere near rca.

I

um You know, I think some some cas may be interested in doing that, but we we want to stay clear of that.

I

So if you want to move on to the next slide,.

I

I think that there are two kind of big open questions with the the document as it is written. The current validation mechanism is rather complicated. um You know the use of a csr is. This is an artifact from the previous version of onion addresses where which were used essentially using uh rsa, 1024 keys and and truncated sha-1 hashes.

I

So the the validation mechanism was kind of over constructed to try and get around some slightly dodgy security properties and using those keys, and that, as was discussed on the list previously, it turns out that actually, the attempt at performing hash strengthening actually doesn't work, because the way the two um server and client provided nonsense end up being ordered the the server nonce always ends up being the prefix. So um there is still some uh weakness there.

I

If we were still using um rsa 1024 keys, I you know, I think it would be nice to try and define a slightly more simple mechanism that doesn't have these kind of workarounds for security issues that no longer exist with ed 225.19 keys.

I

But it's it's not strictly necessary in order to get a validation mechanism that is cap forum, approved and then the other question is right. Do we want to specify usage with http 01? um You know, I think, if we did that you know it would probably warrant some discussion of a security consideration. Section of you know how closely you want your your validation stack to be uh to a tall stack, but right. This is probably um more of a policy question for a ca. Then it is something we can strictly specify.

I

uh So if anyone has.

H

Any questions I.

I

Would be uh interested.

B

In hearing them, I.

I

Think there's been a bit of discussion on the list, but uh right. I think that the only interest from from cas that I've heard is is from lexicrit, so uh interest from others would be yeah.

I

A

um Rich, I think you said something, but we didn't hear anything.

A

A

A

I'm still not hearing.

A

A

It's true because I do see the microphone icon next, to your name, but um not getting.

F

C

C

Yeah, I'm not seeing the mic in front of rich's name anymore,.

A

C

Mean maybe drop it on jabber, while we sort it out.

A

So, while we're doing that, um okay and just repeat what has been said in jabber- that uh which got it wrong and the integrations draft is already about working documents. So there's no need to do a call for adoption, just read it and then we'll decide if it's ready for working with plastic.

A

So what he's saying now is we're just asking the working group for input if anyone wants to say anything, that's about onion.

A

Rodding and the silence is deafening.

A

um Okay, let's do part of that. This is really all we had planned for this meeting.

A

So anyone have anything to say about onion addresses and that.

I

I guess just to kind of give an uh an example of what this likely would be used for, I think in the current uh current ca ecosystem. The most common use case is that you would create a certificate containing both a dns name and an onion name.

I

So one very popular example of this is that for the facebook hidden service they have a certificate that contains both facebook.com and the hidden service address, and there's been some discussion within the tor browser community about trying to use this as a way to uh essentially bind these two names together, so that you could be connected to the hidden service, but the the url bar might actually show the dns name rather than the hidden service address um and rich.

I

I I the name sounds familiar, but I I don't think I have uh talked to him specifically about this. I think that would be a good idea to reach out.

A

The question is alex muffet, which is suggesting that we reach out to you and he'll send an email, okay, um and if that's all, we have then.

A

This slide is there any other business.

A

Okay- and I guess we all- got um almost 50 minutes of our lives back.

A

Hey, thank you all for coming and um hopefully next time we can meet closer together. Well, not next time, but the time after that, hey. Thank you.

A

All yep stay safe and healthy.

A

And thanks to euron for taking notes.

A

Thanks for waiting at that.

A

A