All,
This seems like a tremendously useful document to have out there. Thanks to the
authors for the effort and I suspect discussion on the list would be helpful.
As a general reminder, we had a very productive meeting in Honolulu, and now
we're about halfway from there to Dallas (somewhere
Oh, It's a great work and helpful as a collection of important DNS
terminology. It's not easy to choose the terminology from massive
DNS-related RFCs.
By the way, I notice the Priming is not included in the draft. I think it
is a common jargon(not documented yet) used in the community. There
On 16-01-15 23:04, Bob Harold wrote:
There seem to be a lot of set CLASS to ANY in the spec. But I thought
that a.b.c class IN was totally unrelated to a.b.c class CHAOS, and
deleting or changing one should not affect the other. Or am I
To clarify: A record with its CLASS set to ANY does
Greetings again. Andrew, Kazunori, and I have done a massive revision on the
DNS terminology draft based on the input we got on the -00. We're sure we have
further to go, but we wanted people to look over the new version and give
feedback. Thanks!
Name: draft-hoffman-dns-terminology
In your previous mail you wrote:
Currently a number of validators don't do ECC, because of the openssl
library from the distribution they are using doesn't include support.
This makes ECC an unsupported algorithm, and so it fails open (See
RFC4035, Section 5.2, around If the validator
I think its possible people have misunderstood what we said, when we
measured 'do not understand ECDSA' as a problem and presented on it.
It is a tenable, arguable case, that PRECISELY because the fail mode is
'unsigned' we can move to ECDSA more easily than any other key transition
under
Next release of Net::DNS::SEC will support ECDSA and ECC-GOST
Dick Franks
On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote:
On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr
wrote:
In your previous mail you wrote:
On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr
wrote:
In your previous mail you wrote:
Currently a number of validators don't do ECC, because of the openssl
library from the distribution they are using doesn't include support.
This makes ECC an unsupported
Next release of Net::DNS::SEC will support ECDSA and ECC-GOST
Dick Franks
On 19 January 2015 at 15:17, Warren Kumari war...@kumari.net wrote:
On Monday, January 19, 2015, Francis Dupont francis.dup...@fdupont.fr
wrote:
In your previous mail you wrote:
On Mon, 19 Jan 2015, Paul Hoffman wrote:
If we want small, short tractable signatures in DNS, moving to eCDSA is easier
now than at any other time. We just have to accept we make a lot of DNSSEC
clients stop validating until code updates.
A big +1 to this.
A big -1 to this. You suggest
More comments inline.
--
Bob Harold
On Mon, Jan 19, 2015 at 3:50 AM, Matthijs Mekking matth...@pletterpet.nl
wrote:
On 16-01-15 23:04, Bob Harold wrote:
There seem to be a lot of set CLASS to ANY in the spec. But I thought
that a.b.c class IN was totally unrelated to a.b.c class CHAOS,
On Jan 19, 2015, at 7:30 AM, George Michaelson g...@algebras.org wrote:
I think its possible people have misunderstood what we said, when we measured
'do not understand ECDSA' as a problem and presented on it.
It is a tenable, arguable case, that PRECISELY because the fail mode is
On Monday, January 19, 2015, George Michaelson g...@algebras.org wrote:
I think its possible people have misunderstood what we said, when we
measured 'do not understand ECDSA' as a problem and presented on it.
Dunno. I think many / most folk got it, at least in the venues I saw it..
Let me clarify things a bit,
The root ZSK key is 1024 because of assumed packet size issues.
nohats.ca is currently publishing 3 2048 bit keys, and has a message
size as reported by dig of 1163. That's even under 1500 (and came in on
UDP). So what's the problem of moving the root ZSK to 2048?
On Mon, Jan 19, 2015 at 1:01 PM, Matthijs Mekking matth...@pletterpet.nl
wrote:
On 19-01-15 18:43, Bob Harold wrote:
More comments inline.
--
Bob Harold
On Mon, Jan 19, 2015 at 3:50 AM, Matthijs Mekking
matth...@pletterpet.nl mailto:matth...@pletterpet.nl wrote:
On 16-01-15
On 19-01-15 18:43, Bob Harold wrote:
More comments inline.
--
Bob Harold
On Mon, Jan 19, 2015 at 3:50 AM, Matthijs Mekking
matth...@pletterpet.nl mailto:matth...@pletterpet.nl wrote:
On 16-01-15 23:04, Bob Harold wrote:
There seem to be a lot of set CLASS to ANY in the spec.
Another take on this, which may make some people feel very uncomfortable,
is to propose key migration in RSA via a downgrade keylength:
sign with a shorter RSA key, and re-sign with a long one once the original
long one is widely deprecated under 5011.
1024- new512 (!) - new1024
this avoids
Bob Harold rharo...@umich.edu wrote:
I don't see anywhere that CLASS is NOT set to ANY,
That happens when adding a record (section 3.2). Compare RFC 2136 section 2.5.
Tony.
--
f.anthony.n.finch d...@dotat.at http://dotat.at/
Viking: South or southeast 5 to 7, perhaps gale 8 later. Moderate
18 matches
Mail list logo
