Good morning, snowy Brussels! Despite the dangers starts. Let's now go the "ethics and blockchain" session.

Mitchell Baker speaking without slides (it seems there is a technical glitch).

Now, Deb Nicholson on "Blockchain: The Ethical Considerations" (first slide: a man working on a giant strawberry)

(I'm disappointed: this big room - Janson - is not full.)

Very good talk of Tom Hacohen about the pleasures of developing a really serious privacy-oriented application.

* everything is done on the client : changing the protocol requires to upgrade all clients
* data is encrypted client-side, the developer never sees the data, so cannot debug data-related issues.

Now, a guy with a french accent on stage. " and the right to data portability"

RFC 171 on screen (about transfer of datas between centralized silos).

Now, Veronika Nad on , and how it could benefit from free software.

(The room is not full, which is very rare for the Decentralized Internet and Privacy devroom.)

Now, panel about at . Christopher Webber, Gualter Barbas Baptista "How many people in the room have read the specification?" [Several hands, including mine] "Wow, that's a lot for a specification."

"What interested you in ?"

"It is simple to understand"

"Because it is used in "

"It is about distributing power"

" has a good model as a foundation: everything is actors sending messages to each other."

With such vague description, any protocol is ActivityPub...

"It would be cool to have a documentation of 'MastodonPub' [the actual protocol(s) needed to work with Mastodon] but we must not forget that could be used for very different things, too."

By the way, are there women working on ? The panel seems, at first glance, be all-male.

has a client-to-server protocol but nobody uses it, every ActivityPub server has its API. Is it a bad thing?

"Use cases are too different [Mastodon for chatting, Funkwhale to listen music], a common client would lead to a poor user experience."

"What I don't like in is that it uses ." Troll incoming, flame war ahead.

What is needed for the fediverse to talk to alice@7j3ncmar4jm2r3e7.onion? Webfinger and ActivityPub can work over Tor but most Mastodon instances cannot talk Tor.


Philip Homburg certifies results from his application, with .
He starts with a comparison with X.509 (1) with X.5909, you need to trust a lot of other parties 2) if the attacker controls DNS,it controls X.509 anyway).

Speaking of , a volunteer to write a monitoring plugin with getdns?

Existing plugins call dig or nslookup :-(

0952 local time: the devroom at is now full (we got refugees from other, more popular, rooms).

9 is 18 years-old. "Dealing with software that can drink legally" by Witold Kręcicki

21 years actually, from the first commit. In some places in the third-world, this is the minimum age to drink.

Among the funny things: one function (2.5 kLOC) doing everything, and with goto going into switch statements).

Testing 9 with pmccabe ( complexity calculation, available in Debian). Results are bad.

Advices for : 1) Don't be smart (don't assume you've understand the code) 2) Be slow (because small changes can have inattended consequences, test often).

Claiming that enables applications to do name resolution themselves while we had a talk one hour before... Not serious.
(Another joke was pretending that you can talk to your ISP about the things they do...)

Also, the talk completely mixes the DoH protocol with its usage and its servers. The concentration in Gmail is not because of the SMTP protocol!

And saying that traffic is protected in Europe by privacy laws like is a joke: data protection authoritities (like in France) are overloaded and not interested at all in DNS, they already have a lot of work with HTTP.

Another fundamental error in that talk: mixing two very different technical issues: the protocol and the fact that each application will do its own name resolution. They are unrelated.

The last trend at : making fun of projects. Too easy: you just say "blockchain" and everybody laughes.

Petr Špaček on administration and maintenance at . Executive summary: very simple and without risk (no, I was joking).

What's is in common between Costa-Rica, Czech republic, and Switzerland ?

These three TLDs implement RFC 7344 and RFC 8078 (CDS and CDNSKEY) for automatic provisioning and maintenance.

Afficher plus

@bortzmeyer chic :) ça fait maintenant 5 ans que j'ai mis ça en place dans le puppet d'Octopuce : un bout de script qui prend les clés SSH des serveurs et les publie dans le DNS :

ça + VerifyHostKeyDNS yes
dans ssh_config = <3

@vincib L'orateur a bien expliqué pourquoi 'VerifyHostKeyDNS yes' était un no-op :-)

@bortzmeyer ah, (je ne suis pas au Fosdem) en quoi est-ce un Noop ?

debug1: matching host key fingerprint found in DNS
debug1: Host '' is known and matches the ECDSA host key.

@vincib Parce que la bibliothèque ldns, utilisée par openssh, ne charge pas la clé de la racine, il faut le faire manuellement (et personne ne le fait). Donc, pas de validation DNSSEC.

@bortzmeyer En effet, je viens de découvrir le "found 3 insecure fingerprints ..."

@vincib Pour citer l'orateur : "this code is perfectly fine, but it doesn't work".

@bortzmeyer Je vois ça, dans openssh 7.9p1 dans openbsd-compat/getrrsetbyname-ldns.c L109, j'ai ldns_resolver_set_dnssec(ldns_res, true); /* Use DNSSEC */
mais aucun appel à ldns_resolver_set_dnssec_anchors() :/

@vincib Oui, c'est le problème. (set_dnssec_anchors nécessiterait de récupérer les ancres de confiance, ce que fait getdns mais pas ldns)

@bortzmeyer Le pire c'est que le patch ne doit pas être bien compliqué, on peut aire une ancre statique déjà ...
- ajouter un paramètre "dnssec_anchor_file" à ssh_config
- lire le fichier correspondant (exemple dans examples/ldns-dane.c fonction read_key_file ...)
- appeler ldns_resolver_set_dnssec_anchors()

@bortzmeyer ah, tu veux dire qu'il te demande confirmation quand même ? oui, c'est pas 100% trust, mais j'obtiens ça sur une nouvelle machine :

debug1: found 3 insecure fingerprints in DNS
debug1: matching host key fingerprint found in DNS
The authenticity of host ' (2001:67c:288::90)' can't be established.
ECDSA key fingerprint is Matching host key fingerprint found in DNS.
Are you sure you want to continue connecting (yes/no)?

@vincib Le mot-clé dans le message est 'insecure'. L'orateur vient de dire qu'il avait envoyé un patch, qui n'a pas été intégré.

@vincib @bortzmeyer il fait la vérification mais il ne fait pas de validation DNSSEC du tout. Il faudrait mettre une variable d'environnement (faut voir dans le code de ldnsà

@bortzmeyer hmmm, do I have L. Poettering just in the seat next to me?

@Keltounet @bortzmeyer (hopr you still have that special macaroon I left for him then)

@bortzmeyer one can actually get sysvinit on #debian quite easy as well.

@bortzmeyer is that a follow up from last year's same kind of talk?

Yeah, it's not nice to make fun of software with a handicap

@bortzmeyer I do not fully agree. In the US ISP play with your data and do ads etc.
In the EU they can be fined if they do. As a result or just because of the environment they do not do it.

@ttyS1 "Because of encryption, we can no longer see the user traffic, while GAFA still do." (A big french ISP at the Forum International de la Cybersécurité in 2016).

@bortzmeyer saying that anything software/network related is protected by some law makes be wanna puke.

The only thing that protects anything there are algorithms. No law will prevent you from utilizing a security flaw or do social engineering.

Laws can only be used to punish afterwards, not to prevent from happening.

@bortzmeyer Bonjour, Stéphane.

De fait, j'ai testé sur mon domaine '' ce que retourne ton site. Et, rien... c'est bizarre.

Alors que dans ma zone, j'ai configuré SSHFP, même TLSA, voire OPENPGPKEY...

Aie-je mal configuré quelque chose ? telle est la question que je me pose ?! :p

@hucste Ces trois enregistrements ne se mettent pas à l'apex de la zone. Pour deux d'entre eux, je ne peux pas deviner le nom. Le TLSA est bien là :

Inscrivez-vous pour prendre part à la conversation
Mastodon - Gougère Network

Mastodon est un réseau social utilisant des protocoles Web ouverts et des logiciels libres. Tout comme le courriel, il est décentralisé.