Security/DNSSEC-TLS: Difference between revisions

Security/DNSSEC-TLS (view source)

Revision as of 22:50, 28 June 2011

52 bytes added , 28 June 2011

m

→‎DNSSEC Chains

Dkeeler

Confirmed users

299

edits

@@ Line 43: / Line 43: @@
 * The TLSA (+RRSIG) for foo.bar.com (given that the bar.com is authoritative for foo.bar.com)
-It is possible to optimize away some fields of these records, but at the moment this is not being done. Another optimization would be for the client to indicate a root of trust deeper down the tree so that the server can omit some zones. For example, a client may already have (and have validated) all of the keys for .com. In this case, example.com need only send a DS record entering example.com and the keys for example.com (as well as the final TLSA record).
+It is possible to optimize away some fields of these records, but at the moment this is not being done. Another optimization would be for the client to indicate a root of trust deeper down the tree so that the server can omit some zones. For example, a client may already have (and have validated) all of the keys for .com. In the above example, if the client has already validated keys for .com, the server need only send the DS record entering bar.com and the keys for bar.com (as well as the final TLSA record).
 For reference, another proposal for the serialization of a DNSSEC chain is [http://tools.ietf.org/html/draft-agl-dane-serializechain-00 here]. Note that this proposal does not follow exactly the wire format of DNS records. Consequently, preexisting code cannot be used to serialize, parse, or validate the chain. Additionally, more flexibility means more opportunities for insecure verifier behavior. This proposal is not currently being used in this project.