Barry Leiba has entered the following ballot position for
draft-ietf-dnsop-rfc2845bis-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to h
On Tuesday, 10 March 2020 02:42:01 UTC Erik Nygren wrote:
> On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie wrote:
> > On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> > > ...
> >
> > i propose that section 6.2 for "port", and all references to same, be
> > removed.
>
> We discussed this so
On Mon, Jan 20, 2020 at 3:21 PM Shumon Huque wrote:
>
> On Sun, Jan 12, 2020 at 9:24 PM Warren Kumari wrote:
>
>> Hi there,
>>
>> Firstly, thank you for a well written and easy to understand document.
>>
>> I have some comments which I think should be addressed before I start
>> IETF LC, but the
On Mon, Mar 9, 2020 at 10:32 PM Paul Vixie wrote:
> On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> > It occurs to me that I hit "publish" on this draft without updating the
> > release notes, so I'll mention some of the many changes since -01 here
> > instead:
> >
> > ...
> >
> > As
Paul Hoffman wrote:
> This confuses a harm purposely caused by authorities (in this case, the
> IETF), with self-harm (in this case, a zone owner who didn't hear about
> the importance of doing an algorithm rollover, or did hear but didn't
> care). They are quite different.
Also I think you hav
On Monday, 9 March 2020 20:56:39 UTC Ben Schwartz wrote:
> It occurs to me that I hit "publish" on this draft without updating the
> release notes, so I'll mention some of the many changes since -01 here
> instead:
>
> ...
>
> As always, please review and send comments. We also expect to do a
>
Paul Hoffman wrote:
> On Mar 9, 2020, at 6:46 PM, Tony Finch wrote:
> > Which is why the timetable aims to stop the use of SHA-1 for signing
> > before it stops the use of SHA-1 for validating, assuming
> > optimistically that we actually have 2 years available. (I fear we
> > don't.)
>
> Who is
On Mar 9, 2020, at 6:46 PM, Tony Finch wrote:
>
> Paul Hoffman wrote:
>>
>> This draft is about discouraging people from signing with SHA-1 by
>> directly harming them (implementations that will no longer be able to
>> validate their signatures). While threats of direct harm are probably
>> eff
Paul Wouters wrote:
>
> Obsoleting really takes time. And the path is to first stop producing
> SHA1 signatures, and once that number goes down, to start discouraging
> consuming SHA1 signatures. If you immediately say MUST NOT for validating,
> you are making 2211449 + 287467 = 2.5M domains more
> On 10 Mar 2020, at 12:42, Paul Wouters wrote:
>
> On Mon, 9 Mar 2020, Tony Finch wrote:
>
>> The aim of this is to deprecate SHA-1 algorithms 5 and 7 more vigorously.
>> I've put in a fairly specific timetable for sake of argument, basically to
>> set up the death of SHA-1 as next year's DNS
Paul Hoffman wrote:
>
> This draft is about discouraging people from signing with SHA-1 by
> directly harming them (implementations that will no longer be able to
> validate their signatures). While threats of direct harm are probably
> effective at getting to a desired outcome, they do not repres
On Mon, 9 Mar 2020, Tony Finch wrote:
The aim of this is to deprecate SHA-1 algorithms 5 and 7 more vigorously.
I've put in a fairly specific timetable for sake of argument, basically to
set up the death of SHA-1 as next year's DNS "flag day", unless some
clever cryptanalysis forces it to happen
On Thu, Feb 27, 2020 at 11:48 AM Daniel Migault wrote:
> Hi,
>
> I read draft-ietf-dnsop-svcb-httpssvc-01. Please find find some comments
> (with my questions) below I had while reading linearly the document. I hope
> this will help.
>
Thanks for the comments, and sorry about the delay.
>
> Yo
On Mar 9, 2020, at 4:16 PM, Tony Finch wrote:
>
> The aim of this is to deprecate SHA-1 algorithms 5 and 7 more vigorously.
> I've put in a fairly specific timetable for sake of argument, basically to
> set up the death of SHA-1 as next year's DNS "flag day", unless some
> clever cryptanalysis fo
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Message Digest for DNS Zones
Authors : Duane Wessels
Piet Barber
The aim of this is to deprecate SHA-1 algorithms 5 and 7 more vigorously.
I've put in a fairly specific timetable for sake of argument, basically to
set up the death of SHA-1 as next year's DNS "flag day", unless some
clever cryptanalysis forces it to happen sooner.
I'm afraid it's a rough first p
On 3/9/2020 4:46 PM, Wessels, Duane wrote:
Michael StJohns pointed out (Feb 25) that a verifier that does not
recognise a particular
ZONEMD Scheme and/or Hash Algorithm may be unable to create the
required placeholders,
and therefore unable to perform a verification using any
(Scheme,Algorithm) a
It occurs to me that I hit "publish" on this draft without updating the
release notes, so I'll mention some of the many changes since -01 here
instead:
- All changes to Alt-Svc have been removed. I would like to see some
updates to Alt-Svc, but since this draft is now in DNSOP, and any changes
t
> On Mar 9, 2020, at 9:37 AM, Dick Franks wrote:
>
>
>>> [3.1 para 1]
>>>
>>> In preparation for calculating the zone digest, any existing ZONEMD
>>> + and covering RRSIG
>>> records at the zone apex are first deleted.
>>>
>>> [3.1 para 1]
>>>
>>> Prior to calculation of the digest, and
> On Mar 8, 2020, at 11:10 PM, Dick Franks wrote:
>
> draft-ietf-dnsop-dns-zone-digest-04 is still a work in progress, with a
> number of internal contradictions to be resolved.
>
>
> [1.2 para 1]
>
> ... The procedures for digest calculation and DNSSEC
> signing are similar (i.e., both
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : Service binding and parameter specification via the
DNS (DNS SVCB and HTTPSSVC)
Authors : Ben
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.
Title : DNS Query Name Minimisation to Improve Privacy
Authors : Stephane Bortzmeyer
Response in line
On Mon, 9 Mar 2020 at 07:20, Mark Andrews wrote:
>8
> > [1.2 para 1]
> >
> > ... The procedures for digest calculation and DNSSEC
> > signing are similar (i.e., both require the same ordering of RRs) and
> > can be done in parallel.
> >
> > There is no requirement for th
** We have extended the submissions deadline for the 33rd DNS-OARC
** workshop to March 19th 2020 (midnight CEST).
The 33rd DNS-OARC Workshop will take place at the Marriott Rive Gauche
Hotel & Conference Center in Paris, France on May 9th and 10th 2020. It
is co-located with and will take place r
Éric Vyncke has entered the following ballot position for
draft-ietf-dnsop-rfc2845bis-07: No Objection
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to h
> On 9 Mar 2020, at 17:10, Dick Franks wrote:
>
> draft-ietf-dnsop-dns-zone-digest-04 is still a work in progress, with a
> number of internal contradictions to be resolved.
>
>
> [1.2 para 1]
>
> ... The procedures for digest calculation and DNSSEC
> signing are similar (i.e., both re
26 matches
Mail list logo
