đź“… Original date posted:2011-12-19
🗒️ Summary of this message: DANE uses secure DNS to associate TLS server's certificate with the intended domain name, mitigating the need for CAs and allowing self-signed certificates.
đź“ť Original message:You are describing the problem DANE addresses, see
http://tools.ietf.org/html/draft-ietf-dane-protocol-12
Using Secure DNS to Associate Certificates with Domain Names For TLS
Abstract
TLS and DTLS use PKIX certificates for authenticating the server.
Users want their applications to verify that the certificate provided
by the TLS server is in fact associated with the domain name they
expect. TLSA provides bindings of keys to domains that are asserted
not by external entities, but by the entities that operate the DNS.
This document describes how to use secure DNS to associate the TLS
server's certificate with the intended domain name.
For those of you against DNSSEC, DANE leverages it significantly.
The point I have been attempting to make is if one to rely on HTTPS,
leveraging DANE will allow you to mitigate CAs and use self signed
cers but you will need to leverage DNSSEC to bind the self signed cert
using DANE and if you are going to rely on DNSSEC for DANE to support
HTTPS, why not short-circut this madness and just publish your
identifiers and secure the zone via DNSSEC and link in a stub resolver
in the client.
Short story: transform user at authority.tld --> _btc.user.athority.tld TXT 1z....
A short i-d is probably a better way to explain, so I will task myself
to do that.
-rick
On Mon, Dec 19, 2011 at 6:46 AM, solar <solar at heliacal.net> wrote:
> I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a good idea and (historical implementation bugs aside) the concept is technically sound and secure. Â What is a bad idea (in my opinion) is to trust a software vendor to decide who you should trust.. thus it is a bad idea for bitcoin software to promise any trust.
>
> The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests. Â Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money. Â All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified. Â I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.
>
> First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.
>
> When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'. Â Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not. Â You would have to retrieve the correct public key of the CA to compare to first, possibly out of band. Â Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps). Â The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.
>
> I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems. Â Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already. Â In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.
>
> Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that. Â In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system. Â The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.
>
> Thanks,
> Laszlo
>
>
>
> On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:
>
>> On 2011 December 19 Monday, Jorge TimĂłn wrote:
>>> Ok, so HTTP is not an option unless it shows a huge warning. I don't
>>> know the HTTPS possible attack, but maybe it needs a warning message
>>> too, from what you people are saying. Although using namecoin to
>>
>> The problems with HTTPS have been social rather than technical. Â Multiple CAs
>> have been strong-armed by governments or tricked into issuing fake
>> certificates by scammers. Â There is no technical measure around that. Â By
>> using the CA certificate we are saying to the system "here is someone I trust
>> to issue a certificate". Â So far, with a large number of CAs, that trust is
>> misplaced.
>>
>> I'm of the opinion though that this problem is outside the remit of bitcoin to
>> solve.
>>
>> Perhaps we should be more strict about which CA certificates are trusted by
>> the bitcoin client: say restrict it to those who have demonstrably good
>> practices for verifying identity; rather than the ridiculous amount of trust
>> that comes pre-installed for me in my browser.
>>
>>
>>
>> Andy
>>
>> --
>> Dr Andy Parkins
>> andyparkins at gmail.com
>> ------------------------------------------------------------------------------
>> Learn Windows Azure Live! Â Tuesday, Dec 13, 2011
>> Microsoft is holding a special Learn Windows Azure training event for
>> developers. It will provide a great way to learn Windows Azure and what it
>> provides. You can attend the event by watching it streamed LIVE online.
>> Learn more at http://p.sf.net/sfu/ms-windowsazure_______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Learn Windows Azure Live! Â Tuesday, Dec 13, 2011
> Microsoft is holding a special Learn Windows Azure training event for
> developers. It will provide a great way to learn Windows Azure and what it
> provides. You can attend the event by watching it streamed LIVE online.
> Learn more at http://p.sf.net/sfu/ms-windowsazure
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Rick Wesson [ARCHIVE] /
npub1xz…2925u
2023-06-07 02:44:26
in reply to nevent1q…zrl2
Author Public Key
npub1xz8q68hmzur6c6uje593nscy3q4njx05h4vnxmz2wxxptx7u7casl2925uPublished at
2023-06-07 02:44:26Event JSON
{
"id": "53a350370126a117dcc97c04c1dfe17f97f5d66aa040eeea7dc1b63860deb09e",
"pubkey": "308e0d1efb1707ac6b92cd0b19c304882b3919f4bd59336c4a718c159bdcf63b",
"created_at": 1686105866,
"kind": 1,
"tags": [
[
"e",
"247922e9146ee6b54a634fc05ad7a489892c01debcd0510d008be95a47f6db80",
"",
"root"
],
[
"e",
"a88ef38d9a1b642e93c9871da143b7d774feff6d93df597d7ca032a61c36e882",
"",
"reply"
],
[
"p",
"6275ce44dd9b0e0a2d7e662dfc9611cc44a10ad8cd03408f46afa778a8cec48e"
]
],
"content": "📅 Original date posted:2011-12-19\n🗒️ Summary of this message: DANE uses secure DNS to associate TLS server's certificate with the intended domain name, mitigating the need for CAs and allowing self-signed certificates.\n📝 Original message:You are describing the problem DANE addresses, see\nhttp://tools.ietf.org/html/draft-ietf-dane-protocol-12\n\n\nUsing Secure DNS to Associate Certificates with Domain Names For TLS\n\nAbstract\n\n TLS and DTLS use PKIX certificates for authenticating the server.\n Users want their applications to verify that the certificate provided\n by the TLS server is in fact associated with the domain name they\n expect. TLSA provides bindings of keys to domains that are asserted\n not by external entities, but by the entities that operate the DNS.\n This document describes how to use secure DNS to associate the TLS\n server's certificate with the intended domain name.\n\n\nFor those of you against DNSSEC, DANE leverages it significantly.\n\nThe point I have been attempting to make is if one to rely on HTTPS,\nleveraging DANE will allow you to mitigate CAs and use self signed\ncers but you will need to leverage DNSSEC to bind the self signed cert\nusing DANE and if you are going to rely on DNSSEC for DANE to support\nHTTPS, why not short-circut this madness and just publish your\nidentifiers and secure the zone via DNSSEC and link in a stub resolver\nin the client.\n\nShort story: transform user at authority.tld --\u003e _btc.user.athority.tld TXT 1z....\n\nA short i-d is probably a better way to explain, so I will task myself\nto do that.\n\n-rick\n\n\nOn Mon, Dec 19, 2011 at 6:46 AM, solar \u003csolar at heliacal.net\u003e wrote:\n\u003e I think HTTPS, and more specifically x.509 PKI certs and CAs are generally a good idea and (historical implementation bugs aside) the concept is technically sound and secure.  What is a bad idea (in my opinion) is to trust a software vendor to decide who you should trust.. thus it is a bad idea for bitcoin software to promise any trust.\n\u003e\n\u003e The part where the concept becomes flawed is trusting 3rd parties who have no relationship with you, to serve your interests.  Now I'm just generalizing here and this is not universally true.. but internet CAs just want to sell certificates - they generally don't care beyond that, and they abuse the certificate validity dates to charge more money.  All this is done under the guise of wanting to provide a secure experience to users without a prior relationship to the entity being identified.  I propose that trying to follow this paradigm in bitcoin alias resolution is a bad idea because it tries to solve 2 problems at once, one of which does not have any 'good' solution, and forces a specific policy.\n\u003e\n\u003e First, we need to resolve an alias to a bitcoin address somehow.. but secondly we need to establish trust with the entity doing the alias resolution - to make sure that we can trust the response.\n\u003e\n\u003e When resolving an alias you will have to query an untrusted server, possibly being proxied by an 'attacker'.  Presumably, an x.509 certificate will be presented, possibly self signed or chained off a self generated CA or whatever else.. but if it's your first contact then there is no possible way to know if it's correct or not.  You would have to retrieve the correct public key of the CA to compare to first, possibly out of band.  Get it from my website, compare it to my business card, send me an email and I'll send it to you, or get it from some other source using some other pre existing trust (a centralized and possibly private directory perhaps).  The point is, the reason there is so much disagreement is because there is no good way to trust the resolver if you don't create that trust relationship prior to resolving an alias from it.\n\u003e\n\u003e I think that having to pre-trust the resolver would be an acceptable solution to all.. Those whose policy requires a simpler process can get a 3rd party CA list, much like the ones provided with web browsers and operating systems.  Those with strict verification policies can choose to pre verify every public key.. and these processes are familiar to many organizations using PKI for other things already.  In a client, presenting the usual certificate detail dialog, showing the public key, subject, issuer, and thumbprint would be sufficient to allow users to implement their own policies without forcing it one way or another.\n\u003e\n\u003e Please consider that while some organizations or users might require strong anonymity and pre existing trust, there are others who may want to do the opposite and that is just as valid, even if you or 'everyone else' disagrees with that.  In the case of bitcoin, it will be used as part of a larger system, and whatever concerns are created by 'insecure' alias resolution may well be addressed in another part of the system.  The most successful standards and implementations are the ones which provide the most flexibility - primarily because that allows users to extend them in ways the original designers didn't necessarily plan for.\n\u003e\n\u003e Thanks,\n\u003e Laszlo\n\u003e\n\u003e\n\u003e\n\u003e On Dec 19, 2011, at 11:44 AM, Andy Parkins wrote:\n\u003e\n\u003e\u003e On 2011 December 19 Monday, Jorge Timón wrote:\n\u003e\u003e\u003e Ok, so HTTP is not an option unless it shows a huge warning. I don't\n\u003e\u003e\u003e know the HTTPS possible attack, but maybe it needs a warning message\n\u003e\u003e\u003e too, from what you people are saying. Although using namecoin to\n\u003e\u003e\n\u003e\u003e The problems with HTTPS have been social rather than technical.  Multiple CAs\n\u003e\u003e have been strong-armed by governments or tricked into issuing fake\n\u003e\u003e certificates by scammers.  There is no technical measure around that.  By\n\u003e\u003e using the CA certificate we are saying to the system \"here is someone I trust\n\u003e\u003e to issue a certificate\".  So far, with a large number of CAs, that trust is\n\u003e\u003e misplaced.\n\u003e\u003e\n\u003e\u003e I'm of the opinion though that this problem is outside the remit of bitcoin to\n\u003e\u003e solve.\n\u003e\u003e\n\u003e\u003e Perhaps we should be more strict about which CA certificates are trusted by\n\u003e\u003e the bitcoin client: say restrict it to those who have demonstrably good\n\u003e\u003e practices for verifying identity; rather than the ridiculous amount of trust\n\u003e\u003e that comes pre-installed for me in my browser.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Andy\n\u003e\u003e\n\u003e\u003e --\n\u003e\u003e Dr Andy Parkins\n\u003e\u003e andyparkins at gmail.com\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e Learn Windows Azure Live!  Tuesday, Dec 13, 2011\n\u003e\u003e Microsoft is holding a special Learn Windows Azure training event for\n\u003e\u003e developers. It will provide a great way to learn Windows Azure and what it\n\u003e\u003e provides. You can attend the event by watching it streamed LIVE online.\n\u003e\u003e Learn more at http://p.sf.net/sfu/ms-windowsazure_______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Learn Windows Azure Live!  Tuesday, Dec 13, 2011\n\u003e Microsoft is holding a special Learn Windows Azure training event for\n\u003e developers. It will provide a great way to learn Windows Azure and what it\n\u003e provides. You can attend the event by watching it streamed LIVE online.\n\u003e Learn more at http://p.sf.net/sfu/ms-windowsazure\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development",
"sig": "1f9b990f9ddf3d29584e26dd18d93c416f8fe577a0b1801c52e082b3f15e888623686db5aa0b9fe5c33b6446c648456bcdea80a3a66396dd94fad498bf9a73f6"
}