ietf-openpgp
[Top] [All Lists]

Re: [openpgp] rfc3880bis - hard expiration time

2015-05-04 08:26:20
Nicholas Cole <nicholas(_dot_)cole(_at_)gmail(_dot_)com> writes:

On Tue, Apr 28, 2015 at 3:01 PM, Derek Atkins <derek(_at_)ihtfp(_dot_)com> 
wrote:
Hi,

Nicholas Cole <nicholas(_dot_)cole(_at_)gmail(_dot_)com> writes:

On Mon, Apr 27, 2015 at 4:29 PM, Werner Koch <wk(_at_)gnupg(_dot_)org> 
wrote:

FWIW: I have no real preference pro or contra a hard expiration time.

I have not seen anyone in favour of a hard expiration time explain
what it is designed to prevent / enable. I think the new standard
should have a real prejudice in favour of excluding anything unless
there is a clear justification.  It could be that I've just missed
something, but I don't think that standard has been reached here yet.

You have seen them.  You've just ignored them.

It prevents someone who gains access to your private key the ability to
keep your public key going past your pre-selected expiration time.
Using soft expiration doesn't help in this case because the attacker has
access to your private key and could, as a result, issue additional
self-sigs with extended expirations.

No. I haven't ignored them.  What you cut out of my email was the
point I made that assuming an attacker is in a position to forge or
coerce an extension of the key expiration time but would not be in a
position to forge or coerce a new key is a very niche model of an
attacker.   That was the point I made.  Unless you think that scenario
is likely, I am against adding complexity to the new standard, even if
it is small complexity.

I don't see it as a niche at all.  It's quite possible for an attacker
to have obtained the secret key without the user being aware.  They
could have spent the resources to factor N (for RSA) or surrepticiously
obtained a backup data and determined the users' passphrase.  None of
these positions would put the attacker into a position to cause the
original user to generate a new key.

If you mean that they could generate a new OpenPGP Key Packet using the
same Key Material, you are correct...  Anyone could do that, even
without the secret data.  However, in the case of V3 keys doing so would
change the fingerprint and invalidate all existing signatures.  So it's
no different than an attacker generating a new key with your email
address and posting it to the keyserver to say she is you.

However with V4, an attacker with access to the secret material COULD
create a new SelfSig with an extended expiration.  This is a very
different (and expanded) attack surface, becuase it means they could
take over your existing Key+Signature/Certificate, precisely because
changing the expiration does NOT invalidate all existing signatures on
the Key.

Please don't tell me I ignored something I didn't.  I completely
understand the *technical* point being made. What I do not understand
is whether the use-case is realistic.

It is absolutely realistic!

Has there *ever* been a confirmed attack that this feature would have
prevented?

Yes.

N.

-derek
-- 
       Derek Atkins                 617-623-3745
       derek(_at_)ihtfp(_dot_)com             www.ihtfp.com
       Computer and Internet Security Consultant

_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp