Re: Opportunistic signatures - a proposed design

Atom 'Smasher' wrote:

> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> 
> i already let signed email bypass any filtering, if i have the public
>  key in my keyring.
> 
> i'm currently working on a formal standard for including OpenPGP key
>  information in an email header. when that happens, an MUA can offer
> the user an option to accept the key, and accept any message signed
> with that key. it really shouldn't be *that* difficult to build the
> UI smarts into an app, if the key management is handled
> intelligently.

well, I'm on the opinion that the user should never ever see there is a
key unless they have a specific security need to do so.  Think about the
most successful systems with encryption today: SMTP/TLS and HTTPS

the reason they are successful is because the user just uses them.  They
don't futz with keys, they don't manage a key ring, it just works
because it does.  If it doesn't work right, you call your local geek and
maybe they can make things get better again.

what ever system we build in, should have zero interface required as one
of the founding principles.  It can be done, yes the keys are not very
secure but, once you're owned, it doesn't matter if you have a pass
phrase whether it's default, stored somewhere on the system, or in your
head.  If you don't own your own system, it's gone.

once you're comfortable with a concept, plus the knowledge that if you 
need to add more key security you can, a zero user interface baseline is 
really not all that scary.

> in the meantime, only geeks will allow signed messages to bypass
> further checks. i think that signatures and hashcash serve different
> purposes, and to that extent the technologies are complimentary... if
> i have your key in my keyring you can sign a message and it won't be
> subject to filtering... but if i don't know you, then hashcash will
> do the same thing. also, i may not want to sign an email with my key
> (maybe i'll want to deny later that i authored it)... in that case,
> hashcash is more valuable.

the whole point behind signatures (in this context) is to indicate 
automatically that the message is from someone I know.  Not from someone 
pretending to be someone I know but actually someone that I know and 
have exchanged e-mail with in the past.  That's it.  End of requirements 
(sort of).  It's not to have any greater level of meaning.  That's for 
someone else's concern.  It's just "it says it's from Joe, does it look 
like his signature?"


> anyway, OpenPGP is a perfectly viable protocol for signing email...
> no need to reinvent that wheel. of course, if people are signing on 
> auto-pilot (no password protected keys) then keys should be small...
>  they'll be stolen by viruses, not password protected and there
> should be several avenues of plausible deniability... the purpose is
> to "prove" to a filter, not to a court, who authored an email. of
> course, if one is handling outbound email for a large bank and they
> want to discourage phishing, then a large key is a good idea (with
> certain obvious and non-obvious precautions).

well, here's the question how fast can you for someone's key if it's a 
small number of bits.  After all, that's what all of our techniques boil 
down to.  If I use a public key system with 256 bits, how fast can 
spammer fake being me?  What's a reasonable lower floor?

now, if we add the requirement that we want to also encrypt e-mail in 
transit, again, what's the size of the organization that can regenerate 
my key, how long would take, etc.

mind you, if we use the Russian dolls model of encryption (weak outside, 
strong inside) then it wouldn't matter so much because if you truly 
wanted to protect your contents, you would protect your contents 
explicitly.  I'm mostly thinking about envelope level protection.

---eric