[messaging] OTR pre-verification pinning [was: Fingerprint usability study]

[Daniel Kahn Gillmor]

On 06/17/2014 04:36 PM, Filippo Valsorda wrote:
> On 2014-06-17 18:55:15 +0000, Daniel Kahn Gillmor said:
> 
>> In the real world, the incentive to accept fakes is slightly different
>> than either of the above.  In nearly all scenarios [0] where a
>> fingerprint is presented and needs to be confirmed or denied, it is *an
>> obstacle in the way of doing what you were trying to do*.
>>
>> [...]
>>
>> [0] OTR is just about the only exception to this obstacle situation, and
>> in practice, many users of OTR simply skip the fingerprint comparison or
>> SMP confirmation step entirely (which i think might even be strictly
>> worse than accepting an unverified fingerprint once and getting
>> TOFU-like alerts upon peer key change).
> 
> I wonder if this behavior is spec-dictated. I think that it might make
> sense to pin the peer key on first sight and give a warning if a new one
> is encountered (and obviously upgrade it to verified once the user takes
> that step).
> 
> Are there any implementations doing it this way or was this ever
> discussed before for OTR?

I suspect the rationale for OTR having this behavior was an attempt to
cope with the situation of one user connecting with different pieces of
client software (possibly on different machines), not all of which would
have access to the same OTR keys.  This would produce a lot of false
alerts under the proposed scheme.

In some transports (e.g. XMPP) it's possible to identify the client used
in addition to the user account, so you could conceivably bind a key to
that client+agent, to avoid a false alert.  But then an attacker could
simply choose a novel agent-identifier when spoofing a key and avoid the
alert.  Maybe this isn't a UX improvement?

In any case, i don't think a protocol as platform-agnostic as OTR can't
make the assumption about there even being an agent-identifier.

But if we could assume that the user always has access to their own
keys, then yes, the TOFU UX seems like an improvement.

OTOH, i think that the common OTR implementation is designed
specifically to avoid sharing keys between systems, since you only need
one copy of the key to be compromised in order to lose OTR's
communications security guarantees on every agent.  I'm not convinced
the OTR team made the right tradeoff there.

	--dkg

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 1010 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140617/f2a58d91/attachment.sig>