> 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 Apr 28, 2018, at 3:04 PM, Shumon Huque wrote:
>
> This mean "additive" mandatory or non-mandatory, I assume. Viktor opposes
> the latter case, I assume based on his (unproven) assertion that there will no
> incentive to deploy this.. I don't agree. Lots of sites already publish DANE
> fo
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, Apr 28, 2018 at 2:17 PM, Richard Barnes wrote:
>
>
> On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni
> wrote:
>
>>
>>
>> > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote:
>> >
>> >This specification can also be used to optionally convey
>> >authenticated denial of existence of
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 2:34 PM, Paul Wouters wrote:
>
> But more importantly, it does not specify what the extension content
> should be in the absense of a signed TLSA record and not wanting to
> put in the denial of existene. Are you expecting an empty payload?
> A single NULL payload? Or are
On Sat, 28 Apr 2018, Shumon Huque wrote:
TLS servers that do not have a signed TLSA record MAY instead return
a DNSSEC chain that provides authenticated denial of existence. This
specification does not require TLS servers to provide such a denial
of existence chain,
The second sen
> On Apr 28, 2018, at 2:17 PM, Richard Barnes wrote:
>
> Let's just scope this to the additive case.
When you say "additive case" do you mean to cover just applications
where the extension is mandatory? Or you expect the extension to
also have some value when it is optional?
I thought I expl
On Sat, Apr 28, 2018 at 1:52 PM Viktor Dukhovni
wrote:
>
>
> > On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote:
> >
> >This specification can also be used to optionally convey
> >authenticated denial of existence of TLSA records. Restrictive uses
> >that might require such proofs (
> On Apr 28, 2018, at 12:19 PM, Shumon Huque wrote:
>
>This specification can also be used to optionally convey
>authenticated denial of existence of TLSA records. Restrictive uses
>that might require such proofs (such as the PKIX constraining modes
>of DANE, or where DANE shou
> 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
> On Wed, Apr 18, 2018 at 2:22 PM, Joseph Salowey wrote:
> Concerns have been raised about the trade-offs associated with pinning
and I do not think we currently have consensus to add pinning. While I
think it may be possible to come to consensus on pinning I think it may
take some time. I beli
17 matches
Mail list logo
