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:
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>
--
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
