User: Password:
|
|
Subscribe / Log in / New account

On keys and users

On keys and users

Posted Jun 23, 2011 9:29 UTC (Thu) by ortalo (subscriber, #4654)
Parent article: On keys and users

Two thoughts I'd like to share for further discussion if anyone is interested:
- occasionnally and probably provocatively, I come to say that cryptography cannot be used to solve any security problem, but that it can be used to *move* it (from the protection of the data to the protection of the key(s)). These are still impressive achievements by the way; but using cryptography does not mean we do not have to address all other security issues correctly (integrity checks, access checks, authentication, authorization, revocation, monitoring, etc.).
- "For many, the additional hassles required to securely communicate may not be overcome by the concern that their communications may be intercepted." Computers offer us astounding new opportunities with respect to information security, not limited to ciphering. In the civil domain, these opportunities are probably even more astounding for integrity (signature, authentication, etc.) than for confidentiality issues. Why not try to go after original features to motivate most users to overcome the hassles? (For example, the Internet explosion of the 2000s boom was targeted at e-commerce; what about offering novel features surrounding money issues like peer-to-peer contracting? $$ tend to motivate many...)


(Log in to post comments)

DNSSEC and PKI

Posted Jun 23, 2011 10:32 UTC (Thu) by copsewood (subscriber, #199) [Link]

I suspect that DNSSEC combined with tamper resistant private key storage (e.g. within mobile phones) once these technologies becomes more widely available, will help lessen a couple of hard key management problems to a useful extent. (NB these 2 problems don't have and probably never will have complete solutions).

1. Having a generally known and agreed place to obtain public keys from where the domain name represents the identity of the user and some kind of a chain of trust needs to be established to say that the public key for alice.smith.coventry.uk really belongs to the Alice known to have this globally unique identity. (If you don't like AINA as the identity trust root, DNSSEC enables you or your community to establish alternate and even multiple trust anchors). The advantage is that DNS identities are the ones we use anyway, the difference between alice@smith.coventry.uk and alice.smith.coventry.uk being syntactic and not semantic.

2. Having arbitrarily short time to live values enables users to manage risk of key compromise and signature repudiation by leaving invalid signatures possible based upon user knowledge of key compromise for a known and more limited time extent. E.G if your bank requires you to inform them within 24 hours of your losing a signing device, it takes 48 hours to extract the private key from its tamper resistant container by someone with access to a semiconductor plant without destroying it, and the DNS record storing the key has a TTL of 24 hours, then the compromised key can be timed out before it can be used (unless a bank customer is unable to inform the bank within 24 hours. Larger transactions can have longer delays or additional security checks and those who think it may take them longer than 24 hours to inform their bank can insure against quantifiable risk, and the bank will probably be obliged to provide such insurance in exchange for normal bank charges).

One of the flies in this ointment concerns how Alice revokes her key once her mobile phone containing a tamper resistant module protecting her private key is stolen, if the signature from this key is the most reliable means for Alice to identify herself for this purpose. But I think all key-identity binding solutions have this problem, and require alternative means by which Alice's identity can be sufficiently established (e.g. personal knowledge of secrets over a phone conversation with Alice's bank). In this event the bank will prefer to risk an imposter who has been through Alice's rubbish bin and tapped her phone being able to cause a temporary denial of service on Alice's bank account than risk Alice's funds being stolen. Alternatively if Alice has signed a revocation certificate and left copies with friends who can identify her over the phone better than the bank, the bank may be able to accept a copy of one of these.

DNSSEC isn't just about securing the naming system, as I see it. It seems to provide for a more generic PKI.

DNSSEC and PKI

Posted Jun 23, 2011 11:17 UTC (Thu) by ndye (guest, #9947) [Link]

... the difference between alice@smith.coventry.uk and alice.smith.coventry.uk being syntactic and not semantic.

coventry.uk and smith.coventry.uk can be under completely separate administrative authority. In my view, the following are distinct identities:

  • alice.smith@coventry.uk
  • alice@smith.coventry.uk

So why do you assert no difference between

  • alice@smith.coventry.uk
  • alice.smith.coventry.uk

(Or there's much more I don't grok about DNS.)

@ndye: DNSSEC and PKI

Posted Jun 23, 2011 20:31 UTC (Thu) by copsewood (subscriber, #199) [Link]

"So why do you assert no difference between

alice@smith.coventry.uk
alice.smith.coventry.uk"

I was pointing out the fact of syntactic difference but the semantic similarity.

In the first example, the email admin of smith.coventry.uk creates the ID. In the second example the DNS admin of smith.coventry.uk does. Syntactically (based upon punctuation) we assume the first to be an email address and the second to be a DNS name. Semantically (the meaning behind the use of words) we have delegation of authority over identity through the big endian chain of labels in both cases, and it matters little whether the granter of the globally unique identity concerned is looking after a DNS or an email server.

The point I'm making here is that the DNS concept is inherently extensible to include everyone on the planet and use of all kinds of network services, not just the narrow priesthood of server operating geeks. RFC4255 http://tools.ietf.org/html/rfc4255 and RFC4871 Domainkeys http://tools.ietf.org/html/rfc4871 both demonstrate interest in using DNS and DNSSEC for secure or cheap public key storage and access in respect of non-DNS protocols (SSH and SMTP respectively). The use cases to extend the SMTP concept initially to Domainkeys (to prevent cheap email origin spoofing) , and to extend the Domainkeys concept to using DNSSEC to create certificates for authentication and privacy of email seem reasonably clear.

DNSSEC and PKI

Posted Jun 23, 2011 12:36 UTC (Thu) by david.a.wheeler (subscriber, #72896) [Link]

Yes, I completely agree that DNSSEC can provide a basis for a simple-to-use PKI. I wrote Easier Email Security is on the Way? back in 2002, outlining this. I think you could use DNSSEC to get keys for domains, and then other protocols (such as LDAP) to get public keys for individual users.

It's sad that it's taken so long to get DNSSEC mature. But it's finally starting to get out there. It's finally becoming possible.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds