Re: [dane] I-D Action: draft-ietf-dane-ops-08.txt (chair guidance request)

[Warren Kumari <[e-mail]>]

On Fri, May 22, 2015 at 1:34 PM, Warren Kumari <[e-mail]> wrote:
> On Thu, May 21, 2015 at 6:24 PM, Viktor Dukhovni <[e-mail]> 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
>> [e-mail]
>> 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