[OTR-dev] new TLV to query supported TLVs

[Hans-Christoph Steiner]

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