3 ms·

Phreebird isn't production code. I've been telling people to use it for internal testing only -- and I've even got that into various articles. What it does do

by dakami 16y ago

Phreebird isn't production code. I've been telling people to use it for internal testing only -- and I've even got that into various articles. What it does do is show what DNSSEC is capable of -- it's a way to separate fundamental limitations of the protocol (which do exist) from implementation faults (like the horrifying things you have to do to maintain DNSSEC with two year old DNSSEC code). DJB's talk argues that a whole bunch of things are fundamental limitations of DNSSEC. It implies that it must be a offline signer. This is patently false. Actually, any system that supports offline signing can be an online signer, and Phreebird is an example of one. I'd love to hear more about what you think the biggest problems with DNSSEC are. Perhaps this could inspire new features for Phreebird!

dakami 16y ago
Oh, hi Tom :) Was WONDERING why you were so quiet.
tptacek 16y ago
Ok. Here's one. It's a very common C function that appears in some way/shape/form in most client software deployed on the Internet: int connect_host(const char *host, u_int16_t port) { int sock = socket(AF_INET, SOCK_STREAM, 0); if(sock >= 0) { struct sockaddr_in si; memset(&si, 0, sizeof(si)); si.sin_family = AF_INET; si.sin_port = htons(port); si.sin_addr.s_addr == inet_addr(host); if(si.sin_addr.s_addr == INADDR_NONE) { struct hostent *hp = gethostbyname(host); if(hp) { memcpy(&(si.sin_addr.s_addr), hp->h_addr, 4); } } if(si.sin_addr.s_addr != INADDR_NONE) { if(connect(sock, (struct sockaddr*)&si, sizeof(si)) >= 0) { return(sock); } } close(sock); } return(-1); } Tell me something. In the world we live in now, with 10's of well-known mainstream CA's, I see an SSL certificate warning on an otherwise totally OK site about once a month. DNSSEC supposes a world in which everyone runs their own CA; in other words, a world in which there are tens of thousands of CA's. Where, in that function, do I (a) detect a DNSSEC failure, (b) propose to the user the untrustworthy - but - probably - totally - valid address we got instead, and (c) pop up a dialog to the user to allow them to decide whether to connect? Or, instead, does all this deployed code fail in exactly the same fashion as if the host didn't exist?

by dakami 16y ago

dakami 16y ago

Oh, hi Tom :) Was WONDERING why you were so quiet.

tptacek 16y ago

Ok. Here's one. It's a very common C function that appears in some way/shape/form in most client software deployed on the Internet: int connect_host(const char *host, u_int16_t port) { int sock = socket(AF_INET, SOCK_STREAM, 0); if(sock >= 0) { struct sockaddr_in si; memset(&si, 0, sizeof(si)); si.sin_family = AF_INET; si.sin_port = htons(port); si.sin_addr.s_addr == inet_addr(host); if(si.sin_addr.s_addr == INADDR_NONE) { struct hostent *hp = gethostbyname(host); if(hp) { memcpy(&(si.sin_addr.s_addr), hp->h_addr, 4); } } if(si.sin_addr.s_addr != INADDR_NONE) { if(connect(sock, (struct sockaddr*)&si, sizeof(si)) >= 0) { return(sock); } } close(sock); } return(-1); } Tell me something. In the world we live in now, with 10's of well-known mainstream CA's, I see an SSL certificate warning on an otherwise totally OK site about once a month. DNSSEC supposes a world in which everyone runs their own CA; in other words, a world in which there are tens of thousands of CA's. Where, in that function, do I (a) detect a DNSSEC failure, (b) propose to the user the untrustworthy - but - probably - totally - valid address we got instead, and (c) pop up a dialog to the user to allow them to decide whether to connect? Or, instead, does all this deployed code fail in exactly the same fashion as if the host didn't exist?