Subject: Re: [dane] #33: Publish enough information for the client to achieve the security of its favorite digest

From: Zack Weinberg <[email-masked]>
Date: Mon, 03 Oct 2011 13:11:01 -0700

On 2011-09-30 10:27 PM, Matt McCutchen wrote:
> On Fri, 2011-09-30 at 11:03 -0700, Zack Weinberg wrote:
>> To put all digests of one cert in one RR, you would
>> need to define a parseable format for the data portion.
>
> Yes, it could be something trivial like:
>
> (cert usage, selector, (algorithm ID, 16-bit length, value)*)

I agree that parsing this would not be that much of a headache.

>> As far as I
>> know there is no other RR that needs this treatment, so we'd be making
>> up something new and adding code to all clients. If we keep it to one
>> digest per RR, we get the same functionality for free.
>
> What functionality are you envisioning reusing?

The functionality of segmenting DNS reply *packets* into RRs.

> I'm not convinced that solution 1 does in fact require more code.  I'd
> imagine the code to parse the RDATA into individual digest values would
> be comparable in size to the code to collate RRs by group ID for
> solution 3.  The rest is two levels of iteration, either way.

This is also a valid point.  And since the consensus seems to be against 
*either* 1 or 3 right now, it's notable that only option 1 can be 
deployed later without defining a new RRtype (we'd have to define a new 
"sequence-of" reference type, but that's easier than a whole new RR).

I wonder if the WG would be willing to consider reserving a byte in the 
RR against the possibility that group IDs, disjunctions, or something 
else yet-unforeseen will become necessary in the future.

zw

---

From: Warren Kumari <[email-masked]>
Date: Wed, 5 Oct 2011 12:44:33 -0400

Ok, and we are calling this.

There was *not* support consensus for the 3 solutions (individually or as a group) and so we will be closing the issue.

I apologize in advance for the summary[0], but I wanted to capture the view of the WG in one place, so this issue can finally be put to bed, once and for all...
W

[0]: I realize that summarizing your views down to one sentence necessarily loses much info -- please let me know if my summary misrepresents your position...

----------------------------------------------------------

Paul Hoffman, Sept 28th: I do not support any of the three, for the reasons given before.

Martin Rex, Sept 28th:
-.5   1. All digests of one cert in one RR
-.5   2. Cartesian product requirement
-.5   3. Group ID

Jim Schaad, Sept 29th: You may not think it makes sense, however some of us do. (in response to: "I do not see the situation in which the halfway job of algorithm agility we have now makes sense.")

Stephen Kent, Sept 29th: I am not in favor of any of these three options for dealing with hash alg agility.

Matt McCutchen, Sept 28th:
1. All digests of one cert in one RR: +1
2. Cartesian product requirement: +1
3. Group ID: +1

Jakob Schlyter, Sept 29th: no support from me.

Richard Barnes, Sept 29th: That's a +1 for "no support".  I included the -3 to try and clarify that it was three negative votes :)

Ondrej Sury, Sept 29th:
1. All digests of one cert in one RR (-1)2. Cartesian product requirement (-1)3. Group ID (-1)

Zack Weinberg, Sept 29th:
I am +1 on the use case -- that is, I am in favor of providing for
(what I understand to be) Matt's goals in *some* fashion.  Of the
available options:
1. All digests of one cert in one RR  -1: unwieldy, complicates client-side processing.
2. Cartesian product requirement  -0: simple and reliable, but imposes potentially enormous wire overhead.
3. Group ID  +1

Bill Manning, Sept 29th: i agree w/ steve here.  No support for any of the three options.

Phillip Hallam-Baker, Sept 30th: I agree with Steve, no support for any of the mechanisms.

--------------------

On Sep 29, 2011, at 9:32 AM, Warren Kumari wrote:

> 
> On Sep 28, 2011, at 10:53 PM, Matt McCutchen wrote:
> 
>> On Wed, 2011-09-28 at 17:02 -0400, Warren Kumari wrote:
>>> And if folk do wish to show support for any of the 3 solutions I ask that they do it by Friday 13:00UTC.
>> 
>> Man, that is a short consensus call.
> 
> If you had spoken to the chairs before kicking this off....
> 
> But I realize I'm being petty, so fine, lets extend it till Wednesday, that will be 7 days.
> 
> W
> 
> 
>> 
>> 
>> For others' convenience in replying:
>> 
>> 1. All digests of one cert in one RR
>> 2. Cartesian product requirement
>> 3. Group ID
>> 
>> -- 
>> Matt
>> 
>> _______________________________________________
>> dane mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dane
>> 
>

---

From: "dane issue tracker" <[email-masked]>
Date: Wed, 05 Oct 2011 17:31:45 -0000

#33: Publish enough information for the client to achieve the security of its
favorite digest

Changes (by warren@…):

 * status:  new => closed
 * resolution:   => wontfix

Comment:

 There was *not* support consensus for the 3 solutions (individually or as
 a group) and so we will be closing the issue.

 Ref: http://www.ietf.org/mail-archive/web/dane/current/msg03631.html

-- 
----------------------+-----------------------------------------
 Reporter:  matt@…    |       Owner:  draft-ietf-dane-protocol@…
     Type:  defect    |      Status:  closed
 Priority:  major     |   Milestone:
Component:  protocol  |     Version:
 Severity:  -         |  Resolution:  wontfix
 Keywords:            |
----------------------+-----------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/33#comment:5>
dane <http://tools.ietf.org/dane/>