> On Apr 26, 2018, at 11:41 AM, Eric Rescorla wrote:
>
> This discussion would probably be a lot more productive if you were
> able to have it without accusing other participants of acting in bad
> faith.
[ Well the objections do seem rather hypothetical, and the thing being
objected to (a 1
On Thu, Apr 26, 2018 at 11:53:29AM -0400, Viktor Dukhovni wrote:
> Of course given evermore sophisticated BGP attacks:
>
> https://blog.cloudflare.com/bgp-leaks-and-crypto-currencies/
>
> you might actually want to consider DNSSEC, implement it properly
> and monitor, and the bricking won't hap
On Thu, Apr 26, 2018 at 08:41:18AM -0700, Eric Rescorla wrote:
> On Thu, Apr 26, 2018 at 8:22 AM, Nico Williams
> wrote:
> > Because we'd pin only to the use of this extension, the TTL is
> > sufficient.
>
> I explained in my response to Victor why this isn't so.
I don't accept that explanation.
On Thu, Apr 26, 2018 at 11:41:05AM -0400, Richard Barnes wrote:
> On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams
> wrote:
>
> > On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> > > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni > >
> > > wrote:
> > > > On Apr 26, 2018, Eric Re
> On Apr 26, 2018, at 11:41 AM, Richard Barnes wrote:
>
> Until my DNSSEC signing infra breaks, the signatures expire, and now my
> server is bricked.
If that happens, you're bricked anyway, the 1.1.1.1, 8.8.8.8, 9.9.9.9,
64.6.64.6, ... resolvers all validate and are used by a broad and
rapid
On Thu, Apr 26, 2018 at 8:22 AM, Nico Williams
wrote:
> On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni >
> > wrote:
> > > On Apr 26, 2018, Eric Rescorla wrote:
> > >
> > > * a lifetime field
> > > * enforce vs. test
> > >
On Thu, Apr 26, 2018 at 11:22 AM, Nico Williams
wrote:
> On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> > On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni >
> > wrote:
> > > On Apr 26, 2018, Eric Rescorla wrote:
> > >
> > > * a lifetime field
> > > * enforce vs. test
> > >
On Wed, 25 Apr 2018, Eric Rescorla wrote:
The conventional reason to reserve this kind of field is that you need to leave
space for an extension in some PDU, because it's hard to add later. But that's
not true here (or in TLS in general) because we already have an extension
mechanism (indeed, th
On Thu, Apr 26, 2018 at 07:50:08AM -0700, Eric Rescorla wrote:
> On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni
> wrote:
> > On Apr 26, 2018, Eric Rescorla wrote:
> >
> > * a lifetime field
> > * enforce vs. test
> > * a report URI
We will need only the TTL. We will not need anything el
On Thu, Apr 26, 2018 at 11:13 AM, Nico Williams
wrote:
> On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote:
> > Thanks for producing some text. I understand why one might think that
> > having a reserved 16-bit field is useful here, but I don't really
> > agree.
> >
> > The convention
On Wed, Apr 25, 2018 at 11:30:02PM -0700, Eric Rescorla wrote:
> Thanks for producing some text. I understand why one might think that
> having a reserved 16-bit field is useful here, but I don't really
> agree.
>
> The conventional reason to reserve this kind of field is that you need
> to leave
On Thu, Apr 26, 2018 at 8:05 AM, Viktor Dukhovni
wrote:
>
>
> > On Apr 26, 2018, at 10:50 AM, Eric Rescorla wrote:
> >
> >> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
> >> find:
> >>
> >> * a lifetime field
> >> * enforce vs. test
> >> * a report URI
> >>
> >> This spec
> On Apr 26, 2018, at 10:50 AM, Eric Rescorla wrote:
>
>> If we look at Expect-CT and MTA-STS + companion SMTP-TLSRPT we
>> find:
>>
>> * a lifetime field
>> * enforce vs. test
>> * a report URI
>>
>> This specification is always "enforce" (though my pull request
>> changes a MUST use D
On Thu, Apr 26, 2018 at 6:51 AM, Viktor Dukhovni
wrote:
>
>
> > On Apr 26, 2018, at 2:30 AM, Eric Rescorla wrote:
> >
> > If you look at HPKP and Expect-CT, you will note that there are a number
> of
> > other fields besides just lifetime (report-uri, include subdomains). I
> recognize
> > that
> On Apr 26, 2018, at 2:30 AM, Eric Rescorla wrote:
>
> If you look at HPKP and Expect-CT, you will note that there are a number of
> other fields besides just lifetime (report-uri, include subdomains). I
> recognize
> that opinions vary about whether these are good, but the advantage of havin
Hi Victor,
Thanks for producing some text. I understand why one might think that
having a
reserved 16-bit field is useful here, but I don't really agree.
The conventional reason to reserve this kind of field is that you need to
leave
space for an extension in some PDU, because it's hard to add la
> On Apr 26, 2018, at 12:13 AM, Joseph Salowey wrote:
>
> This proposal is quite a bit more than just a two byte reserved field.
I am not sure what you mean. The proposed text adds the field, tells
servers to set it to zero, and tells clients to treat it as though it
were zero even if a non-z
On Wed, Apr 25, 2018 at 09:13:37PM -0700, Joseph Salowey wrote:
> This proposal is quite a bit more than just a two byte reserved field.
What, Viktor's text? Most of it has to do with the denial of existence,
not with those two bytes.
___
TLS mailing l
> On Apr 25, 2018, at 10:02 AM, Willem Toorop wrote:
>
> If you do, could you please make separate pull requests for denial of
> existence and another one for the lifetime field.
I made a single pull request with two commits, I hope that's OK.
The 16-bit field is the second commit, and if that
This proposal is quite a bit more than just a two byte reserved field.
On Wed, Apr 25, 2018 at 8:46 AM, Nico Williams
wrote:
> On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote:
> > On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote:
> > > On Wed, Apr 25, 2018 at 11:51:58A
On Wed, Apr 25, 2018 at 10:40:02AM -0500, Nico Williams wrote:
> On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote:
> > On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote:
> > > On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > > > Perhaps a concrete proposal will make it
> > >
On Wed, Apr 25, 2018 at 09:57:22AM -0500, Nico Williams wrote:
> On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote:
> > On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > > Perhaps a concrete proposal will make it
> > > easier to reach a mutually-agreeable consensus position, and make it
>
To clarify, I asked for exact text to understand better what is being asked
for, since it wasn't very clear to me what the scope fo the change is.
On Wed, Apr 25, 2018 at 2:51 AM, Melinda Shore wrote:
> On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > Perhaps a concrete proposal will make it
> > e
> On Apr 25, 2018, at 10:02 AM, Willem Toorop wrote:
>
> We're actually working on
>
> https://github.com/tlswg/dnssec-chain-extension
>
>
>> if there's interest in me doing that. Below I list OLD/NEW text
>> chunks with the name of the section in which they fit.
>
> If you do, could
On Wed, Apr 25, 2018 at 11:51:58AM +0200, Melinda Shore wrote:
> On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> > Perhaps a concrete proposal will make it
> > easier to reach a mutually-agreeable consensus position, and make it
> > clear that the requested 16-bits are a reasonable consensus outcome.
Op 25-04-18 om 07:33 schreef Viktor Dukhovni:
>The following is a TLSA RRset denial-of-existence example:
>
> example.com. IN SOA
> RRSIG(example.com. SOA)
> example.com. IN NSEC www.example.com. SOA NS MX A RRSIG NSEC
Hopefully the DNSKEY rrtype is incl
Thanks for the suggestions,
Op 25-04-18 om 07:33 schreef Viktor Dukhovni:
>
> I've been asked to write up proposed changes to the DNSSEC chain
> extension draft (with the 16-bit extension support lifetime field).
> In doing that I've discovered that adding the 16-bit field is a
> minor tweak to t
On 4/25/18 7:33 AM, Viktor Dukhovni wrote:
> Perhaps a concrete proposal will make it
> easier to reach a mutually-agreeable consensus position, and make it
> clear that the requested 16-bits are a reasonable consensus outcome.
Hi, Viktor:
This doesn't actually reflect the consensus called by the
28 matches
Mail list logo
