Ian Goldberg: > On Fri, Mar 13, 2015 at 03:23:05PM -0400, Hans-Christoph Steiner wrote: >> >> Upon thinking about this more, I think this should really be a part of the >> Signature Message. Then whenever there is a working OTR session, it will >> include the supported TLVs bitmask. I imagine that requires a new rev of the >> protocol, since the Signature Message does not seem to have a mechanism for >> extending it. >> >> Perhaps it still makes sense to include this TLV as a way to get this >> functionality with OTRv3. Then OTR implementations can just send this >> "Supported TLVs" Data Message immediately after the OTR session is >> established >> to get almost the same effect. > > I'm a little concerned that clients get only one bit to specify > "support/no support" for a particular TLV type. How would you describe, > for example, which byte values for TLV8 are supported by a client? > There's also a small information leak related to client fingerprinting, > but that may be hard to fully block in any event.
For TLVs like TLV8 that have their own sub-types that can or cannot be implemented, that TLV should have the query capability built into it. So for the Disconnected and SMP TLVs, there is no need to query whether subsections of the TLV are supported, its binary. For TLV8, there would be a byte value to represent querying which byte values of TLV8 are supported. I think the same format as I first proposed could be used for TLV8. As for client fingerprinting, I haven't really looked into that. My guess is that one client can so easily fingerprint the other side, regardless of the OTR session info, that it doesn't really matter if the OTR info itself leaks a little info about which client is in use. > What I would actually prefer is to just say "OTRv(whatever) is defined > as requiring support for these TLVs: ...", but that may be too strict? That would be nice, but how would that realistically be enforced? If someone takes an OTR lib (libotr, otr4j, etc) which fully supports OTRv3, but then does not expose SMP in the GUI, then OTRv3 is somehow "supported" but not actually in a useful way to the user. I think we can look at the past 10+ years of OTR and see that it is unlikely that many clients will actually follow this, so the software needs to adjust to the real world. .hc -- PGP fingerprint: 5E61 C878 0F86 295C E17D 8677 9F0F E587 374B BE81 https://pgp.mit.edu/pks/lookup?op=vindex&search=0x9F0FE587374BBE81 _______________________________________________ OTR-dev mailing list [email protected] http://lists.cypherpunks.ca/mailman/listinfo/otr-dev
