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
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp