> On May 3, 2018, at 8:54 AM, Benjamin Kaduk wrote:
>
> (2) It is asking the WG to take on faith and Paul/Viktor/Nico's authority
> that the 16-bit value (in hours) is sufficient, and no other fields or
> semantic changes would be needed. While I (and presumably others) do have
> a great deal
On Sat, Apr 28, 2018 at 01:40:25PM -0400, Viktor Dukhovni wrote:
>
>
> We may yet have to see how much support or opposition the follow-on
> document will meet. What continues to be puzzling is resistance to
> adding a field that imposes negligible burden on the present spec,
> and would clearly
On Sat, Apr 28, 2018 at 03:01:34PM -0400, Paul Wouters wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote:
>
> [ not going to repeat my technical arguments here, just going to comment
> on process ]
>
> >First, there is no agreement that your reason for doing pinning,
> >i.e. that DANE needs downgr
> On Apr 28, 2018, at 4:11 PM, Shumon Huque wrote:
>
> What greatly surprised me was that Viktor (and you) did not come to
> this realization until a few months ago (I believe that was shortly after I
> asked Viktor in private email to read the entire draft and I assume he
> came upon the text
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote:
>
> This can be clearly seen from various comments on
>> list and at IETF/London, such as the point made many times that
>> the original purpose of this draft was to add DANE as an additional
>> possib
> On Apr 28, 2018, at 3:28 PM, Shumon Huque wrote:
>
> Sadly, only a handful of people are actually participating on the list.
> What you are ignoring is the many people who spoke up in person at
> IETF/London against pinning. Most of those folks are not speaking up
> on list now. So if we d
On Sat, Apr 28, 2018 at 3:01 PM, Paul Wouters wrote:
> On Sat, 28 Apr 2018, Shumon Huque wrote:
>
> [ not going to repeat my technical arguments here, just going to comment
> on process ]
>
> First, there is no agreement that your reason for doing pinning,
>> i.e. that DANE needs downgrade resist
On Sat, 28 Apr 2018, Shumon Huque wrote:
I wish I could be confident that such a specification would
be allowed to move forward. My fear is that the same visceral
opposition to DANE and DNSSEC would play out, and so I may as
well try to get past these now.
I would like
On Sat, 28 Apr 2018, Shumon Huque wrote:
[ not going to repeat my technical arguments here, just going to comment
on process ]
First, there is no agreement that your reason for doing pinning,
i.e. that DANE needs downgrade resistance against PKIX attacks
is even valid.
This is incorrect. From
On Sat, Apr 28, 2018 at 1:40 PM, Viktor Dukhovni
wrote:
>
> > On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote:
> >
> > So moving this feature into a new optional
> > extension (both the pinning field and a description of the associated
> > behavior) appears to me to be the past of least resista
> On Apr 28, 2018, at 12:26 PM, Shumon Huque wrote:
>
> I am in support of doing the pinning in a new extension, and will
> even help you write the draft if you like. I'm pretty sure we could
> have easily done this in the time that has been taken up on list
> endlessly and repetitively discuss
On Fri, Apr 27, 2018 at 4:17 PM, Viktor Dukhovni
wrote:
>
> It would be helpful to know where opponents stand on negotiating
> continued use of the extension in general and in the future. We
> are confused by their statements so far, and wonder if they are
> not just generally in opposition to a
12 matches
Mail list logo
