On Fri, May 22, 2015 at 1:34 PM, Warren Kumari <[email protected]> wrote:
> On Thu, May 21, 2015 at 6:24 PM, Viktor Dukhovni <[email protected]>
> wrote:
>> On Thu, May 21, 2015 at 04:08:35PM -0400, Warren Kumari wrote:
>>
>>> > 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.
>>
>> And yet the language is somewhat muddy and repetitive, and confused
>> at least John Gilmore about what it was trying to say. Furthermore
>> Section 12 disclaims consensus, but I think we should reach concensus
>> on digest agility (if we have not yet).
>>
>>> 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.
>>
>> Thanks. I'll remove the note, but I would very much like to improve
>> the clarity of the section 9 text (without changing the technical
>> content). I have such an update queued-up. How might we proceed
>> to adopt it?
>
>
> Does anyone have any useful clarity improvement suggestions?
> We'll wait until 12:00PM UTC on Wednesday (20:00ET), otherwise we'll
> go ahead with the text as written, and ask Viktor to include it.
<no hats>
... I have some very small grammar / readability suggestions.
Take them if you like them, or ignore if you don't....
------
<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
[O]: Such a protocol allows the client and server
[P]: Such a protocol would allow the client and server
[C]: We haven't specified the protocol yet, so different tense for
readability.
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>
[WK] ... we hope -- or we have some *serious* issues. :-P
<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>
[O]: 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.
[P]: While all clients SHOULD implement ordering of digest algorithms
by strength, each client is free to decide upon the order of digest
algorithms,
from strongest to weakest. Client implementations SHOULD make the digest
algorithm preference ordering a configurable option.
[C]: The original paragraph is unclear as to whether the client can choose the
order of the algorithms or whether the client can choose to implement this
feature at all.
<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>
-----
</no-hats>
>
> W
>
>
>>
>> --
>> Viktor.
>>
>> _______________________________________________
>> 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
--
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
