On Sun, Feb 13, 2011 at 5:20 AM, Eddy Nigg wrote:
I can see how DANE could be useful with CA issued certificates. The above is
a non-starter (at least for me) and rather dangerous for any third party
relying on it. But those are my opinions at least if and until this gets
implemented anywhere
On 02/12/2011 05:57 PM, From Stephen Schultze:
Not at all. I was inviting others to voice their support of your
position as well, but so far it's just you.
Don't take this as an indicator of such - I'm usually more vocal (than
others) and others might be not willing to enter into discussion
Zack,
I think having some kind of statement from the Moz community could be
helpful, and a good excuse for Moz folks to get up to speed on the spec.
With respect to the Section 3 text, it may be best simply to voice your
thoughts directly on the DANE list. I don't think the current text is
On 2/12/11 7:03 AM, Eddy Nigg wrote:
If anybody else on this list would like to present a more compelling
argument than you have
as if your arguments are more convincing and the only ones that
count :-)
Not at all. I was inviting others to voice their support of your
position as well, b
On 02/12/2011 05:44 AM, From Steve Schultze:
Not that many phishing attacks rely on HTTPS. That report also
details phishing attacks *on people seeking to purchase SSL
certificates* in which the phishing happens over plaintext. If
there's any community that would require an HTTPS connection i
On 2/11/11 6:04 PM, Eddy Nigg wrote:
Indeed, PAYPA1.COM, MICR0S0FT.COM, PAYPAL.DOM.COM,
BANK0FAMERICA.COMall goes.
Of course not, that's why we have this:
http://www.antiphishing.org/reports/APWG_GlobalPhishingSurvey_2H2009.pdf
Have you actually read that report? It details a rapid resp
Last reply, I promise...
On 02/12/2011 12:50 AM, From Stephen Schultze:
Today's DV CAs already rely on a self-assertion of domain control, and
they in turn assert that they observed this. In plain english, a DV
cert says, "The guy holding the corresponding private key asserted
that he control
On 02/12/2011 12:32 AM, From Stephen Schultze:
Who the subscriber is (not higher level validation, sanity check)
I still can't decipher this.
I didn't expected that you do :-)
what the requested host name is
There is no ambiguity in DANE.
Indeed, PAYPA1.COM, MICR0S0FT.COM, PAYPAL.DOM.C
On 2/11/11 3:11 PM, Eddy Nigg wrote:
improves reduces the spectrum of exploits... does this make any sense?
Thanks typo cop. I'm sure it's clear what I meant.
. It also places revocation power directly in the hands of the
subscriber.
That's the same as self-assertion. Most subscribers
On 2/11/11 5:57 AM, Eddy Nigg wrote:
On 02/11/2011 07:08 AM, From Steve Schultze:
Can you give an example?
Who the subscriber is (not higher level validation, sanity check)
I still can't decipher this.
what the requested host name is
There is no ambiguity in DANE.
what's the purpose of
On 02/11/2011 05:56 PM, From Stephen Schultze:
Thus, the CA DV model provides no clear comparative benefit with
respect to revocation abilities. In fact, by removing the need to
proactively revoke, DANE improves reduces the spectrum of exploits
improves reduces the spectrum of exploits...
On 2/11/11 4:39 AM, Rob Stradling wrote:
On Friday 11 Feb 2011 05:08:10 Steve Schultze wrote:
- OCSP and CRLs are unnecessary with DANE
Steve, may we presume that you only intended this statement to apply to the
use of self-signed certs with DANE?
When an EV (or OV) certificate issued by a t
On 02/11/2011 07:08 AM, From Steve Schultze:
Can you give an example?
Who the subscriber is (not higher level validation, sanity check), what
the requested host name is, what's the purpose of a certificate,
cryptographic weaknesses, to name a few.
Would these checks be necessary under DAN
On Friday 11 Feb 2011 05:08:10 Steve Schultze wrote:
> - OCSP and CRLs are unnecessary with DANE
Steve, may we presume that you only intended this statement to apply to the
use of self-signed certs with DANE?
When an EV (or OV) certificate issued by a third-party CA is used with DANE, I
would
On 2/10/11 8:09 PM, Eddy Nigg wrote:
There are additional steps CAs can/should/do besides checking domain
control - even in the DV settings.
Ok, so the theory here is that some DV CAs do some stuff above and
beyond baseline domain validation. We don't really know who is doing
how much of thi
On 02/11/2011 01:33 AM, From Stephen Schultze:
You cut off the end of the sentence, which made clear that I was
referring to how the *trust* of the CA model relies on blind trust of
the data in DNS. Any fundamental trust model shortcoming of DNS is
likewise a shortcoming of CA DV. You've neve
On 2/10/11 5:36 PM, Eddy Nigg wrote:
On 02/10/2011 10:40 PM, From Stephen Schultze:
Until you actually explain why you think it's not correct that DV
relies on DNS,
I didn't say DV doesn't rely on DNS, almost everything on the [net] uses it.
Of course, but the fact that apps use DNS irreleva
On 02/11/2011 12:36 AM, From Eddy Nigg:
I didn't say DV doesn't rely on DNS, almost everything on the *NET*
uses DNS.
Corrected.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
--
dev-tec
On 02/10/2011 10:40 PM, From Stephen Schultze:
Until you actually explain why you think it's not correct that DV
relies on DNS,
I didn't say DV doesn't rely on DNS, almost everything on the DNS uses it.
or what beyond domain validation that you think DV actually does,
there's really nothing t
On 2/10/11 3:33 PM, Eddy Nigg wrote:
On 02/10/2011 08:51 PM, From Stephen Schultze:
As I have said repeatedly (and you have never addressed) the CA DV
model relies on DNS and thus imports any vulnerabilities that exist in
a DNS-based model. CA DV blindly trusts DNS.
That's exactly your mistak
On 02/10/2011 08:51 PM, From Stephen Schultze:
As I have said repeatedly (and you have never addressed) the CA DV
model relies on DNS and thus imports any vulnerabilities that exist in
a DNS-based model. CA DV blindly trusts DNS.
That's exactly your mistake, you are not correct.
The only t
On 2/10/11 1:25 PM, Eddy Nigg wrote:
On 02/10/2011 07:20 PM, From Steve Schultze:
Zack, arguing with Eddy on this point is a losing proposition.
DNSSEC+TLSA is has some demonstrably superior characteristics to CA
DV, but Eddy is not willing to concede this or even give detailed
reasoning.
Well
On 02/10/2011 07:20 PM, From Steve Schultze:
Zack, arguing with Eddy on this point is a losing proposition.
DNSSEC+TLSA is has some demonstrably superior characteristics to CA
DV, but Eddy is not willing to concede this or even give detailed
reasoning.
Well, we know about the advantages and s
On 2/7/11 6:31 PM, Robert Relyea wrote:
My primary worry of the this spec as is is that DNSSEC is trying to be
the end-all-be-all authority. That's a recipe for disaster. Keeping all
my server keys in sync with the DNSSEC record? And if I have OV/EV, I
have to keep it in sync with the certificate
On 2/6/11 1:01 PM, Eddy Nigg wrote:
On 02/06/2011 07:11 PM, From Zack Weinberg:
I'm going to ask you the same question I asked Nelson: In a
hypothetical world where DNSSEC+TLSA completely supersedes DV (but
people still use OV/EV for high-value sites) what do you see as having
been lost? Or, tur
On 02/08/2011 07:56 AM, Gervase Markham wrote:
> On 05/02/11 21:13, Nelson B Bolyard wrote:
>> 2) After 14 years of working on SSL/TLS for browsers, I can tell you
>> that
>> browsers will all ignore the paragraph that says "Clients SHOULD NOT
>> allow
>> users to force a connection ...". I suppos
On 05/02/11 21:13, Nelson B Bolyard wrote:
2) After 14 years of working on SSL/TLS for browsers, I can tell you that
browsers will all ignore the paragraph that says "Clients SHOULD NOT allow
users to force a connection ...". I suppose that surprises no-one.
It's all about precedent. If all br
On 02/06/2011 09:11 AM, Zack Weinberg wrote:
> On 02/05/2011 02:55 PM, Eddy Nigg wrote:
>>
>> However probably the optimal approach will be CA issued certs in DNS
>> that also make use of DNSSEC to validate the former (DV). Eventually I
>> believe that this will emerge as the real improvement and m
On 02/06/2011 07:11 PM, From Zack Weinberg:
I'm going to ask you the same question I asked Nelson: In a
hypothetical world where DNSSEC+TLSA completely supersedes DV (but
people still use OV/EV for high-value sites) what do you see as having
been lost? Or, turning it around, what value do you
On 02/05/2011 02:55 PM, Eddy Nigg wrote:
However probably the optimal approach will be CA issued certs in DNS
that also make use of DNSSEC to validate the former (DV). Eventually I
believe that this will emerge as the real improvement and most useful
approach for software vendors and CAs alike -
On 02/05/2011 03:28 PM, Zack Weinberg wrote:
"bogus" in this case is a term-of-art defined by RFC 4033.
You have made my day. :-)
I am so tweeting that.
- Marsh
https://twitter.com/marshray/status/34121219292790784
--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lis
On 2011-02-05 2:02 PM, Nelson B Bolyard wrote:
On 2011-02-05 13:28 PDT, Zack Weinberg wrote:
>> ...
There is a list/newsgroup focused specifically on the browser policy
governing the admittance of CAs to mozilla's root CA list. That probably
seems like the more obvious place, but it's where al
On 02/06/2011 12:02 AM, From Nelson B Bolyard:
I think CAs still get most of their revenues from DV
I'm not sure if that's correct (revenues != market share)...
and so perceive DANE as a direct threat.
and I believe that DV certs issued by CAs provides what the proposed
keys in DNS can
On 2011-02-05 13:28 PDT, Zack Weinberg wrote:
> On 2011-02-05 1:13 PM, Nelson B Bolyard wrote:
>> Zack, thanks for bringing this to this list/group. I think many of
>> us were caught by surprise by it, because it is a browser policy
>> proposal rather than a technical discussion of the protocols.
On 2011-02-05 1:13 PM, Nelson B Bolyard wrote:
Zack, thanks for bringing this to this list/group. I think many of us
were caught by surprise by it, because it is a browser policy proposal
rather than a technical discussion of the protocols.
Personally, I was a little surprised to be asked to d
On 2011-02-01 07:57 PDT, Zack Weinberg wrote:
> I've been following the mailing list for the IETF's "keyassure"
> working group, which plans to standardize a mechanism for putting
> application-layer server keys (or their hashes) in DNS, certified by
> DNSSEC. TLS/SSL is the first target, and of
[Some of you may have seen an earlier draft of this proposal before.
I originally sent it to secur...@mozilla.org and was asked to bring it
here.]
I've been following the mailing list for the IETF's "keyassure"
working group, which plans to standardize a mechanism for putting
application-layer
[Some of you may have seen an earlier draft of this proposal before.
I originally sent it to secur...@mozilla.org and was asked to bring it
here.]
I've been following the mailing list for the IETF's "keyassure"
working group, which plans to standardize a mechanism for putting
application-layer
38 matches
Mail list logo
