On Sat, May 16, 2015 at 1:42 AM, Viktor Dukhovni <[email protected]> wrote: > On Fri, May 15, 2015 at 06:03:32AM +0000, Viktor Dukhovni wrote: >> On Thu, May 14, 2015 at 11:44:54AM +0200, nudge wrote: >> >> > I've slightly reworded your text for clarity: >> >> Thanks, with guidance from the chairs, I'll merge as much as I can. > > Inspired by the proposed improvement, the below takes a stab at > further clarity and elimination of redundancy. I realize it is > late in the process, so guidace on whether/when/how to improve > this section would be helpful. New section 9 text below the > "signature" line. > > With Section 9 ideally no longer under a cloud of uncertainty, > we would also update section 12:
We have heard nothing from the working group saying that they are unhappy with the new section 9, and it seems clear. > > OLD: > <t> In <xref target="agility"/>, we propose a digest algorithm > agility protocol. [Note: This section does not yet represent > the rough consensus of the DANE working group and requires further > discussion. Perhaps this belongs in a separate document.] </t> > > NEW: > <t> In <xref target="agility"/>, we specify a digest algorithm > agility protocol. </t> The Working Group reviewed this document, and we called consensus on it (and then waited a bit to see if anyone came out of the woodwork, looking sad), and so I believe that this *does* have WG consensus, and so the [Note:...] can be removed. W > > -- > Viktor. > > <t> > While <xref target="RFC6698"/> specifies multiple digest algorithms, > it does not specify a protocol by which the client and TLSA record > publisher can agree on the strongest shared algorithm. Such a > protocol allows the client and server to avoid exposure to > deprecated weaker algorithms that are published for compatibility > with less capable clients, but which SHOULD be avoided 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 alongside > stronger digest algorithms. Note that this protocol never avoids > RRs with DANE matching type Full(0), as these do not employ a > digest algorithm that might some day be weakened by cryptanalysis. > </t> > > <t> > The ordering of digest algorithms by strength is not specified > in advance; it is entirely up to the client. Client implementations > SHOULD make the digest algorithm preference ordering a configurable > option. > </t> > > <t> > To make digest algorithm agility possible, all published DANE > TLSA RRsets MUST conform to the requirements of <xref target="rrreq"/>. > Clients SHOULD use digest algorithm agility when processing the > peer's DANE TLSA records. Algorithm agility is to be applied > after first discarding any unusable or malformed records (unsupported > digest algorithm, or incorrect digest length). 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> > > <t> > Example: a client implements digest agility and prefers SHA2-512(2) > over SHA2-256(1), while the server publishes an RRset that employs > both digest algorithms as well as a Full(0) record. > </t> > > <figure> > <artwork> > _25._tcp.mail.example.com. IN TLSA 3 1 1 ( > 3FE246A848798236DD2AB78D39F0651D > 6B6E7CA8E2984012EB0A2E1AC8A87B72 ) > _25._tcp.mail.example.com. IN TLSA 3 1 2 ( > D4F5AF015B46C5057B841C7E7BAB759C > BF029526D29520C5BE6A32C67475439E > 54AB3A945D80C743347C9BD4DADC9D8D > 57FAB78EAA835362F3CA07CCC19A3214 ) > _25._tcp.mail.example.com. IN TLSA 3 1 0 ( > 3059301306072A8648CE3D020106082A > 8648CE3D0301070342000471CB1F504F > 9E4B33971376C005445DACD33CD79A28 > 81C3DED1981F18E7AAA76609DD0E4EF2 > 8265C82703030AD60C5DBA6FB8A9397A > C0FCF06D424C885D484887 ) > </artwork> > </figure> > > <t> > In this case the client SHOULD accept a server public key that > matches either the "3 1 0" record or the "3 1 2" record, but > SHOULD not accept keys that match only the weaker "3 1 1" record. > </t> > > _______________________________________________ > dane mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dane -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
