On Sun, Nov 30, 2014 at 06:48:41PM -0700, Peter Saint-Andre - &yet wrote:
[ I'm splitting it into a few messages to keep it manageable, and
in any case some of my comments are still pencil marks on a
print-out, not yet transcribed. ]
This message covers sections 3.2 ("Address Queries") and 3.3 ("TLSA Queries").
General comment (copied verbatim from abstract and introduction
feedback):
The draft frequently talks about "hostnames", where what is
really meant is a transport endpoint (port, transport protocol,
host). With PKIX-EE or DANE-EE certificate usages, TLSA records
are more precise than the Web PKI and can associate different,
non-interchangeable key material with distinct services on a
single host. So in many places I will be suggesting replacing
statements about "hostnames" with statements about "transport
endpoints".
3.2. Address Queries
Clients that support only v4 or only v6 need not make queries for
an address type they can't use.
OLD:
<t>For each SRV target server host name, the client makes A and AAAA
queries, performs DNSSEC validation on the address (A or AAAA) response,
and continues as follows based on the results:
NEW:
<t>For each SRV target server host name, the client makes A and/or AAAA
queries, performs DNSSEC validation on the address (A or AAAA) response,
and continues as follows based on the results:
The term "usable" is not applicable in the context of address
queries. TLSA queries should be made if either the A or AAAA
response is secure (e.g., sometimes the absence of "AAAA" is
"insecure" due to opt-out, while the "A" records are "secure").
When the zone containing the host's A/AAAA records is unsigned,
queries for TLSA are more likely to fail than to unexpectedly
produce "secure" results. This is not to say that they are in
fact likely to "fail".
OLD:
<list style="symbols">
<t>If the response is "secure" and usable, the client MUST perform a TLSA
query for that target server host name as described in the
next section.</t>
<t>If the response is "insecure", the client MUST NOT perform a
TLSA query for that target server host name; the TLSA query will
most likely fail.</t>
<t>If the response is "bogus" or "indeterminate", the client
MUST NOT connect to this target server; instead it uses the next
most appropriate SRV target.</t>
</list></t>
NEW:
<list style="symbols">
<t>If either of the A or AAAA RRsets is "secure", the client MUST
perform a TLSA query for that target service endpoint as described
in the next section.</t>
<t>If both RRsets are "insecure", the client MUST NOT perform a
TLSA query for that target; such TLSA queries are very
unlikely to produce "secure" results and have been observed
to spuriously fail even though no TLSA records are present.</t>
<t>To defend against downgrade attacks, if address record
lookup fails (this includes both the "bogus" and RFC 4035
"indeterminate" validation status) the client MUST NOT
connect to this target service endpoint; instead it uses the next
most appropriate SRV target.</t>
</list></t>
3.3. TLSA Queries
Perhaps a better split:
OLD:
<t>For example, the following SRV record for IMAP (see <xref
target='RFC6186'/>)
leads to the TLSA query shown below:</t>
<t><figure><artwork><![CDATA[
_imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.
_9143._tcp.imap.example.net. IN TLSA ?
]]></artwork></figure></t>
NEW:
<t>For example, the following SRV record for IMAP (see <xref
target='RFC6186'/>)</t>
<t><figure><artwork><![CDATA[
_imap._tcp.example.com. 86400 IN SRV 10 0 9143 imap.example.net.
]]></artwork></figure></t>
<t>leads to the TLSA query shown below:</t>
<t><figure><artwork><![CDATA[
_9143._tcp.imap.example.net. IN TLSA ?
]]></artwork></figure></t>
--
Viktor.
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
