I've been thinking about this on and off.
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: 08 March 2018 23:25
I think that this and draft-putman are not competing, but rather that they
serve different use cases
Agreed. It sounds like you have a set of use cases where you
I support separation of concerns: publish as is, and start new work to
extend existing Strict Transport Security mechanisms to include DANE
authenticated TLS.
Currently the draft is describing only a single mechanism: Letting
owners of a (DNSSEC signed) domain vouch for their own TLS services.
Not
On Wed, Apr 4, 2018 at 1:50 PM, Joseph Salowey wrote:
> Hi Folks,
>
> Some objections were raised late during the review of
> the draft-ietf-tls-dnssec-chain-extension. The question before the
> working group is either to publish the document as is or to bring the
> document back into the working
> On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote:
>
> But I would also like to publish a document that has the solid
> consensus of the community that is one of key potential target
> consumers of this draft (web browsers and servers). So I'm giving
> more weight to their views and preferences
On Tue, 10 Apr 2018, Willem Toorop wrote:
I just want to clarify one misconception in Willem's statement. See my
previous emails to thist list for my full arguments on this issue.
The chain extension already contains verification of Denial Of Existence
proofs, because that is needed for verifyi
> On Apr 10, 2018, at 11:22 AM, Paul Wouters wrote:
>
> This hints at returning the proof of non-existence, but clearly even the
> authors are now saying they did not mean this and a server is not
> required to do this. Clearly the text needs clarification, and if it
> then leaves out denial of
Hi Viktor,
With no hats.
On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote:
>
>
> > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote:
> >
> > But I would also like to publish a document that has the solid
> > consensus of the community that is one of key potential target
> > cons
On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote:
[...]
> I concede that it remains useful to consider what the client will do
> with the received DANE records or denial thereof, so as to not unduly
> block off future routes for development. But it seems at least possible
> to take
> a ver
On Tue, Apr 10, 2018 at 01:25:02PM -0400, Shumon Huque wrote:
> On Tue, Apr 10, 2018 at 12:48 PM, Benjamin Kaduk wrote:
> [...]
>
> > I concede that it remains useful to consider what the client will do
> > with the received DANE records or denial thereof, so as to not unduly
> > block off future
On Tue, Apr 10, 2018 at 11:22 AM, Paul Wouters wrote:
> On Tue, 10 Apr 2018, Willem Toorop wrote:
>
> I just want to clarify one misconception in Willem's statement. See my
> previous emails to thist list for my full arguments on this issue.
>
> The chain extension already contains verification o
[I only have part of the thread available, and so am replying to the
last message I see.]
I agree that the draft MUST explicitly support chains corresponding to
a NXDOMAIN or NODATA responses to have sufficient value.
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
___
On Tue, Apr 10, 2018 at 09:48:24AM -0400, Shumon Huque wrote:
> Yes. I support the publication of the document as is.
>
> and would like to explain my position a bit.
>
> I'm very sympathetic to Viktor's desire to enhance this protocol
> to provide downgrade resistance against PKIX attacks, and I
On 4/10/18 3:53 PM, Nico Williams wrote:
> The earlier consensus is not just applicable, as if it were, we would
> not be having this LC.
I have no idea what that even means, to be honest. We're through
last call, and it's not that the earlier wg consensus isn't
"applicable," it's that you've rai
On Tue, Apr 10, 2018 at 11:48:58AM -0500, Benjamin Kaduk wrote:
> On Tue, Apr 10, 2018 at 10:20:01AM -0400, Viktor Dukhovni wrote:
> > > On Apr 10, 2018, at 9:48 AM, Shumon Huque wrote:
> > > But I would also like to publish a document that has the solid
> > > consensus of the community that is on
On Tue, Apr 10, 2018 at 04:17:14PM -0800, Melinda Shore wrote:
> On 4/10/18 3:53 PM, Nico Williams wrote:
> > The earlier consensus is not just applicable, as if it were, we would
> > not be having this LC.
>
> I have no idea what that even means, to be honest. We're through
> last call, and it's
> On Apr 10, 2018, at 8:17 PM, Melinda Shore
> wrote:
>
> There's an unfortunate number of IETF protocols that
> people worked on for years and that never saw implementation, and
> it seems to me that we ought to be trying to minimize the chances
> of that happening with the protocols we're wo
Let me synthesize one new argument, though I've implied it before, but I
think making it explicit may be useful:
The cost of making the requested changes is fixed and can be estimated
-- measured even, after the fact. I argue that cost is low. But the
cost/risk of not making the requested
17 matches
Mail list logo
