Re: [MLS] Use Cases for avoiding Forward Secrecy

[Stephen Farrell <[e-mail]>]

Hiya,

On 28/02/18 22:56, Dave Cridland wrote:
> On 28 February 2018 at 21:16, Stephen Farrell <[e-mail]> wrote:
>>
>> Hiya,
>>
>> On 28/02/18 17:14, Dave Cridland wrote:
>>> Given the latter, for example, I could not use an MLS-based system to
>>> discuss a tax problem with the authority, and since I'm unlikely to
>>> have a SAKKE-based messaging client, I'm unlikely to have encrypted
>>> messaging to my tax authority at all - which seems signficantly worse
>>> than merely having no Forward Secrecy.
>>
>> Sorry, why is transport layer security not sufficient between you
>> and your tax authority?
>>
> 
> Because it's not a single hop.
> 
> Supposing my tax authority uses XMPP, for example, and so has (in my
> case) hmrc.gov.uk as an XMPP domain. I use some commercialish XMPP
> provider. I don't want my provider to be able to read my tax messages,
> nor do I want them archived in plaintext on the server (although I
> probably do want a verifiable record). Meanwhile, HMRC wants to keep
> an archived, but secured, copy at their end, viewable by their
> organisation.

I see no evidence that revenue.ie would ever prefer to handle
tax information via any intermediary when they have the option
to provide a URL to a tax payer or their agent. But perhaps you
do have a convincing use-case along those lines. If so, then I'd
say describing that, rather than asking to back off from forward
secrecy, might be a better approach at this stage (even if your
concern is really with the FS aspects of current MLS proposals).

> 
>> I'm unclear as to why the security guarantees (aimed for) between
>> groups of people ought be reduced in order to meet the goals of
>> securing communications between a person and a service provider.
>>
> 
> I'm not suggesting they should be.

FWIW, that's how I read your message. Apologies if I misread it.

> 
> I am suggesting that it might be nice if my options were not simply FS or FO.

FO?

> 
> (Besides which, the archives in a non-FS situation gain some security
> guarantees, too).

Again, specifics there would be useful. I can't evaluate the
sentence above.

> 
>> I do agree that it'd be good if a user of some application could
>> add a new device and still see old messages, but I'm not at all
>> clear that's that significant (for the crypto) since people will
>> always need to have some kind of fallback to handle cases where
>> they've lost state.
> 
> Assume a FS-only message transfer. In that case, how do we recover
> missing messages? 

I've no idea. But MLS isn't aiming to provide interoperable messaging
(sadly but understandably IMO), so that seem a tad out of scope, as
ekr pointed out.

> We have to transport those from another device that
> has them. That's a perfectly reasonable concept, and one that has been
> tried before in Skype. Unfortunately, as mobile devices replaced
> desktop/laptop combinations as the dominant device, they switched away
> from the design back to centrally-held archives since the clever
> synchronisation options simply didn't work.

I'm fine if MLS is only usable by some subset of interpersonal
messaging applications myself, even if the precise delineation of
the set of applications that can use MLS isn't precisely known.
(So long as there are a useful set of applications that can use
MLS.)

> 
> Of course, there are users who prefer the trade-off of higher security
> and no (or limited) archives. Such users would, one hopes, be warned
> about the change in security should they enter into a conversation
> with someone who cannot (or will not) support FS.

I don't think such subtle differences are at all desirable myself.

Cheers,
S.

> 
> Dave.
>