>Discussion, please. See below for my take; the IETF is one host, MX is really
>meaningless, and there are
>benefits to avoiding a ton of spambot zombie spam.
That's not a very good idea. I wouldn't count on zombies ignoring the
IETF, nor would I count on there not being real MTAs that will hic
Total of 115 messages in the last 7 days.
script run at: Fri Feb 26 00:53:02 EST 2010
Messages | Bytes| Who
+--++--+
8.70% | 10 | 11.39% |76571 | hal...@gmail.com
6.96% |8 | 5.69% |38218 | d...@dotat.at
Discussion, please. See below for my take; the IETF is one host, MX is really
meaningless, and there are benefits to avoiding a ton of spambot zombie spam.
Begin forwarded message:
> From: "Glen via RT"
> Date: 25 February 2010 18:16:44 GMT
> To: m...@sabahattin-gucukoglu.com
> Subject: [rt.iet
> From: Shumon Huque
> Any of them, whether by malice or by being tricked, can issue a
> certificate for any of your services. Our security is basically as good
> as the the CA with the laxest policies & worst security.
Sounds like a poor attribute for a security architeture...
a...@tr-sys.de wrote:
> Hello,
> draft-ietf-tcpm-tcp-ao-crypto-02 intends to make
> mandatory-to-implement for TCP-AO two MAC algorithms,
> HMAC-SHA-1-96 and AES-128-CMAC-96, as well as two related KDFs.
>
> IIRC, other WG(s) have been advised last year by important stakeholders
> (in particular
On Thu, Feb 25, 2010 at 11:55:03AM -0500, Paul Wouters wrote:
> On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
> >If DNSSEC succeeds, the domain validated certificate business will
> >have to either transform or eventually die. I think that for most CAs,
> >the business opportunities from SSL+DNS
> -Original Message-
> From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On
> Behalf Of Joe Abley
> Sent: Thursday, February 25, 2010 1:06 PM
> To: Tony Finch
> Cc: Phillip Hallam-Baker; IETF Discussion
> Subject: Re: DNSCurve vs. DNSSEC - FIGHT! (was OpenDNS today
> announced it
On 2010-02-24, at 15:50, Tony Finch wrote:
> On Wed, 24 Feb 2010, Shane Kerr wrote:
>>
>> DNSSEC declares out of scope:
>> * the channel where DS records get added to the parent
>
> Is that actually out of scope or just not specified yet?
The whole channel from end-user (registrant) to re
On Feb 25, 2010, at 8:41 AM, Paul Wouters wrote:
> On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:
>> I would like to see us create an assumption that a given machine will
>> only use recursive resolution services from a specific trusted source.
>
> Trust no one.
You have to trust someone. Real
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
But SSH would be much better if we could integrate the key
distribution into a secured DNS.
See previous post. Already done and running.
And self-signed SSL certs would be
better if we could use hash values distributed through a secured DNS
to
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
What does DNSCurve additionally provide
compared to a combination of traditional DNS with IPsec?
They appear to have an interest in actually listening to real world
requirements.
Of course a combination of DNS and IPSec would be a better solu
On Thu, 25 Feb 2010, Phillip Hallam-Baker wrote:
>
> But SSH would be much better if we could integrate the key
> distribution into a secured DNS.
RFC 4255 "Using DNS to Securely Publish Secure Shell (SSH) Key
Fingerprints"
Tony.
--
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUT
On Wed, 24 Feb 2010, Phillip Hallam-Baker wrote:
I would like to see us create an assumption that a given machine will
only use recursive resolution services from a specific trusted source.
Trust no one. More and more devices will do their own DNSSE validation,
and just use caches to get the d
[For some reason, I seem to receive Phillip's messages later than other people
who are responding to his messages. Odd.]
Hi,
> Signing the .com zone is irrelevant until we have a process for
> putting the key in.
Not really. If VeriSign were to sign .COM tomorrow and publish their key
somewh
On Thu, 25 Feb 2010, Nikos Mavrogiannopoulos wrote:
Ssh without secure public key distribution mechanism is not really
secure cryptographically.
In general, public key cryptography is scure only if public key
distribution is secure.
Well as far as I know ssh works pretty well today and this m
I find blanket statements of the form 'Verifiability does not scale'
to be inconsistent with the facts.
We do in fact have a very successful PKI industry with multiple
companies competing in a multi-billion dollar market. The only reason
this is not heralded as the triumph of PKI is that some peop
On Thu, Feb 25, 2010 at 8:30 AM, Martin Rex wrote:
> Phillip Hallam-Baker wrote:
>>
>> I took a look at DNSCurve. Some points:
>>
>> * It could certainly win.
>> * It is designed as a hack rather than an extension.
>> * It considers real world requirements that DNSSEC does not.
>
> What does DNSCu
You do not make problems disappear by declaring them out of scope.
Security systems are social systems. If you have not considered the
business and social issues you haven't got a system.
Security is about people, not protocols.
On Wed, Feb 24, 2010 at 2:30 PM, Shane Kerr wrote:
> Phillip,
>
>
It looks like draft-ietf-tcpm-tcp-ao-crypto-02 is not yet ready for
publication.
Here is a collection of some editorials (found on a quick pass
over the draft) that should be fixed:
(1) Section 1, last para
The text there does not reflect the order of presentation in the
remainder of the docum
I was attempting to refer to the fact you considered the break
noteworthy rather than that you were the source, my apologies if that
was not clear.
I think we do need to change the DNS model. But not necessarily as
drastically as DNScurve and not to get rid of caching.
I would like to see us cre
The same could be said of PGP when it was first launched.
There was only one version of PGP against multiple PEM
implementations. Phil Z. made clear he didn't give a wetslap about the
patents.And I have been asking ICANN for months how I get a key for my
DNS zones into the system and have never go
Hello,
draft-ietf-tcpm-tcp-ao-crypto-02 intends to make
mandatory-to-implement for TCP-AO two MAC algorithms,
HMAC-SHA-1-96 and AES-128-CMAC-96, as well as two related KDFs.
IIRC, other WG(s) have been advised last year by important stakeholders
(in particular NIST) to not standardize new use case
On Thu, 25 Feb 2010, Tony Finch wrote:
On Thu, 25 Feb 2010, Martin Rex wrote:
What does DNSCurve additionally provide
compared to a combination of traditional DNS with IPsec?
DNS-based keying.
RFC 4025 - A Method for Storing IPsec Keying Material in DNS
Paul
__
On Feb 25, 2010, at 6:16 AM, Florian Weimer wrote:
>> It's very slow if you don't have a cache.
> Note that most stubs actually have a cache these days,
They do? Maybe that explains the 98% of the crap hitting the roots these
days...
Regards,
-drc
__
On 25 Feb 2010, at 14:14, Tony Finch wrote:
On Thu, 25 Feb 2010, Sabahattin Gucukoglu wrote:
>> I'm thinking that maybe there's something in having DNSCurve be used for
>> one leg of the journey, between customer and cache.
>
> That won't work because DNScurve gets its key from the server name, bu
The IETF community may be interested in this announcement from the Acting
RFC Series Editor.
Russ
Original Message
Subject: [rfc-i] New email address for Independent Submission stream
Date: Tue, 23 Feb 2010 10:56:31 -0800
From: Bob Braden
To: RFC Interest
CC: rfc-...@rfc-edito
Tony Finch wrote:
>
> On Thu, 25 Feb 2010, Martin Rex wrote:
> >
> > What does DNSCurve additionally provide
> > compared to a combination of traditional DNS with IPsec?
>
> DNS-based keying.
That appears to be an illusion.
My impression is that DNScurve can only distribute public keys
of autho
* Masataka Ohta:
> Mark Andrews wrote:
>
http://tools.ietf.org/html/draft-dempsky-dnscurve-00
>>>
>>>As I read the draft, it seems to me that DNSCurve without Curve
>>>(that is, with 96 bit nonce of DNSCurve as an extended message
>>>ID without elliptic curve cryptography) is secure enough.
>
* Tony Finch:
>> And why aren't stub resolvers being encouraged to do their own DNSSec
>> validation?
>
> It's very slow if you don't have a cache.
Note that most stubs actually have a cache these days, so I don't
think this is a major architectural issue.
--
Florian Weimer
BFK
On Thu, 25 Feb 2010, Martin Rex wrote:
>
> What does DNSCurve additionally provide
> compared to a combination of traditional DNS with IPsec?
DNS-based keying.
Tony.
--
f.anthony.n.finchhttp://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GO
On Thu, 25 Feb 2010, Sabahattin Gucukoglu wrote:
> I'm thinking that maybe there's something in having DNSCurve be used for
> one leg of the journey, between customer and cache.
That won't work because DNScurve gets its key from the server name, but
recursive servers are configured by IP address
I'm thinking that maybe there's something in having DNSCurve be used for one
leg of the journey, between customer and cache. Then the cache can use DNSSec
to get the desired validity of data, withstanding all attempts to subvert it,
and not needing to depend on any tricky key retrieval process
Phillip Hallam-Baker wrote:
>
> I took a look at DNSCurve. Some points:
>
> * It could certainly win.
> * It is designed as a hack rather than an extension.
> * It considers real world requirements that DNSSEC does not.
What does DNSCurve additionally provide
compared to a combination of traditi
Nikos Mavrogiannopoulos wrote:
>>In general, public key cryptography is scure only if public key
>>distribution is secure.
> Well as far as I know ssh works pretty well today
With plain old DNS, yes, ssh works pretty well today.
However, it should be noted that first ssh connection may be
misdi
Paul Wouters пишет:
DNSSEC declares out of scope:
* the channel where DS records get added to the parent
Is that actually out of scope or just not specified yet?
Out of scope. It is the bootstrap problem. Though with RFC-5011
It is much more than bootstrap problem.
and perhaps draf
35 matches
Mail list logo
