Andy Parkins [ARCHIVE] on Nostr: 📅 Original date posted:2011-12-16 🗒️ Summary of this message: The use of ...
📅 Original date posted:2011-12-16
🗒️ Summary of this message: The use of HTTPS is centralized, but necessary for secure communication. Trust is needed somewhere, and until PGP support is available, CAs are necessary.
📝 Original message:On 2011 December 16 Friday, Rick Wesson wrote:
> I believe that any URI scheme will still leverage DNS and inherit any
> base issues you would have with TXT records. I suggest looking at DANE
HTTPS takes care of that.
> and reviewing their work on hardening certificate (x.509)
> infrastructure as your HTTPS scheme will inherit the issues we
> currently experience with CAs getting p0wned.
This is the only real problem with HTTPS: we would be centralising part of our
otherwise decentralised system. CAs are certainly a risk.
However, trust is needed somewhere in the communication. There is no way to
securely communicate between A and B without the use of some previously
trusted secure channel -- in Joe Sixpack's case it's by assuming that the
browser he downloaded came with an untainted CA list, and that the CAs are
trustworthy. Neither of which is guaranteed. Until and unless we get PGP
support in browsers, CAs are all that we have.
Worrying about CAs misses the point anyway; if we're being that paranoid --
how did A tell B the appropriate alias to use for a lookup? Was that channel
secure too? I could set up a MITM server that simply looks for the alias
"RICKWESSON at bitcoinaliases.org" and rewrites it to
"ANDYPARKINS at bitcoinaliases.org". When the answer to that problem is HTTPS
(or some other system that requires a previously authorised secure channel for
transfer of trust), then we're back where we started, and HTTPS is acceptable.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/c16ac4b7/attachment.sig>;
🗒️ Summary of this message: The use of HTTPS is centralized, but necessary for secure communication. Trust is needed somewhere, and until PGP support is available, CAs are necessary.
📝 Original message:On 2011 December 16 Friday, Rick Wesson wrote:
> I believe that any URI scheme will still leverage DNS and inherit any
> base issues you would have with TXT records. I suggest looking at DANE
HTTPS takes care of that.
> and reviewing their work on hardening certificate (x.509)
> infrastructure as your HTTPS scheme will inherit the issues we
> currently experience with CAs getting p0wned.
This is the only real problem with HTTPS: we would be centralising part of our
otherwise decentralised system. CAs are certainly a risk.
However, trust is needed somewhere in the communication. There is no way to
securely communicate between A and B without the use of some previously
trusted secure channel -- in Joe Sixpack's case it's by assuming that the
browser he downloaded came with an untainted CA list, and that the CAs are
trustworthy. Neither of which is guaranteed. Until and unless we get PGP
support in browsers, CAs are all that we have.
Worrying about CAs misses the point anyway; if we're being that paranoid --
how did A tell B the appropriate alias to use for a lookup? Was that channel
secure too? I could set up a MITM server that simply looks for the alias
"RICKWESSON at bitcoinaliases.org" and rewrites it to
"ANDYPARKINS at bitcoinaliases.org". When the answer to that problem is HTTPS
(or some other system that requires a previously authorised secure channel for
transfer of trust), then we're back where we started, and HTTPS is acceptable.
Andy
--
Dr Andy Parkins
andyparkins at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20111216/c16ac4b7/attachment.sig>;