[foaf-protocols] dtls + DNSsec + FOAF+SSL + google + Dane

peter williams home_pw at msn.com
Sun Dec 12 07:23:47 CET 2010


I've been trying to imagine the FOAF+SSL world contemplated by Henry last
week, in which certs/CRLs used in server https pickup of FOAF cards are
replaced by reliance on DNSsec. And then, for good measure given the pointer
to the new IETF Dane WG, I replaced TLS with DTLS (when talking to the
connectionless DNS resolvers), and then threw in Google's TLS handshake
modification too. (Their clients use the traffic encryption for
(non-handshake) plaintext encipherment before the (now datagram-based)
recipient has demonstrated possession of the server's write key, if you


Every bone in my body rebels against doing what Google did to the SSL
"finished" process, but let's see what happens. They are all a lot smarter
than me, and certainly a lot richer!


Years ago, I wrote an auto-correlation function that simply aimed to detect
DES - much like US navy machines detected which ciphertexts were of which
axis cipher in 1944, before Colossus then worked on the decrypt (according
to my cipher teacher, who contributed to all that in his youth). In those
days folks were apparently using early forms of differential cryptanalysis
as the detector, measuring a sideeffect "signature."My goal was rather
simpler: "simply" predict which of the various (std) protocols using the DES
f() someone gave me were reflected in the ciphertext, postulating that their
good/bad/awful design features concerning IVs (part of the operational key
that impacts the key schedule of DES-grade ciphers, typically) would induce
the detectable condition in the ciphertext. 


They were many protocols in our suite, all specified by ISO committess and
each using IVs very differently and for different purposes/modes: encrypted
Ethernet (connectionless) frames, X.509 handshakes over both
connection/connectionless channels, signed directory operations in a
web-like graph, various X.400 tokens for domain and inter-domain encryption
key agreement, and an American proposal for the internet using a generalized
telnet-like conversation for peer-TCP-entity authentication (that eventually
gave way to SSL!)


Rather than have an RSA key sign DNS RRs containing a pubkey introducing one
of the partitions in the subordinate zone (where the pubkey for those static
signatures themselves are distributed much like a "superior" cert in the
namespace distributes pubkeys in SSL, today), assume that the validation key
is distributed using the DTLS _session_ over which the DNS
req/resp/redirect/chain messages are communicated. The value can still be
static (so one doenst have to dynamically sign the RRs using the
timing-sensitive RSA cipher). But, the point is that  one obtains the pubkey
authenticator of the zone's RRs using the SSL handshake; where the
handshake's own properties delivers PROPERLY the authorization of said
pubkey to serve as a validator of RR signatures in a given zone, for a
particular master/slave/replicant of the zone. Typically, it would not be an
RSA pubkey, but let's use RSA as the well known function.

Now, if one applies the Google optimization, 2 problems strike me: (a) the
DNS client doenst yet have authorization to encrypt/issue datagram
containing the DNS request (where authorization is a limiting function
against client flooding of DNS servers), and (b) the server has not been
able to confirm that the proposed write keys do not conflict with its
checking out the run of the KDF to see if it has generated one of the pesky
keys that allows detection of the cipher, merely from the ciphertext.
Concerning (b) worse still, the server cannot reject the proposed client
write key (by withholding its side of the finished sub-protocol) should it
be deemed to be "related to" other write keys (which can be a disaster for
certain common SSL stream ciphers).


Assuming FOAF+SSL does have the strategic goal of migrating to DNSsec, I
think I'm starting to see where that IETF WG (dane) would fit into an W3C
incubation project - which focuses more on the FOAF side of FOAF+SSL
(assuming dane would work on a supporting class of DTLS+DNS+zone concepts
that specifically support huge numbers of semweb clients dereffing countless




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.foaf-project.org/pipermail/foaf-protocols/attachments/20101211/86ffbcf3/attachment.htm 

More information about the foaf-protocols mailing list