Re: [openpgp] review of the SOP draft

[Antoine Beaupré <[e-mail]>]

On 2019-11-14 03:18:07, Daniel Kahn Gillmor wrote:
> I've incorporated some of your suggestions from this e-mail directly in
> the draft now.  Thanks a lot for them!  more discussion below…
>
> On Tue 2019-11-12 12:26:00 -0500, Antoine Beaupré wrote:
>> I guess what I'm wondering is how I would make this work with my yubikey
>> at all. Or maybe I got this backwards and the yubikey interface is what
>> should implement sop directly?
>
> I have no idea about how to make it work with hardware tokens.  I remain
> frankly unconvinced about the seurity tradeoffs for most uses of
> hardware tokens (something i guess i need to actually write down more
> formally), and i'm unlikely to spend a lot of time developing how to
> integrate them with `sop`.

I'm not sure it would be productive for me to engage at that level here
right now, given how long this thread is already. :) Suffice to say I
believe there's enough of a use case of those devices that we might want
to think about how this standards interoperates with them.

I guess we don't have good answers for this in any case. At least I
don't know how to materialize those things in standards right now
anyways, but I would love for this to change in the future.

[...]

[all good stuff elided]

[...]

>> What I'm saying is the `sop sign` example is error prone. Forget the `<`
>> and the mandated order and you might reverse the signing key and the
>> message.
>
> sure. if you screw up any API, you can screw up any API :)

Some APIs are harder to screw up than others. Naming things,
specifically, forces people to think about meaning. Ordering them
doesn't.

>>>>> If `sop decrypt` fails for any reason and the identified `--session-key-out`
>>>>> file already exists in the filesystem, the file will be unlinked.
>>>>  
>>>> This seems dangerous! Why do we delete a file we haven't created?
>>>> Explain.
>>>
>>> We don't want the user to run `sop`, and then inspect a file that was
>>> already in the filesystem thinking that it is `sop`s output.  If you
>>> think that's a bad decision, please suggest what we should do
>>> differently.
>>
>> Maybe we should not overwrite existing files at all and fail earlier?
>
> I think you're proposing that if the `--sessionkey-out` file already
> exists in the filesystem, that should be an error in the first place.
> I'd be happy to entertain that idea, if anyone wants to provide text for
> it.

Yes, i think that might be preferable.

> If you decide to try to write it up, please think about how it works for
> the other scenarios where `sop` can produce output on more than stdout.
> it would be nice if these mechanisms all had the same behavior.

Okay, I'll keep that in mind.

>>>>> [`--with-session-key`] enables decryption of the `CIPHERTEXT` using the session key directly against the `SEIPD` packet.
>>>>> This option can be used multiple times if several possible session keys should be tried.
>>>>
>>>> What happens if both "in" and "out" are provided? I can venture a guess,
>>>> but it would be important to make that explicit as there can be horrible
>>>> bugs there.
>>>
>>> Please do venture a guess, in the form of proposed text! I'd also love
>>> to hear what the horrible bugs are.  I don't see them.
>>
>> I would argue that both options should not be provided at once. One
>> implementation that could come up would be that the program attempts to
>> read the file as it's writing it, truncating the precious key before it
>> has time to read it.
>
> Ah, you're not talking about providing both options -- you're talking
> about providing both options pointing *at the same file*.  i agree, that
> sounds like a bad idea, but it's a bad idea for *any* pair of input and
> output fields.

This is something I came up with recently while writing another
program. I started by writing something that would read parameters from
a config file, then realized I could also *save* parameters to that same
file (or another). So I have two parameters, usually pointing at the
same file (but not necessarily).

The way "conflicts" are handled is simple: the file is first read, and
closed. Then it is written to. As long as that's done in order and
there's no parallelism, it works correctly.

I was wondering if we might want to do such a suggestion specifically
for the session key because it's this one case where you have a state
that can be read and written. Sure, everything in sop read and writes to
stuff, but in general they are different objects (cleartext vs
encrypted) that won't be written to the same file unless the user does a
mistake.

[...]

>> I don't know how OpenPGP packets are built. Can't we show the signature
>> on the output of decrypt?
>
> Absolutely not.  Mixing the cleartext output with the signature
> verification stream is a classic cause of failures.  What if the
> cleartext data happens to "look like" a signature verification?  how is
> the consumer supposed to distinguish between them?
>
> It is critical to keep them separate.

Understood.

[...]

>> In the context where all my email traffic is encrypted with OpenPGP,
>> for example, decryption is not the primary operation anymore. I *do*
>> want to fail properly on signature validity, it becomes a primary
>> operation when encryption is "default"...
>
> You want a *failure* in the sense that you think that an MUA shouldn't
> show the user the cleartext of the message if no valid signature can be
> found?
>
> This is suprising to me, and i know of no MUA that does this.

Didn't think of that pattern. The system you're proposing makes more
sense in that context.

[... possibility of making yet another patch to support -fd ...]

>> Say you think you are in a trusted directory with "CERTS" that you want
>> to encrypt to. You call:
>>
>>   sop encrypt * < /tmp/file > /tmp/file.pgp
>>
>> Except you made a mistake and the attacker has control of the current
>> directory, and injects a file named (say) @ENV:SOMETHING. Assuming they
>> have control over the SOMETHING environment, they can now add an
>> encryption key to the message.
>
> if the attacker has control of the directory, they can inject an
> encryption key in the first place, right?  i don't think @ENV makes this
> any worse...

I guess so. It still makes me iffy even if I can't put my finger on it.

[...]

>> `sop probe` would do the minimal amount of work required to determine
>> which keys ("signers") to consider  when decrypting, then call `decrypt`
>> properly.
>
> I don't think this is "stateless", and i don't think it's
> well-specified.

Sure, it's stateless. The input is external and the output is purely
informative. But of coruse, it's not well-specified. It was just an idea
to work around the double-pass problem you identified.

[...]

> Thanks for the discussion!

You're welcome! I'm not sure I will have much more time to provide
patches and more work, but at least that was something. :)

a.
-- 
Antoine Beaupré
torproject.org system administration