Confirmed users
299
edits
Security/DNSSEC-TLS-details: Difference between revisions
→DNSSEC Chains
| Line 27: | Line 27: | ||
The format of a serialized DNSSEC chain sent in this protocol consists first of a series of the following: | The format of a serialized DNSSEC chain sent in this protocol consists first of a series of the following: | ||
* | * The DNSKEY (and corresponding RRSIG) records for a zone, in wire format. There must be a key signing key present. | ||
* | * A DS (and corresponding RRSIG) record for the key signing key in the previous record, in wire format. This DS must be from a zone outer to that of the keys. The following set of keys must be from the same zone as this DS record. | ||
The root zone may be omitted, because it is assumed that the client already has the DNSSEC keys for the root. The TLSA (and corresponding RRSIG) record is prefixed to the chain and must be from the same zone as the first key set. | |||
So, for example, the DNSSEC chain sent for clients connecting to foo.bar.com could be: | So, for example, the DNSSEC chain sent for clients connecting to foo.bar.com could be: | ||
* The DS (+RRSIG) | * The TLSA (+RRSIG) for foo.bar.com | ||
* The DNSKEYS (+RRSIGs) for bar.com | |||
* The DS (+RRSIG) for bar.com (from .com) | |||
* The DNSKEYS (+RRSIGs) for .com | * The DNSKEYS (+RRSIGs) for .com | ||
* The DS (+RRSIG | * The DS (+RRSIG) for .com (from .) | ||
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 | 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 TLSA record, the keys for bar.com, and the DS record entering bar.com (as well as the signatures, of course). | ||
Note that once a chain has been serialized, it will only be valid for as long as every signature in it is valid. That is, it will become invalid when any signature it contains expires. | Note that once a chain has been serialized, it will only be valid for as long as every signature in it is valid. That is, it will become invalid when any signature it contains expires. | ||
For reference, another proposal for the serialization of a DNSSEC chain is [http://tools.ietf.org/html/draft-agl-dane-serializechain-01 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. | For reference, another proposal for the serialization of a DNSSEC chain is [http://tools.ietf.org/html/draft-agl-dane-serializechain-01 here]. Note that this proposal does not follow exactly the wire format of DNS records. Additionally, it reverses the order of 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. | ||
== Google Chrome == | == Google Chrome == | ||