Follow up,
I thought again about the possible attacks scenarios. I concluded that I
also need to include the new public key in the content of the old signature.
This means the old signature should be new public key + timestamp,
otherwise the attacker might have a possibility (a few seconds) to do
On 2/15/2014 11:15 PM, Patrik Fältström wrote:
The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be that innovation of DNS is not possible unless it
involves reuse of the TXT resource record.
That assertion is quite wrong on both process and technical
Dear Marc,
Thanks again for your message.
Let me first react to your first email of today. CGA uses the
RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I
understand it as explained at
http://tools.ietf.org/html/rfc3447#section-8.2.1 is that the length of the
output
On Feb 15, 2014, at 11:15 PM, Patrik Fältström p...@frobbit.se wrote:
On 2014-02-16 03:04, David Conrad wrote:
Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a
seeding ground)?
The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be
On 02/16/2014 04:52 PM, Paul Hoffman wrote:
Sorry, friend, but this is trolling. Or do you believe that DANE is not an
innovation?
Well, I personally am not so sure that the delta to CERT records (RFC
4398) is all that big,
so is this really the best example you have? ;-).
On 2/16/2014 6:03 AM, Patrik Fältström wrote:
I think this email make exactly my point.
Please explain.
By way of anticipating your response, I should not have removed your key
conclusion:
Unless that is put to rest, we can not do much at all.
That is demonstrably not true, as well
On 2014-02-16 17:39, Patrik Fältström wrote:
On 2014-02-16 16:52, Paul Hoffman wrote:
On Feb 15, 2014, at 11:15 PM, Patrik Fältström p...@frobbit.se wrote:
On 2014-02-16 03:04, David Conrad wrote:
Perhaps DNSOP actually is the DNS innovation WG (if perhaps only as a
seeding ground)?
The
On 2014-02-16, at 11:39, Patrik Fältström p...@frobbit.se wrote:
- We can not use new RR Types, lets use A and TXT
- DNSSEC will never take off
- Lets just use HTTP for transport
I think we are suffering from a knee-jerk instinct to say no to ideas that we
assume will never work in the real
Joe Abley wrote:
...
If we believe all these problems are intractable, then we might as well just
accept that overloading TXT records and reflection attacks are a fact of
life, and stop worrying about them.
reflection attacks aren't a fact of life. DNS RRL does not require a
forklift
Dear Marc,
Yes, that's what I thought too, so that's why I proposed to use
1.2.840.113549.1.1.5 (note the last 5 instead of 1) for RSA+SHA1.
IMHO, we do not really need two bytes and no padding is also needed.
Because I think if the encryption is on hash function, then it always
In message alpine.deb.2.03.1402141618310.14...@iskra.ottix.net, William F.
Maton Sotomayor writes:
On Fri, 14 Feb 2014, Tony Finch wrote:
Joe Abley jab...@hopcount.ca wrote:
Reactions and reviews of the two documents would be most welcome!
The as112-dname draft still does not
On Sun, 16 Feb 2014, Dave Crocker wrote:
On 2/16/2014 6:03 AM, Patrik Fältström wrote:
I think this email make exactly my point.
Please explain.
By way of anticipating your response, I should not have removed your key
conclusion:
Unless that is put to rest, we can not do much at all.
On 2/15/14, 9:04 PM, David Conrad wrote:
[perpass dropped from ccs]
On Feb 15, 2014, at 11:57 AM, Paul Wouters p...@nohats.ca wrote:
At ietf87 it was planned to have a discussion at dnsop about this
continued problem of drafts that fall between operations and extensions
and the fact that
Dear all,
This proposal has multiple shortcomings compared to DNSCurve.
First off, it says that the rationale for TLS over DNSCurve is simply
to take advantage of TLS. I would respectfully submit that DJB can
do a better job than the TLS committee, and did. Merely adding bolts
and nuts onto a
On Sat, Feb 15, 2014 at 8:44 AM, Watson Ladd watsonbl...@gmail.com wrote:
Dear all,
This proposal has multiple shortcomings compared to DNSCurve.
And some advantages over DNSCurve.
First off, it says that the rationale for TLS over DNSCurve is simply
to take advantage of TLS. I would
Cherry-picking the worst of the assertions...
On Sat, Feb 15, 2014 at 10:08 AM, Paul Vixie p...@redbarn.org wrote:
has mr. bernstein's Curve25519 (see
http://en.wikipedia.org/wiki/Curve25519) been explicitly validated by
other crypto experts?
Yes.
last i knew he was the only one
Dear Hosnieh,
You're right I guess I was confused two different things -- data encryption
and signature generation. I re-checked the signature generation algorithm.
Since first the data is hashed using SHA function and then the digest is
encrypted using a private key, this will lead to
Dear Hosnieh,
First of all, I'm glad I could be of help and to see that a number of my
suggestions have been adopted!
Regarding the size of the length fields, however, I'm still confused by
what you are trying to say. I did not consider the number of bits, I
really considered the number of bytes
Dear Hosnieh,
Let me first react to your first email of today. CGA uses the
RSASSA-PKCS1-v1_5 signature algorithm to sign the message. The way I
understand it as explained at
http://tools.ietf.org/html/rfc3447#section-8.2.1 is that the length of
the output signature S only depends on the length k
The largest problem for IETF and DNS innovation is that the consensus in
IETF seems to be that innovation of DNS is not possible unless it
involves reuse of the TXT resource record.
Yes, sort of. The consensus in one part of the IETF is that adding
new RR types is too hard due to DNS server
On 17/02/2014, at 5:48 am, Joe Abley jab...@hopcount.ca wrote:
On 2014-02-16, at 11:39, Patrik Fältström p...@frobbit.se wrote:
- We can not use new RR Types, lets use A and TXT
- DNSSEC will never take off
- Lets just use HTTP for transport
I think we are suffering from a knee-jerk
21 matches
Mail list logo
