Internet Engineering Task Force 108, 29 Jul 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF108-COSE-20200729-1300

Description

COSE meeting session at IETF108
2020/07/29 1300

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

A

A

B

B

C

All right, uh hello: everyone uh welcome to the cozy working group session for ietf 108.

C

um If you've been here, you've probably have seen this, but it's important to call out. The note well um reminder that it policies are in effect here, and this includes code of contact and and uh patents.

C

So we're going to take care of some administrative things here. First, thank you francesca for volunteering. For note, taking um is anyone willing to jabber scribe? This is if somebody can't speak, for whatever reason to be able to bring that to the.

C

C

Is that michael richardson.

D

Volunteering, I think so.

C

Yeah. uh Thank you michael for volunteering.

C

All right um and anybody that's willing to help uh francesca. That would be great. um I believe that the link is, uh if I go, provide the link further further up in our uh jabber chat, um a couple of meat equipment tips. That chairs have found helpful.

C

If you do want to cue it, the mic make sure you always request audio. You can request video if you like, but make sure you at least request audio. um If you are speaking, please first state your name: it's not there's no other indication um immediately available for everybody, um and if you are taking your tracking notes, it will be helpful to open them in a new tab or window.

C

That way, you can still see what's going on and be able to get back to hums.

C

So with that out, today's agenda we're going to go over the document statuses. um This also includes a quick uh um comment with uh jim to go over um an issue with this. The 8152 struct um then we'll hear about certain compression, uh more algorithms and wrap up with chartering. um Is there any bartering over this agenda or any changes that are desired.

C

All right uh well, then, moving on.

C

So, moving on to pointing out some documents uh that have already progressed so um cozy hashtag is has been published since the last time we all talked um and the web authent algorithms is currently in the rc editor review.

C

So this, if I'm remembering the state correctly, the next stage here is off 48, so we're moving right along um a document. That's with our area, director is a cozy x-509 requested publication, we're awaiting a b review before we move on to iesg and ietf. Last.

C

Call see things that are still with the isg are an ietf last call, so the um cozy hashtags um that murray graciously took over um looks like it's approving once we've gotten a revised internet draft, it should have approval, um there's a revised published waiting, ap review approval and uh whatever the outcome is of um 8152 best struct, which there's an outstanding discuss that we will be talking about here very shortly.

C

That is, then all the documents that we've had chartered for this group so far.

C

So if there's any comments, questions.

C

Okay, um jim, I think we are ready to talk about the structure, discuss.

E

Okay, so it took about four weeks for me to to figure out exactly what uh jean-marc was talking about in terms of what his discuss was, um but I actually finally figured it out, and I agree that it's something that needs to be dealt with so next slide, so this is basically going to be kind of a recap of the message I sent out, but with some colors and arrows to make things easier to see.

E

So the way things are set up right now, if you get a real counter signature, you take the protected attributes from the thing you're kind of signing and you take the cryptographically changed content whatever that means, and you combine those two things together as part of your counter signature creation process.

E

So this is true for both of the cozy encrypt things, uh the cozy recipient and the cozy signer, where that is actually really cryptographic, content that is in that field. Next,.

E

Slide there are, however, a couple of structures where that content is either effective. The content that we're looking at is actually plain text content, or so it hasn't been cryptographically modified and for cozy signature.

E

There is no cryptographic content, so the best thing you can do with that is to.

E

Is to um basically create a parallel signature, um but for the max and cozy sign zero, there is actually cryptographic content. That is part of the structure. It's just not the third element in the structure, so you actually so right.

E

Now what we do is we always generate what is essentially a parallel structure for that, and we say that is true for signature, and we say that is true for both of the max structures, but we don't say that that is true for the cosy science zero structure, and that is, that is what the discussion itself was actually about was the fact that cozy sign zero did not say it was generating a parallel structure. It implied it was creating a counter signature next slide.

E

So we've got a couple of options, one of which is to change the definition of the counter signature algorithm so that we actually always include some cryptographic content that is in into that into that counter. Signature processing algorithm. If there is any present so cozy's signature, would still basically produce a parallel signature right because it doesn't have any cryptographic content, but for the both at the max and for cozy sign zero.

E

We could, if we change the algorithm to include that cryptographic content, we can produce a real counter signature type structure, how beneficial that is for max. I don't know, but it would certainly be more what people would expect in terms of the sine zero.

E

So if we change the counter signature algorithm, we basically have two options: option number one is to include every bister object, which is in the structure and option. Two is to include the first and the last under the assumption that the last one is always going to be counter is always going to be cryptographic, content and the middle one would be probably not cryptographic content so including all of them is an extremely aggressive thing.

E

You're, not only your sister for you'd actually be signing the plain text message, as well as the cryptographic content, which is unusual, but it is functional, including just the first and the last has a potential of a problem in the future.

E

um If we define additional, cosy structures which have which don't put the cryptographic content last or have multiple cryptographic contents that you may want to sign. So, for example, there is some discussion- and I haven't still have not figured out in the cfrg working group exactly what their the the the.

E

There's a document about doing some type of content, plus message, distribution in the same concept somehow, and I never figured out exactly what that document was, but I could see that document potentially ending up as a cozy structure, where you have both the encrypted content and the key distribution objects as separate fields in a cozy structure, and at that point you would probably want to include both of those things in your counter signature computation.

E

Thus, the reason why I put in the include everything um the other the other problem with it is, you may end up with things which are not interesting but are still wrapped in bisters, and since they are not interesting, they potentially could be modified, and that would break the counter signature.

E

Does anybody have any questions about what I've described at this.

C

Point um well ben jumped straight in and we'll give him an option and then corn.

D

F

Okay, uh sorry to jump the queue this has been k-duck um jim. Could you uh perhaps after euron asks his question? Could you just reiterate what the drawbacks are would be for including all of the beasters.

E

F

Okay, uh you're on please go ahead: okay,.

G

Thanks your answer so this, um so you there's just one thing, I I I noted in the in your mail there. You don't want this to be individual per struct. You want to have the same structure for all, because because you want to be able to pick up the fields and verify the signature before or what what? What is the reason for? For that.

E

um Having a single algorithm, one makes things simpler, yeah.

G

E

And um just because you have a single thing you can implement and two means that you don't have to actually deconstruct and figure out what the base object is before you start either producing or verifying the counter signature so that it's the processing is exactly the same, whether it is an encrypt structure or a recipient structure, and potentially the only way you can tell the difference between those is to pull apart the protected attributes and look for an algorithm identifier.

G

Yeah yeah, I can see I can see the advantage of that, but that is an option also to allow differences between difference.

E

Yes, that would also be an option: okay, um ben the drawback is not in any of the structures we have defined today.

E

The thing I'm worried about is potential structures defined in the future, where you might have.

E

A beaster which wraps something which is on which it was intended to be unprotected, as opposed to as opposed to protect it. um There are a couple of different ways that that could be addressed.

E

uh The easiest one is would be to tag it so that it is all so that it does it's not a beast or it's a tag to be stir and therefore you would know not to include it.

E

But if someone defined a new, unprotected attributes type thing and wrapped it in a beaster that would suddenly give you the potential of breaking counter signatures. If that, what was intended to be an unprotected structure became part of the counter signature content signed content.

E

Does that make things clearer.

F

It helps yes, so it seems like, regardless of if we choose the first or last or if we choose the first and last option versus the all option. We still have to worry about future proofing against any new messages that are defined in the future.

E

F

And so in some sense that becomes a question of fail, safe versus fail open, uh although I guess the example that you've just presented is not exactly a fail safe when you include the all the easter option, but it seems like anybody who is defining a new message. Type in the future might be expected to read some spec or look at the registry or something or have a designated expert review. That would be an opportunity to point out that if you do want your attributes to be unprotected, you should do the tag easter.

F

So that would sort of be my inclination to do the thing that is feeling safe most of the time and give guidance to people to avoid the place where it's the wrong thing and how to do so.

E

Yeah after doing this presentation now, I think that is probably a much easier method in terms of describing things um next slide. Please.

E

Okay, so this was basically the slide I wrote up to say now. I want you guys to tell me what I should be doing so basically, I wrote it up is as two hums that the chair can run um or I can run take your pick.

C

Well, the chairs will have to click the buttons true.

D

H

So um when you say change, does that mean you would change the interpretation of existing structures or does it mean you would put in something new and deprecate the old.

E

It would mean that I would change the current algorithm and any counter signatures that have been computed for the max star or the sine zero structure would be invalid.

H

So again, when you say change, do you mean actually change or do you mean deprecate and put in something new.

E

I mean change, I will I intend to change the current thing, not to define something new.

H

Okay, so maybe we should discuss that option as well.

E

That would make sense.

H

So the the reason I'm asking is that we have a hard time knowing what people are using cozy for outside already.

H

um So I think just adding another counter signature which the working title of which would be counter signature done right um and and leaving the old india with the deprecation notice would be a fully backward, compatible way of handling this.

E

H

So, what's the cost of doing that.

E

E

The cost on that is, we define two new counter signature attributes and we document the current one is saying it produces. A parallel signature for sine zero potentially gives oh and, and then we mark the current ones as being deprecated, don't use. We don't want to use these.

E

New tags in in the in the table would have to be defined for both of those um but they're just but they're they're unprotected attributes in both cases. So that's a simple change in the registration.

H

E

um You do end up with a little bit of potential confusion with people who are using counter signatures today, I'm not exactly too sure what we do with, for example, the oscore document in core, because it would be using the deprecated counter. Signature algorithm.

H

Yeah, so so, do we have the power to to retroactively fix all the other specifications that are using cozy by by changing the structure or should we do the new tag.

E

Well, the problem with oscore is: is it's not even using the tag, so it's got to actually specify which one it's using now it turns out. It doesn't make any difference, because it's good on the encrypted structures, the new and the older can actually be exactly the same.

E

But I don't know if there's somebody else running around who is going to be in the same.

A

H

Okay, I think I'm still on the side of adding something and deprecating the.

E

Old okay, so let's go ahead and make it three hums then does that make sense to the chairs.

C

Did the chairs go.

E

C

In this format, I will grant you that.

C

um This chair thinks that that makes sense. um I one question going into this myself. This is matthew miller by the way um with so. To reiterate this, this problem is, is really with the sign. The sign zero because of the lack of of all the context or correct.

E

Yes, although it does also affect the max okay, correct, okay,.

C

Okay, um I think it makes sense for for us to have free hums, which, to reiterate, is leave things alone, um and by leave things alone, we really mean.

C

Document that using this for max m4 sign, zero doesn't have the it doesn't, have the um the intent. You think it does.

C

um Work on excuse me, work on a um this fix or deprecate the current one and like either make the full change which would break exist, which could break existing implementations or have this parallel, one that would ultimately deprecate the existing. Is that all correct that sounds correct.

C

Okay, okay, um so let us start then: oh.

E

C

E

You deal with people in the queue yes.

D

What's up, please go ahead.

I

Yeah thanks uh is the microphone working. Yes, yes, it is great. Thank you um yeah. I may be um talking across purposes here, looking back at a couple of ben's comments, but some of this some of the difficulty that jim was describing seemed to me to be that you might, you might try to counter sign stuff that had not previously been signed and that therefore signing that unsigned data might result in a um in leaving data that could be changed subsequently, resulting in a subsequent invalid signature.

I

So I guess the first thing is: have I understood that correctly or have I set off on the wrong foot to start.

E

With I believe, you understand that correctly.

I

Okay, so then, um uh when ben made a comment at one point, um discarding inauthentic data before starting to pause. It is a common mechanism for robust implementation, so that that sounded to me like the basis for a possible um approach here, which was that if you, if you have a string of data, some of which is signed and some of which is not- and you want to apply a counter signature- is it viable to say you should discard all the data from that stream? That is not signed and only countersign. What you're left with.

E

The issue that I can see with that approach is that I believe you would need to know what structure you were dealing with before you started doing the counter signature processing.

E

Otherwise, you would be unable to determine which pieces of data you should discard.

I

Yep, okay, so this seems to me then there's a general problem of deciding the scope of what it is that you must counter sign.

I

So, as so as not to leave yourself with the problem you described where someone subsequently modifies data that was not cryptographically protected and the counter signature becomes invalid. As a consequence.

I

Yes, okay, thank you.

E

Are we ready for homes now.

C

I think we are okay, so I'm going to make sure that uh everybody, so there just point out. There is a note that they're in the interface there is an extra tab on that right on that left side um for the home. So once we click start, you will have 35 seconds to enter your choice of either low, hum or soft tum or loud hum. You don't want to hum, don't click anything and you'll be fine.

H

um Yep the problems are in the kodi md right, because the homes on the side are no longer the right ones. Correct. Thank you. Yes, fat.

C

I don't have it open. I apologize.

D

Okay, so if you want, I can read it uh first, this leave things alone and you.

D

C

Okay, so this is what we have so far. Yes, we'll probably need to read it, because my screen is.

H

Let's draw plus a couple of.

A

C

Here we go: is that better for everybody.

E

C

C

So how so the first time you'll have is leave things alone and which means you cannot counter sign. Sine zero also might have effect on max.

C

Hum2 will be to fix it so that counter sign zero works. The cozy sign zero works correctly. um This which could break existing implementations.

C

Or hum3, which is fix this by defining a new algorithm and deprecating an old one,.

C

I think there is going to be details if the choice comes. There's going to be some extra details, we'll have to work through with with the results of home three and hung two. But let's, let's start, let's start with these first three, so we'll start again um hum in a couple of seconds.

C

If you think that we should leave things alone and document that counter signatures, um don't apply correctly to sign zero.

C

C

C

Okay, this came in pianissimo pianissimo, so uh not the quietest, not complete, silence, okay, so uh the next one is uh fix counter signatures so that uh sine zero works correctly, which could involve breaking changes.

C

So if you, if you like this option, hum.

C

C

Thank you 15 seconds.

A

C

Okay, this one was also canisimo.

C

This will get interesting, okay, so the third hum uh fix counter signatures by defining a new algorithm that takes into account sign zero and deprecating the old algorithm.

C

uh If this is your choice, hum now,.

C

C

C

All right, this option was forte, so uh at least the the dentist in the room fairly strong to deprecate the old and replace with a new.

C

Now I think some questions after arise from this is: how do we want to go about doing this? Is this that do we do all this work within 8152 bis, or is this its own document.

D

Okay, so my call, I would like to speak now.

J

Anything other than doing it in this document, michael richardson. Here um I think a different document won't be helpful because at the most we could say what deprecate the old thing and then we would leave them without a new thing until the new document. So I don't think that's useful.

J

I think we have to clearly clearly uh loudly announce we're doing this. um Maybe we need an ietf last call to make everyone aware, uh but I think I mean at least ace knows at this point. So that's good.

C

Well, I think, regardless this document needs to come back to the working group um and arguably, probably also uh owls. um Actually, I'm almost assuming alex will have to come back also because it will require changes.

E

I'll record any changes, I will have to verify that, but I do not believe that is true.

C

F

uh So I came to the mic just to point out that I don't know the answer offhand, but we'll need to check the details of whether we can go for internet standard while still defining the the new thing.

C

That that is a very good uh point. I I was wondering the same thing myself my my argument.

F

Would be very good, I see, barry is in the room, so he may have some thoughts on this as well. My sense would.

K

Be that if you're making a breaking change, um you have to stay at proposed standard for a while to uh until you think it's mature enough that that piece can go to internet standard.

H

Yeah, so it's good that we are not making a breaking change here and I would classify this third change as fixing a bug and that's definitely something you do on the way from a football standard to an internet stand-up.

H

So the reason why I think this is a good thing to do is that it sends a signal in the document that there is something different that people should be using. But if we put this into a different document, people will just read the base specification and will simply not notice that the other thing is.

L

There hi this is russ. um I think that uh if we put this new feature in the document, which I do believe it belongs in the base document, not a separate document for the reasons uh carson just said, but it means that we don't have the implementation experience with the new thing, so it should cycle it that proposed.

K

I I don't think leaving it proposed for another. Few months is an issue. It's easy enough to reprogress these later.

J

Michael, I think you're saying is that we wouldn't necessarily need a new document, because the isd could act in a few months or uh 12 months or some something based on the implementation experiences.

K

Correct we have, we now have a thing called a status change document and we can just uh move whatever these become. Let's say it's you know, 89.99, um we can just say: 89.99 is now internet standard.

K

After doing the last call on it.

E

I'm going to ask the rfc editor to end it in.

E

C

Okay, um so we'll we can confirm this on the list, but I think at this point it's pretty clear. We need to find something new and it's going to be in this document.

C

And this document, then we'll probably change to proposed standard.

C

Do we have any any beginning sense of what, where we want to go with this yet or is that um like what how like details in this or do we need to set up a an interim discussion.

E

Well, why don't we take the the last hum and and see what it comes out as.

C

Okay, so um the chairs will take the last the the the notes from these hums. Take that to the list uh point out, the the um the strong, uh the consensus of the meeting being to um deprecate the old and replace with a new and then we'll solicit, we'll start soliciting. What what that looks like.

C

H

So we do have to do the last hum if you want to decide whether two elements or all elements, uh I would actually add to this.

H

It might be a third way and we we might find out after the meeting that there is a third way, but it's very useful to hear the center of the room with respect to the full transfers we have now.

C

Okay, jim, do you have any comment.

E

C

Okay, um so so assuming since we are looking at changing things or and hopefully non-breaking, um let's have another set of hunts, so the first time will be. um Are we going to be aggressive with the new counter signature proposal, um which is sign everything that looks like a beaster.

C

If you, if you think that we should so and then the second hum will be be more constrained on what we on, what we put to the signature, um for instance, only the first and last bistro element, although this could change as we we work through the process, um so I guess yeah so um hum. If we, if we should be aggressive on what is um what is signed for this new counter signature. Do that.

C

H

This interface is so stupid if you want to hum loudly at the moment when you click on it, it's showing the number of seconds remaining. So you click on softkey and then you have to go to the other side and say no. I changed it go back. Click on largely just entertaining you, while you're waiting. We are waiting for the run to complete.

C

Thank you, karsten. Okay, um the result of that hum was piano, which is the middle, so this will be very interesting, uh so second hum hum, if we should be more constrained um on what is signed for the counter signature.

C

C

All right that was pianismo, so rough consensus in the room to be aggressive.

C

But I would say if anything, half-hearted.

C

Okay, um thank you, everybody. I think we've got some we'll bring these to the list um we are running way over, but this discussion really did have to happen.

C

Next up is joel talk about the cert.

C

B

So am I on air? Yes, yes, I want lung speaking. We wanted to take this opportunity to quickly present and get some more input on a draft which is been around for a while, but now is updated.

B

So next slide, please yeah that does yeah exactly so. This version is a merger of three previous drafts, and now it's one matt from cozy next.

B

Sorry next slide, please so a very quick background to bring everybody everyone up to speed before we get into the interesting discussion parts just stating our background and our starting points. Basically- and this is to actually care about single bytes when it comes to transfer of certificates back and forth, between constrained iot devices and as a starting point, we have been looking at rfc 7925, which already specifies an iot profile for certificates for iot deployments, and on top of this we add seabor encoding.

B

And by this we can shop down certificate sizes to half in many cases, and we talk both about reconstructable certificates and where we sign the native, smaller structs. Next, please.

B

And, as I said, this is where it actually matters to save bytes. This means that you do not target all available certificates. In fact, we start by 79.25, and then we do even some more further restrictions.

B

uh That is not to say that we should disallow everything else, but the the main focus has so far been the compactness, but there is, of course, open for discussion for some of these trade-offs and that's where many discussions have already happened. Next, please.

B

Yeah exactly as mentioned, the 7925 is the starting point, and this mandates that all involve the keys are elliptic curve type, including the ca certificates, and this is because the iot devices are not thought to be able to handle more heavyweight compression algorithms, and there is also restrictions on the subject type and which certificate extensions that can be used. On top of this, we have done some further profiling to chop down and be able to implicit deduce some of these certificate fields, and we will get more into them into the discussion next, please.

B

So, as I mentioned it's been around and now we have merged these documents, which talk about the format itself and how to add, ayana registry entries to use this in both a quality and a tls context and, of course, uh clarifications and simplifications on some of the details of the encoding that were not yet 100 specified and some of them are still open.

B

B

And understandably, the the overall discussion teams is on the kind of the core target. How eager to say bytes should one be basically how many certificates do we exclude by our assumption, versus how much complexity in the encoding that we want to add to accommodate more of the cases and we're very happy for the discussion that has been happening on the mailing list, with many constructive suggestions and pointing out open issues from a number of participants.

B

We're very happy for this next, please, okay, diving straight into the ongoing discussions in our current draft the issue field of the certificate. We have made the assumption that it can be encoded as a simple seabor map, and that is, of course not true for all possible issues.

B

For instance, it cannot currently handle the repeated attribute types, and currently we cannot distinguish whether the the original type was printable string or utf-8, and so some of these discussions have been about what what are the can we shortcut and make a functions versus? Do we need to encode all of this information and to what degree of complexity?

B

So, basically, at some point here, I I want you to start arguing for your your points of view and or fill in where you think there are. I mean the more neither the details but I'll keep going for the ongoing discussions. Next, please.

B

So another issue is how much to spend how much bytes to spend for encoding algorithm types and parameters where we currently have one integer for signal, signature, algorithm and one for public key info, and this we believe, is sufficiently future proof for our target algorithms to enumerate those that we think are relevant and then mapping back to the 7925 starting point.

B

We have only considered algorithms suited for iot targets, meaning we have not considered our rsa type of cryptos, uh even though this has sparked some discussion on the mailing list for sure there are erisa crypto certificates out there. But our starting point has been that they are not relevant for the type of iot scenarios that we mainly target, meaning that we don't think they are necessarily in this context.

B

But of course this this can be questioned. But we have not seen this as we have not seen it's worth to include in iot deployments.

B

B

Please then, of course, the current draft has a very a simplified encoding of extensions where we don't encode the order, and we also where the extended key usage is a bit underspecified.

B

So here we have had many helpful suggestions on either which ordering can be assumed or how to uniquely how to uniquely encode a specific, extended key usage order. We believe this is this. Discussion needs to continue also on the mailing list. Next, please.

C

Joel, I just want to point out. We are technically over time here and we're about to get all kicked out here shortly. Oh my.

B

So thanks for the warning and then there is an ongoing discussion on extensions, further extensions, whether ca certificates could be included or not, and how to handle that.

B

And finally, next, please, whether this is more terminology, whether it should be called certificate compression or only stay as a tls certificate type and all of these issues we had some input which we are investigating, but we are very happy to have an ongoing discussion on the mailing list.

C

All right, I think your last two slides all right, so any any quick clarifying questions we have about. We have less than two minutes.

C

All right, thank you very much, joel, um we'll, take further comments on the list. um Sorry, uh jim, that we could not get to the next one, but I think you may have a lot of work ahead of you anyways all right um unless there's anything super pressing. I think that that concludes our meeting for today. um Thank you. Everyone. Thank you again francesca for taking minutes. That's tremendously helpful um and we'll see everybody on the list.

D

Yes, thanks francisco.

C

One last thing: if you have more alex, tell jim or the list, preferably the list. Thank you all.

A

A

A

A