jdev - 2019-12-17

Hi. I'm implemeting OMEMO media sharing, and it seems that there is an incoherence: doc says that key is 32 bytes and IV 12 bytes, in hex it's 64 + 24 = 88 but the example URL fragment is 96 bytes, and a quick test with Gajim give me a fragment of 96 bytes too. So it the XEP text wrong or am I missing something?

(talking about the URL in example at https://xmpp.org/extensions/inbox/omemo-media-sharing.html#aesgcm)

we originally used 16 byte IVs; but the aes-gcm spec says you should use 12

so for legacy reasons everyone keeps sending 16 for now; but have read support for 12

except chatsecure i think which only supports reading 16

which is why we haven’t switched over yet

ok so for reading both should be implemented. For writting is it still recommanded to use 16 or should I use 12? Is there any client not supporting reading 12?

yes chatsecure; last time i checked

ah right sorry you just say that above :)

Thanks Daniel

are there tests provided to verify the correctness of a given RFC implementation? I'm working on implementing RFC 6122 and I'd like to improve and extend my test cases. The dependency on Unicode makes it a bit complex to come up with a complete set of tests

Hm, wasn't there a project for that?

There's a few test cases in in https://github.com/igniterealtime/jxmpp/tree/master/jxmpp-strings-testframework/src/main/resources/xmpp-strings/jids

Not sure about the coverage of Unicode yet tho

the ones you provided are very helpful, thanks Zash.

And then there's the thing with RFC 6122 being obsoleted by RFC 7622 but I don't know if anyone is there yet

PRECIS isn't implemented yet as far as I know

libidn2 team were thinking about releasing libprecis but no news. ICU team's case is vague too https://unicode-org.atlassian.net/browse/ICU-11981 https://libidn.gitlab.io/libidn2/manual/libidn2.html#Stringprep-and-libidn2

I've got that ICU ticket bookmarked 🙂

:D

prosody discussed PRECIS as well https://issues.prosody.im/533

didn't sco0ter do PRECIS? ✏

libidn being obsoleted by libidn2 when we're using the stringprep stuff .. looks like we're going with ICU for now

(in Babbler?)

Guus, I'm not familiar with sco0ter sorry. Zash, it leaves us with a hybrid implementation. 6122 for localpart and resourcepart, 7622 for domainpart (IDNA2008)

There were rumors of some Rust folks maybe planning on some PRECIS stuff

Hm?

Isn't 6122 IDNA2008 + STRINGPREP?

no

6122 IDNA2003 + STRINGPREP

Wasn't that what was before 6122?

yeah

https://tools.ietf.org/html/rfc6122#section-1.1 sounds like IDNA2008 or do I need to read more carefully?

well I follow https://tools.ietf.org/html/rfc6122#section-2.2

>A domainpart consisting of a fully qualified domain name MUST be an "internationalized domain name" as defined in [IDNA2003];

> or do I need to read more carefully? No, I need make dinner. Looking at these things only leads to tears 🙁

eat well

It does say > software implementations are encouraged to begin migrating to IDNA2008

yeah that's what I meant by "hybrid"

I think there's also some compat options in IDNA2008 (or at least in ICU) that somehow minimizes the differences (and hopefully, pain) between '03 and '08

of course. both PRECIS and IDNA2008 are backward compatible as far as I know

`UIDNA_NONTRANSITIONAL_TO_ASCII` does ... something (in ICU)

their docs are a bit vague ...

Can you guys make a page maybe on xsf wiki how to live with c/c++ and without PRECIS implementation?

It seems some distros are eager to remove old libidn :(

if distros are eager to remove libidn, it's because the libidn team is pushing idn2? no? iirc libidn also offers stringprep whereas libidn2 doesn't offer anything (neither stringprep nor precis)

an alternative would be to use ICU because it offers (deprecated) idna2003 support, idna2008 and stringprep

ICU also has "confusable" mapping stuff

such as?

http://www.unicode.org/reports/tr39/

oh yeah that's neat. it helps with address spoofing and forging

Right, that, like if someone joins as "Zаsh" (using a cyrillic small letter a)

I assume XMPP users are nice people and delay security considerations until later oops

oh yeah Zash, apparently HenryⅣ `\u2163` gets mapped to Henryiv in stringprep however it's illegal in precis. interesting

henry*

Fun

and this is why we don’t go there (PRECIS)

I'd like to have the option but I'm not sure if there's any rush

I don't know. I'm still a beginner but personally PRECIS seems more organized and structured properly

care to elaborate, jonas’?

renken, PRECIS and Stringprep aren’t compatible. if some entities are on PRECIS, and some are on stringprep, chaos ensues

in addition, PRECIS isn’t pinned to a unicode version, so different entities on different unicode versions coudl very well be of different opinions on what constitutes a "legal" string

Bad enough things happen already

🤖️ says hi

#robotface

I see. thanks for the explanation

sad unicode life

read also: https://mailarchive.ietf.org/arch/msg/xmpp/a-WhzOTyOq168GujQHgzQ1-DURI

jonas’, how much chaos do we get if we do the postel thing?

postel?

"be conservative in what you send, liberal in what you receive"

helps only partially

it helps with the plain out rejection, but if unicode comes up with different normalisation mappings, you’ll get havoc with user passwords and stuff

Altho here I mean being Very Strict when creating things locally, while not being as strict with incoming data

I’d also expect a MUC service to enforce a single unicode version across all nicknames it allows

Yeah, that.

And locally created users.

usernames*

Hm did we already add that to Prosody for MUC?

Ah yeah (trunk tho)

and room localparts

flow, is there any documentation on creating a MAXS plugin?