Notices by Jens Finkhäuser (jens@social.finkhaeuser.de)

Trust your instincts with people!

This is triggered by a post from a friend, but is also something that happened to me not so long ago.

There's a guy I know IRL who is terminally ill. His little daughter is our son's best friend, so we try to support all of them as best as we can, which is very little.

He's got good and bad phases in dealing with this, which is a very euphemistic way of phrasing his struggles. I think any attempt at trying to understand how he feels is going to miss the mark.

So the other day I was driving home from an errand, saw him by the side of the road, and nodded to him in greeting - there wasn't really time to stop and chat.

I arrived home, and couldn't shake a weird feeling I had. I couldn't quite explain why I had it. But I pulled out my phone to message his wife. Didn't get a response.

By that time I understood why I had a weird feeling. He'd been sitting by the road in a fairly relaxed kind of way. But it was the location he'd chosen: on the guard rail.

Nothing strange about sitting on a guard rail, except this was the guardrail of the road that crosses the motorway here. He'd been sitting on a bridge, staring into space.

So I jumped back into the car to have a chat with him. Barely underway, his wife called and apologized for not responding. No worries, I interrupted here, are you missing your husband?

"Yes, no, kind of, what's going on?" - "He's sitting on the bridge!" - "Aah, don't worry, he was taking a walk and probably overdid it again"

Fine, OK, I get that.

I apologized for the panic, we talked it out a bit.

But the key thing is: she immediately understood why I had an odd feeling. It didn't come out of nowhere, it had good reasons.

Nothing happened. He's in a positive phase. He went for a walk, overdid it, and rested where he could sit for a bit. It just happened to be that bridge.

But the feeling was valid nonetheless.

If you have a bad feeling like that, it likely has a reason, and reaching out can make the difference.

... it's no longer enough to resolve names to IP addresses, you also have to resolve to choices of transport protocols.

With encrypted transports, you always have a key exchange to deal with, which can be slow.

The TLS issue is that you have a TCP handshake, which exchanges three packets. Once the TCP session is established, you have a TLS handshake, which is also three or more packets. QUIC adds key information from the start, so you only have one handshake that combines both purposes.

So...

... what next can you optimize? You can put the key exchange even further up front, which may speed up the QUIC handshake.

And that only leaves us with DNS as anything that comes earlier. In addition to IP addresses and transport choices, now folk wish to put keys into DNS as well.

Which may be fine with small Edwards keys. But several KiB of post quantum cryptography key won't fit into a DNS message, which is in practice bound by the size of a UDP datagram.

So what then - we can't do DNS...

I kind of want to write up my #ietf121 experience, but I don't think what I would write will impart the meaning it has to me unless you are me, which most of you are not.

I went there for #DNS reasons. I did not take part in all of the DNS related working groups, because I am at this time most interested in networking and figuring the organization out better. That includes specifically the people involved with DNS, of course, but not exclusively.

Let's focus on DNS first.

I'm glad the BoF...

... for the Restful Provisioning Protocol went well! The charter is up to see at https://github.com/SIDN/ietf-wg-rpp-charter/blob/main/rpp-charter.md

It's driven by SIDN, but my colleagues are also in favour, so it was good to see overwhelming support for developing a more modern protocol for domain provisioning.

Other DNS related working groups made more sense to me after I just sat in them.

That's generally my approach here. It seems like reading charters gives you the stated intent, reading drafts reveals more about how things...

... discussions on that topic which try to disambiguate a bit what that means. In the years before, it felt more like the different views on centralization led to arguments around whether the problem was more economic or political versus technical.

The view that seems to be emerging is that it's both, and we need to understand how technology and politics influence each other here. I think that is very hopeful! Because at least a fair number of people now have left behind the knee-jerk...

... work, but attending the meetings gives you a much better impression of what everybody wants. That then provides the context for interpreting the fuzzier bits of charters and drafts. So that was very useful!

The other big takeaway for me was that I made some kinds of friends along the way, that I didn't quite expect. A lot of the times when you meet people once a year, so much happened between events that context is lost, and you have to reacquaint yourself with the other person and vice...

... reaction of "not wanting to politicize tech". More now accept that the interaction exists, and that we can shape tech somewhat to help or hinder certain political developments.

The human rights policy considerations group may not have much direct influence on many protocol designers, but I feel they have paved the way with the guidance they issued for taking certain effects into consideration.

They're now focused on the more specific interaction between tech and intimate partner violence.

... versa.

I can't list all the ways in which this *wasn't* necessary, but I do think the puzzle table tradition stands out.

Last year in Prague, the organisers put up a table with a puzzle, which stood around unnoticed for a few days. At some point I asked what that was about, and was told it was an experiment, to see whether people liked working on it together. That led to me becoming one of the first #IETF puzzlers.

It also was where I met someone whose company I joined half a year...

The two key takeaways I have from that, which I think are excellent, is a) IPV as a specific type of human rights violation is a topic that still needs to land in people's head on all sides. A lot of the time, human rights seem to be treated as relating to state level actors, whilst IPV is a personal matter.

The interesting part here is that in my estimate, the focus on IPV and tech now actually seems to help engineers understand better what people mean when they talk about human rights and...

... later, so you can't quite deny the networking effect.

Not only has this tradition continued, it apparently is now the case that other standards organization also put up puzzle tables. It's small things like this which created an instant connection between myself and a number of relatively random other people in the IETF, which seems stronger that I could have expected!

They now also started a board game night, which I hope will continue as well. What's noticeable here more than with the...

... tech (such as @librecast or @interpeer ).

The second interesting thing is that folk are trying to work out how to do persona modelling as part of threat modelling, because in threat modelling the focus has mostly been on protecting organizations from outside attacks.

Persona modelling is necessary for IPV because of that I - the perpetrator and victim are intimate (not necessarily in the sexual sense), and so within the same organization (family, etc). Traditional threat modelling cannot..

... puzzle is that it's also a space in which work gets set aside, and you meet the people behind the roles. I actually think that is very valuable to an organization that has to manage cooperation with this amount of complexity!

I'm sorry, no, this isn't about tech... it is about the people and relationships, and that's actually worth more.

With regards to the various working groups, BoFs and side meetings I went to outside of the DNS space, I gained a much better idea than I had before of...

... capture the risks here at all, while persona modelling with its focus on the individuals can. This can then also be used much better to address the risks of tech in these situations, and further speak to engineers better.

IETF as a whole moves like a slow ship, but this seems like a good shift in perspective that is working its way through the organization.

So it came as a pleasant surprise that both in DINRG where people try to promote decentralization, and HRPC where people try to...

... what is relevant in the IETF at the moment and why.

This I find very hard to summarize, except for having an impression confirmed that essentially everything is moving to QUIC. If it can be done im QUIC, there is a lot of pressure to do it in QUIC.

Is this good or bad?

Well, I guess it's a little bit of both. One person put it as TLS eating its way into every part of the stack. Which means that we'll have more transport security by default, while having similar behavior to the TCP we're..

... promote human rights protections in tech, I was quoted by the chairs. I wrote about only one the other day, but then the other also happened.

It makes me hopeful that efforts such as @interpeer can make some traction, because we do try to address both issues here (and they have some interaction).

Still, the downside of this is that it was made very clear to me yet again that IETF is not ready for taking this kind of work onboard *yet*. Both groups are research groups in the sister org...

... used to. That's good, right?

It generally is. Except for a few annoying parts.

First, transport security isn't end-to-end security. It seems that people can forget that the goal is humans, not machines communicating, so transport security is of limited use.

The second thing is that switching from one protocol to the other means there is a need for a signalling mechanism telling clients how to connect to a service.

And guess what people always get back to?

That's right, DNS.

So now...