On Thu, May 14, 2015 at 01:07:41AM +0000, Viktor Dukhovni wrote:
> I'll put together more clear language for Section 9 promptly.
Below my "signature" is a proposed rewording of Section 9. I
believe it says the same thing it said (or at least tried to say)
all along, only much more clearly.
I'd also like to remove the "weasel words" from Section 12 that
disclaim consensus on Digest Agility. This passed through last
with no objections and has been in the draft for quite some time.
I need guidance from the chairs on how to proceed. [Chairs?]
--
Viktor.
<t>
While <xref target="RFC6698"/> specifies multiple digest algorithms,
it does not specify a protocol by which the TLS client and TLSA
record publisher can agree on the strongest shared algorithm.
Such a protocol would allow the client and server to avoid exposure
to any deprecated weaker algorithms that are published for
compatibility with less capable clients, but should be ignored
when possible. We specify such a protocol below.
</t>
<t>
This section defines a protocol for avoiding deprecated digest
algorithms when these are published in a peer's TLSA RRset
along-side stronger algorithms. A mixture of algorithms may be
present in server TLSA records to allow for interoperability with
legacy or constrained clients. In particular, this protocol never
avoids any RRs with DANE matching type Full(0), as these do not
employ any potentially tarnished digest algorithm.
</t>
<t>
Suppose a server's TLSA RRset contains RRs with more than one
digest matching type. Suppose also that the server adheres to
the requirements of <xref target="rrreq"/> and ensures that each
combination of TLSA parameters contains at least one record that
matches the server's current certificate chain (or raw public
keys). Under the above assumptions it suffices for the client
to identify a most preferred digest algorithm among those published
in the TLSA RRset, and process only records that algorithm in
addition to any records with matching type Full(0).
</t>
<t>
To make digest algorithm agility possible, all published DANE
TLSA RRsets MUST conform to the requirements of <xref target="rrreq"/>.
With servers publishing compliant TLSA RRsets, TLS clients MAY,
for each combination of usage and selector, ignore all digest-based
RRs except those that employ the strongest digest algorithm. The
client then processes only any records with matching type Full(0)
and those with the best published digest algorithm.
</t>
<t>
The ordering of digest algorithms by strength is not specified
in advance; it is entirely up to the TLS client. TLS client
implementations SHOULD make the digest algorithm preference
ordering a configurable option.
</t>
<t>
TLS clients SHOULD use digest algorithm agility when processing
the DANE TLSA records of an TLS server. Algorithm agility is to
be applied after first discarding any unusable or malformed records
(unsupported digest algorithm, or incorrect digest length). Thus,
for each usage and selector, the client SHOULD process only any
usable records with a matching type of Full(0) and the usable records
whose digest algorithm is considered by the client to be the strongest
among usable records with the given usage and selector.
</t>
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
