OpenPGP Browser Support

[Duane]

Adam Langley wrote:
> On Thu, Jul 24, 2008 at 3:37 PM, Duane <duane at e164.org> wrote:
>> I have written in depth about this topic already, so rather than repeat
>> myself I'll just paste a link to the relevant document:
>>
>> http://open-pgp.info/wiki/index.php?title=DNS_Encryption_Draft
> 
> This document seems to be dealing with something quite different,
> namely providing some confidentiality to DNS resolvers. But that's not
> an uninteresting topic in of itself.

Sorry about this, but since I posted that I split the draft into 2, well
3, documents.

The DNS Encryption stuff, Standardisation of OpenPGP information:

http://open-pgp.info/wiki/index.php?title=Standardisation_of_Information_in_OpenPGP_User_IDs_for_Server_Purposes

And a chunk of text left over I'm not sure what to do with entirely:

http://open-pgp.info/wiki/index.php?title=Why_X.509_is_Bad

> However, rather than have queries encrypted to a server and signed
> replies, I'd suggest that clients include an elliptic-curve
> Diffie-Hellman public key in the request and encrypt the request with
> the shared key (assuming that the client know's the server's key). The
> server than calculates the shared key, encrypts the reply and sticks a
> MAC on the end.

The public-key + signed replies are only for session key setup, once
established the server/client can switch to AES or some other
symmetrical encryption. The reason for signed replies is to prevent
spoofed packets from downgrading or sending fake error messages.

> If a server can get a cache hit on the client's public key, it's
> equally very fast. Otherwise (and this would almost always be the case

Actually I'm going the other way, clients are trying to get cache hits
on server keys since that's where you need to calculate confidence
ratings, the server doesn't need to know anything about the client, in
fact the less the server knows about the client the better.

> for root/gTLD servers), you can do about 4000 key
> agreements/second/core[1]. For a modern, 8-core machine that's 32Kq/s.
> I can't find recent data on DNS server load at the root or gTLD level,
> although I suspect it's within an order of magnitude of that. For ISP
> level server, that should be fine.

Actually this will be a little difficult to deal with, a number of root
servers have anycast addresses so it will mess with sessions, all the
client can do is re-request a new session set-up using the same AES key
unless the servers some how share session keys and cookies some how.

I suppose I really should make a note about this in the draft.

-- 

Best regards,
 Duane