On Thu, 14 May 2015, at 07:09 AM, Viktor Dukhovni wrote: > 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, I've slightly reworded your text for clarity: <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 MUST 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> If a server's TLSA RRset contains RRs with more than one digest matching type and adheres to the requirements of <xref target="rrreq"/> with each combination of TLSA parameters containing at least one record that matches the server's current certificate chain (or raw public keys) then under these circumstances, a client MAY identify its preferred digest algorithm and only process records for that algorithm, in addition to any records with matching type Full(0). </t> <t> To allow for digest algorithm agility, 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 those RRs plus any records with matching type Full(0) </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 a TLS server. Any algorithm agility MUST 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 usable records whose digest algorithm is considered to be the strongest, as well as any records with a matching type of Full(0). </t> -- Thanks, Ian Maddison _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
