On 20.7.2017 19:09, Andrew Sullivan wrote:
> On Thu, Jul 20, 2017 at 06:59:42PM +0200, Ondřej Surý wrote:
>>> But it's certainly another step along the way to DNSbis by accident.
>>
>> Would it be useful to make it not "by accident"?
>
> Yes. That was basically the point I was trying to make at t
I am hearing from a number of people that this is "a new protocol" and
hence requires careful thought and perhaps a new working group, along with
the associated delay. I do not _entirely_ disagree with this position,
although it would be really inconvenient from my perspective.
However, I would
On 19.7.2017 10:50, Francis Dupont wrote:
> In your previous mail you wrote:
>
>> NSEC needs no keys, only their RRSIGs would which wouldn't exist in
>> unsigned zones. In this case the unsigned NSEC would also not be part of
>> the zone (it would have to be synthesized and maintained outside
On 20.7.2017 17:00, Stephane Bortzmeyer wrote:
> On Tue, Jul 18, 2017 at 06:20:56PM +0530,
> Mukund Sivaraman wrote
> a message of 27 lines which said:
>
>> It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned
>> zones.
>
> That's quite funny. During the development of RFC
George,
> On Jul 20, 2017, at 1:00 PM, George Michaelson wrote:
>
> I probably will not carry the WG with me on this, but I find myself
> thinking the PII aspect of client-ID makes it a wider-internet
> question and we might have views as a WG, and promote questions as a
> WG, but I think the "f
On Fri, Jul 21, 2017 at 10:24:35AM +0200, Petr Špaček wrote:
> On 19.7.2017 10:50, Francis Dupont wrote:
> > In your previous mail you wrote:
> >
> >> NSEC needs no keys, only their RRSIGs would which wouldn't exist in
> >> unsigned zones. In this case the unsigned NSEC would also not be part o
Andrew Sullivan wrote:
>
> For instance, people also express astonishment that DNSKEYs don't
> expire. Everyone always has to be reminded that signatures expire, and
> if you want to expire keys you take them out of the zone.
I agree with your message.
It might be useful to explain this DNSKEY
On Fri, Jul 21, 2017 at 1:36 PM, Tony Finch wrote:
> Andrew Sullivan wrote:
>>
>> For instance, people also express astonishment that DNSKEYs don't
>> expire. Everyone always has to be reminded that signatures expire, and
>> if you want to expire keys you take them out of the zone.
>
> I agree w
A fine bit of epistemology lies in the question: is it the same
certificate, if you re-issue it with the same keys? No, because it has
a different serial. but the crypto doesn't care, its the validation
which cares which is a product of the crypto. so validation cares but
cryptographic functions th
I've also heard the "changing the keys is good hygiene" argument -- if
someone has wandered off with your private keys (like an old
administrator) you have limited how long they can reuse them but,
a: there is room for argument and b: we have gotten way down into the
weeds here...
W
On Fri, J
On 20 July 2017 at 17:53, John R Levine wrote:
> That's why I don't share the fears about BULK: you cannot easily
>> deploy a new feature that will require a change in the resolvers,
>> because you don't know all the resolvers, and cannot change them even
>> if you know they are too old. But your
On 20 Jul 2017, at 17:00, Stephane Bortzmeyer wrote:
draft-ietf-dnsop-nsec-aggressiveuse is more aggressive (because it can
now synthetizes answers) so it seems to me the same reasons should
apply?
That it is more aggressive, -and- that it relies on a feature of DNSSEC,
suggests that we SHOUL
Hello George,
On 21 Jul 2017, at 14:58, George Michaelson wrote:
I (for one) hang onto the .req file. Maybe thats naughty, but I do, so
in my case Warren routine is that the keypair is being reused,
because.. well.. because I like to. Software I consume I suspect (like
you) doesn't, and re-mint
Tim,
On 20 Jul 2017, at 14:09, tjw ietf wrote:
Another Data Point:
One of the Apps Area ADs stopped by to tell the chairs that 1) they
like
the general idea; 2) their employer has a need for this *outside of
the PTR
space*; and 3) would be willing to shepherd the work through. Now,
they
a
Hello John,
On 20 Jul 2017, at 3:17, Woodworth, John R wrote:
Although in practice the name would likely be shorter and potentially
include other customer attributes,
say acmewabbit-21f-5bff-fec3-ab9d.example.com
1. This shows the owner is example.com, customer acmewabbit
2. Reverse look
On Fri, 21 Jul 2017, Matthew Pounsett wrote:
Dear $VENDOR.
I'm a customer who is considering deploying the BULK RR type into my zone,
and I would like to know whether your systems support it.
Thank you,
$CUSTOMER.
Dear $CUSTOMER,
Thank you for your question. Here at $VENDOR we take pride in
> -Original Message-
> From: John R Levine [mailto:jo...@taugh.com]
>
Hi John,
Thanks again for your feedback.
>
> On Thu, 20 Jul 2017, Woodworth, John R wrote:
> > Camp#2) Don't break DNS, even for a second
>
> Well, yeah, except that there's no such thing as breaking the
> DNS for a se
> From: Tony Finch [mailto:d...@dotat.at]
>
Hi Tony,
Thanks for the feedback.
>
> John R Levine wrote:
> >
> > BULK absolutely requires online DNSSEC signing,
>
> This basically means that BULK is a master-only feature, which
> implies that there's no need for BULK to work across zone
> transfe
> -Original Message-
> From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Andrew Sullivan
>
> On Thu, Jul 20, 2017 at 02:34:48PM +0100, Tony Finch wrote:
> > This basically means that BULK is a master-only feature, which implies
> > that there's no need for BULK to work across zone tr
Having said that, just what level of significance would it take
for us to bend in this respect? What type of feature, etc.?
For DNSSEC the issue was the fundamental integrity of the DNS. I
think it's fair to say that this isn't that.
...BULK absolutely requires online DNSSEC signing,
Unfo
20 matches
Mail list logo
