Thank you for your assistance! I had just ignored the "unscaleable" attribute in favor of additional explanation.
I would think that the introduction of a captcha in the registration process should handle your concern about flooding the registration engines. The registration is normally done once per creation of a user private/public key combination. From: George Michaelson [mailto:[email protected]] Sent: Wednesday, September 11, 2013 17:40 To: Karl Malbrain Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol no no, I don't think this. sorry its my english. if somebody else from sound groundings had said 'palpably wrong' I'd have expected just what you did: ask why. the 'unscaleable' hit my funny bone and got a 'this is bullshit, its the I dont want it so I'll say something to fudge it response. I just meant that HAD somebody said wrong because... or broken because.. I'd not have leapt. But they didn't, they just intruded the 'unscaleable' which frankly counts as much as 'unfashionable' with mechanisms like UUID registration, (which has come up in APNIC) there is an attack model where you flood the registration engine with huge numbers of <new> and make it die in a ditch. we have discussed how you make the TCP lifetime exponential increase to get to the submit button, or use TLS to bind to it, so the cost on the client side is non-trivial, or do captcha or the like. none of them are very good. we've been running registry/whois for years, and periodically somebody designs a new method of business which demands we handle eg 60,000 emails for whois update of their customer more specific, every month. we survive fine, but its a challenge. you need to be mindful of this kind of non-cost On Thu, Sep 12, 2013 at 9:30 AM, Karl Malbrain <[email protected]<mailto:[email protected]>> wrote: Of course you've piqued my interest. In what sense is this palpably broken and wrong? slow: No, The user's UUID for his public key is only obtained once per TLS server on first login. After that it is stored along with the UUID on the server for use in the TLS challenge. Subvertable: No, Since the list is read-only, MITM attackers cannot change the user's public key to one of their own choosing. Without the user's private key the MITM attacker cannot answer the TLS challenge from the server. If the MITM attacker tries to change the UUID, the server will have no knowledge of the bogus client. From: George Michaelson [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, September 11, 2013 16:21 To: Karl Malbrain Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol right. none of this seems to warrant use of the 'unscaleable' word. slow, or subvertable, or palpably broken and wrong I can go with, but unscaleable just doesn't seem to me to be applicable. On Thu, Sep 12, 2013 at 9:14 AM, Karl Malbrain <[email protected]<mailto:[email protected]>> wrote: UUID collisions would be handled by the list servers which would silently reject posts of user public keys to occupied UUID slots. User's would determine this by noting that a UUID query doesn't produce their public key, and then retry the post with a different UUID. List servers would communicate among themselves to replicate the list globally. Karl From: George Michaelson [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, September 11, 2013 16:08 To: Karl Malbrain Cc: Phillip Hallam-Baker; Paul Wouters; [email protected]<mailto:[email protected]> Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol unscaleable is a word which had currency in 16 bit computer days, and possibly in 32 bit computers when disks and bandwidth were untenably expensive. I am less sure that any enterprise which only has to scale to addressing 2 billion people in the next 5-10 years is 'unscaleable' in the real sense of the world. 'seems very inefficient' or 'seems like a problem which will carry its own sub-problems' or 'scaling this is a challenge which demands funding and eyeballs' are all less direct statements going to the same place. or do you believe UUID collide, and in fact cannot uniquely identify end entities casting the runes to make randoms? On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain <[email protected]<mailto:[email protected]>> wrote: The list is replicated but not centralized per-se. There is only one content. Larger servers could maintain their own copy of the replicated list for their own usage. As to the utility of the enhancement, MITM attachments/attacks are precluded by strong authentication of both the server and the client. The specific technical problem addressed is the ability of both parties to reliably obtain client public keys during TLS negotiation. From: Phillip Hallam-Baker [mailto:[email protected]<mailto:[email protected]>] Sent: Wednesday, September 11, 2013 12:16 To: Paul Wouters Cc: Karl Malbrain; [email protected]<mailto:[email protected]> Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <[email protected]<mailto:[email protected]>> wrote: On Wed, 11 Sep 2013, Karl Malbrain wrote: From: Karl Malbrain Sent: Wednesday, September 11, 2013 11:43 To: 'Theodore Ts'o' Subject: RE: [perpass] proposed enhancement to TLS strong authentication protocol It's a WORM list. Users post requests to the list maintainers they trust with a GUID to register their public key, and then send this GUID as part of the TLS negotiation process. Seems to me to be basically like an unscalable central version of the TLSA record? https://tools.ietf.org/html/rfc6698 I think it can be decentralized and have been working on an architecture to do that for email security. But it does not really help much for authentication to random Web sites or for enterprise use either. -- Website: http://hallambaker.com/ _______________________________________________ perpass mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/perpass
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
