Re: [tor-dev] Comments on proposal 279 (Name API)

[Jeremy Rand]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Hi Nick!

Nick Mathewson:
> Section 2.1 and elsewhere:
> 
> I suggest that we require all address suffixes to end with .onion; 
> other TLDs are not reserved like .onion is, and maybe we shouldn't 
> squat any we haven't squatted already.

FWIW it's not at all clear to me that this is a concern that IETF or
ICANN will care about.  Most DNS recursive servers (e.g. Unbound)
allow squatting on arbitrary TLD's (this is often used for corporate
systems that use internal TLD's, but we use it for Namecoin as well),
and to my knowledge no one has complained to Unbound about the ability
to misuse this.

Generally I view a pluggable naming system as useful for use cases
besides simply human-readable .onion names.  It's also useful for any
of the various use cases for which people will fiddle with their local
DNS setup (including but not limited to: firewalling, ad-blocking,
debugging infrastructure, internal naming systems that have nothing to
do with .onion, alternate DNS roots like OpenNIC, decentralized naming
systems like Namecoin that aren't being used for .onion).  Yes, you
*could* do this with the control port (OnioNS does this, and Namecoin
has an internal beta of this as well that we've chosen not to release
because we want to engage on Prop279 to make sure that what we release
meets people's needs).  But the control port is extremely dangerous to
expose to untrusted software, so it makes sense to use a dedicated
naming API.  Forcing all these other use cases to use a clunkier, less
secure setup than the "human-readable .onion names" use case is likely
to stifle innovation, lead to duplicated code with different sets of
bugs, and/or discourage use of the naming API because software authors
don't want to rule out the possibility of exploring other use cases
later on.

I can totally see a policy making sense that *the naming systems
distributed by Tor officially* would only allow .onion as input
addresses, but since it sounds like the intent of this proposal is to
enable experiments that aren't officially endorsed by Tor, it's not
clear to me that such a policy would have much immediate effect.

There will probably be a news post posted to the Namecoin website in
the next week or so that's relevant to this point, but I won't include
it here since it's only reviewed by 3 of the Namecoin developers at
this time and I can't rule out needing to make edits to it.  I'll
provide it in this thread when it's posted.  (If for some reason this
issue urgently needs to be decided and waiting a week will derail that
schedule, let me know and I'll see what I can do.)

Also see my next point below:

> I think we might also want to have all output addresses end with
> .onion too.

This definitely makes sense from a UX point of view: everyone already
knows what .onion services are, and they have certain expectations for
what security properties they provide, so just because the 2nd-level
domain isn't a base32 public key shouldn't mean that all those
security properties don't apply.  Using the 2nd level domain to choose
what type of naming system is in use (e.g. .bit.onion) certainly makes
sense here.  But, there are real use cases where users will want the
output address to not be a .onion address: see my point above.

I think a perfectly reasonable policy would be: "If the input name is
.onion, then the output name must also be .onion; otherwise no
restrictions on the output name exist."  This preserves the UX
properties that people expect from .onion, doesn't restrict the other
use cases I mentioned above, and is minimal enough in terms of code
and spec complexity that I expect it would be easy to audit.

> I suggest  also that we might want to reserve part of the
> namespace for standardized namespaces and some for experimental or
> local ones. Like, if we standardize on namecoin that could be
> .bit.onion, but if we don't, it could be .bit.x.onion.

I don't have a particularly strong opinion on this, although I do
prefer the UX of .bit.onion over .bit.x.onion.  How many naming
systems are we expecting to actually be used here?  I wouldn't expect
any collisions to occur here due to the small number of naming systems
that are even expressing interest -- no collision with .bit exists
even in the wider DNS world 6 years after Namecoin was founded.  Is
there a threat model component here that I'm not seeing?

> I finally suggest that we distinguish names that are supposed to
> be global from ones that aren't.

This makes sense intuitively; is there a specific motivation for this
constraint?

> Section 2.3:
> 
> How about we require that the suffixes be distinct?  If we do that,
> we can drop this "priority" business and we can make the system's 
> behavior much easier to understand and explain.
> 
> Let's require that the TLDs actually begin with a dot.  (That is,
> I think that ".foo.onion" can include "bar.foo.onion", but I don't
> like the idea of "foo.onion" including 

[tor-dev] "Anomalous keys in Tor relays" technical report now available

[Laura M. Roberts]

Hello, Tor devs!


We have just published a (not yet peer-reviewed) technical report entitled 
"Anomalous keys in Tor relays." https://nymity.ch/anomalous-tor-keys/

The project was inspired by the "Mining Your P's and Q's" paper from Heninger 
et. al., and in it, we take a closer look at the RSA keys used in Tor since 
2005. We found that entities had purposely created anomalous keys in order to 
attack Tor's onion services and that researchers had inadvertently created weak 
keys while conducting experiments on Tor. (None of the weak keys we found are 
affecting the current Tor network.)

We welcome your questions and feedback!


Regards,
George, Claudia, Laura, & Philipp
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Alec Muffett]

On 5 April 2017 at 15:11, Ian Goldberg  wrote:

> I believe the danger Alec was wanting to avoid was that someone (not the
> onion service owner) could take an existing onion address, bump the
> version number (which wouldn't change the vanity beginning of the
> address), and upload the very same descriptor to the resulting blinded
> address (under the new version number).  Then the modified address would
> work just like the original.
>


In a nutshell, yes.

I've been having a discussion with Taylor Campbell off-list, and I wrote:

   - *… let me try something on you: *
   -
*The year is 2019.  *
   -
*What would _you_ do  *
   -
*in order to surface to the user  *
   -
*that the onion address in front of them,  *
   -
*one with a given public key which they've previously used and trusted
   before *
   -
*such that the leftmost 32 bytes, base32 encoded, are familiar to them,  *
   -
*is actually a downgraded version-2 format of address *
   -
*against which a bug is being exploited by (say) the FBI *
   -
*rather than the more secure version-3 form which they were expecting and
   had previously used, *
   -
*when all of the information pertinent to versions and checksums is at the
   right-hand-end of the encoded address? *
   - *This is basically where I am coming from.*
   -
*My thinking: Make it brittle. Mix the version (etc) into the represented
   form so that if one messes with a single bit, one perceptibly impacts the
   entire string representation of the onion address. How would you attack
   this? *


...and also:


> *do we want to be teaching users that:*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5c5bc5, and*
> *--- eh2tndsmiher4dqv266z5ii2xkt6brx2llwliq3jim233e5d5bc5**...are
> actually the same thing, but if and only if they differ in the N-5'th
> character?*



...and:


> *… up front I'll just say that my perspective of this class of threat
> comes from observations like *
> *a) people are creative, and if you give them malleability they will use
> it to create onion addresses including embedded "poop-emoji" and the like.*
> *b) people generalise, so that having learned that $SOME_CHARACTER in an
> onion address is malleable, they will assume that most/all of them are and
> subsequently fall for phishing attacks.**c) people are, as a group, given
> the entire Tor prop224 ecosystem, infinitely more creative than I can be at
> finding ways to exploit it, therefore it makes sense to screw down the
> crypto to present as small an attack surface as possible.*



...and:


> *An old programmer maxim is that one should provide for Zero, One, or an
> Infinite number of any resource.  *
> *Since we do not desire an infinite number of representations of an onion
> address (per Roger) - and zero would not be useful, we should shoot for
> one, and only one.**Not a cryptographic argument, but I think it's a
> human one.  :-)*


There's a lot more, but I don't want to bury folk with a huge multi-message
e-mail exchange; plus there is a lot of useful context "up-thread".  :-)



> As mentioned elsewhere in the thread, this is solved if that descriptor
> contains (under the signature by the "master" onion key) the actual
> onion address you were expected to use to get there.  Does it?  If so,
> I think we don't have to worry about this problem at all.


I hope it does.  That sounds very much like what I expect to see in other
network stacks.  :-)

-a

-- 
http://dropsafe.crypticide.com/aboutalecm
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[Ian Goldberg]

On Wed, Apr 05, 2017 at 10:02:07AM -0400, David Goulet wrote:
> Another thing about this I just thought of. This AONT construction seems wise
> to use. But it's still not entirely clear to me why we need a 1bit version
> field. Taking this:
> 
> base64( AONT( pubkey || 0x ) || version)
> 
> If the version is 1 byte, then only the end of the address can be mangled with
> and if it is, the tor client won't be able to fetch the descriptor because of
> how the URL is constructed (correct version number is needed).
> 
> So I really don't see the phishing attack here being successful at all...?
> 
> Can you enlighten what attack we are trying to avoid here that we require a
> 1bit version field?

I believe the danger Alec was wanting to avoid was that someone (not the
onion service owner) could take an existing onion address, bump the
version number (which wouldn't change the vanity beginning of the
address), and upload the very same descriptor to the resulting blinded
address (under the new version number).  Then the modified address would
work just like the original.

As mentioned elsewhere in the thread, this is solved if that descriptor
contains (under the signature by the "master" onion key) the actual
onion address you were expected to use to get there.  Does it?  If so,
I think we don't have to worry about this problem at all.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[David Goulet]

On 05 Apr (09:50:38), David Goulet wrote:
> On 27 Mar (04:58:34), Ian Goldberg wrote:
> > On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote:
> > > > To add an aside from a discussion with Teor: the entire "version" field
> > > > could be reduced to a single - probably "zero" - bit, in a manner 
> > > > perhaps
> > > > similar to the distinctions between Class-A, Class-B, Class-C... 
> > > > addresses
> > > > in old IPv4.
> > > > 
> > > > Thus: if the first bit in the address is zero, then there is no version,
> > > > and we are at version 0 of the format
> > > > 
> > > > If the first bit is one, we are using v1+ of the format and all bets are
> > > > off, except that the obvious thing then to do is count the number of 
> > > > 1-bits
> > > > (up to some limit) and declare that to be version number.  Once we're 
> > > > up to
> > > > 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.
> > > > 
> > > > Teor will correct me if I misquote him, but the advantage here was:
> > > > 
> > > > a) the version number is 1 bit, ie: small, for the forseeable / if we 
> > > > get
> > > > it right
> > > > 
> > > > b) in pursuit of smallness, we could maybe dump the hash in favour of a
> > > > AONT + eyeballs, which would give back a bunch of extra bits
> > > > 
> > > > result: shorter addresses, happier users.
> > > 
> > > You indeed do not require a checksum under an AONT, but you do require
> > > redundancy if you want to catch typos.  Something like
> > > 
> > > base64( AONT( pubkey || 0x ) || version)
> > > 
> > > is fine.  If you want "version" to be a single bit, then the AONT would
> > > have to operate on non-full bytes, which is a bit (ha!) annoying, but
> > > not terrible.  In that case, "0x" would actually be 15 bits of 0,
> > > and version would be 1 bit.  This would only save 1.4 base32 characters,
> > > though.  If you took off some more bits of the redundancy (down to 8
> > > bits?), you would be able to shave one more base32 char.  And indeed, if
> > > you make the redunancy just a single byte of 0x00, then the extra 0-bit
> > > for the "version" actually fits neatly in the one leftover bit of the
> > > base32 encoding, I think, so the AONT is back to working on full bytes.
> > > 
> > > But is a single byte of redundancy enough?  It will let through one out
> > > of every 256 typos.  (I thought we had spec'd 2 bytes for the checkcum
> > > now, but maybe I misremember?  I'm also assuming we're using a simple
> > > 256-bit encoding of the pubkey, rather than something more complex that
> > > saves ~3 bits.)
> > > 
> > > (Heading to the airport.)
> > 
> > OK, here are the details of this variant of the proposal.  Onion
> > addresses are 54 characters in this variant, and the typo-resistance is
> > 13 bits (1/8192 typos are not caught).
> > 
> > Encoding:
> > 
> > raw is a 34-byte array.  Put the ed25519 key into raw[0..31] and 0x
> > into raw[32..33].  Note that there are really only 13 bits of 0's for
> > redundancy, plus the 0 bit for the version, plus 2 unused bits in
> > raw[32..33].
> > 
> > Do the AONT.  Here G is a hash function mapping 16-byte inputs to
> > 18-byte outputs, and H is a hash function mapping 18-byte inputs to
> > 16-byte outputs.  Reasonable implementations would be something like:
> > 
> > G(input) = SHA3-256("Prop224Gv0" || input)[0..17]
> > H(input) = SHA3-256("Prop224Hv0" || input)[0..15]
> > 
> > raw[16..33] ^= G(raw[0..15])
> > # Clear the last few bits, since we really only want 13 bits of redundancy
> > raw[33] &= 0xf8
> > raw[0..15] ^= H(raw[16..33])
> > 
> > Then base32-encode raw[0..33].  The 56-character result will always end
> > in "a=" (the two unused bits at the end of raw[33]), so just remove that
> > part.
> > 
> > Decoding:
> > 
> > Base32-decode the received address into raw[0..33].  Depending on your
> > base32 decoder, you may have to stick the "a=" at the end of the address
> > first.  The low two bits were unused; be sure the base32 decoder sets
> > them to 0.  The next lowest bit (raw[33] & 0x04) is the version bit.
> > Ensure that (raw[33] & 0x04 == 0); if not, this is a different address
> > format version you don't understand.
> 
> I do understand the problem (I think) with the version field being longer than
> a single bit but it kind of causes some problem on the engineering and
> protocol side. Here is why:
> 
> The current plan is to put the HS protocol version in the address because when
> we fetch the descriptor from an HSDir, we use an URL that is on the form of
> "/tor/hs//" where  is the blinded key.

Another thing about this I just thought of. This AONT construction seems wise
to use. But it's still not entirely clear to me why we need a 1bit version
field. Taking this:

base64( AONT( pubkey || 0x ) || version)

If the version is 1 byte, then only the end of the address can be mangled with
and if it is, the tor client won't be able to fetch the descriptor because of
how the URL is constructed (correct 

Re: [tor-dev] Proposition: Applying an AONT to Prop224 addresses?

[David Goulet]

On 27 Mar (04:58:34), Ian Goldberg wrote:
> On Mon, Mar 27, 2017 at 01:59:42AM -0400, Ian Goldberg wrote:
> > > To add an aside from a discussion with Teor: the entire "version" field
> > > could be reduced to a single - probably "zero" - bit, in a manner perhaps
> > > similar to the distinctions between Class-A, Class-B, Class-C... addresses
> > > in old IPv4.
> > > 
> > > Thus: if the first bit in the address is zero, then there is no version,
> > > and we are at version 0 of the format
> > > 
> > > If the first bit is one, we are using v1+ of the format and all bets are
> > > off, except that the obvious thing then to do is count the number of 
> > > 1-bits
> > > (up to some limit) and declare that to be version number.  Once we're up 
> > > to
> > > 3 or 4 or 7 or 8 one-bits, then shift version encoding totally.
> > > 
> > > Teor will correct me if I misquote him, but the advantage here was:
> > > 
> > > a) the version number is 1 bit, ie: small, for the forseeable / if we get
> > > it right
> > > 
> > > b) in pursuit of smallness, we could maybe dump the hash in favour of a
> > > AONT + eyeballs, which would give back a bunch of extra bits
> > > 
> > > result: shorter addresses, happier users.
> > 
> > You indeed do not require a checksum under an AONT, but you do require
> > redundancy if you want to catch typos.  Something like
> > 
> > base64( AONT( pubkey || 0x ) || version)
> > 
> > is fine.  If you want "version" to be a single bit, then the AONT would
> > have to operate on non-full bytes, which is a bit (ha!) annoying, but
> > not terrible.  In that case, "0x" would actually be 15 bits of 0,
> > and version would be 1 bit.  This would only save 1.4 base32 characters,
> > though.  If you took off some more bits of the redundancy (down to 8
> > bits?), you would be able to shave one more base32 char.  And indeed, if
> > you make the redunancy just a single byte of 0x00, then the extra 0-bit
> > for the "version" actually fits neatly in the one leftover bit of the
> > base32 encoding, I think, so the AONT is back to working on full bytes.
> > 
> > But is a single byte of redundancy enough?  It will let through one out
> > of every 256 typos.  (I thought we had spec'd 2 bytes for the checkcum
> > now, but maybe I misremember?  I'm also assuming we're using a simple
> > 256-bit encoding of the pubkey, rather than something more complex that
> > saves ~3 bits.)
> > 
> > (Heading to the airport.)
> 
> OK, here are the details of this variant of the proposal.  Onion
> addresses are 54 characters in this variant, and the typo-resistance is
> 13 bits (1/8192 typos are not caught).
> 
> Encoding:
> 
> raw is a 34-byte array.  Put the ed25519 key into raw[0..31] and 0x
> into raw[32..33].  Note that there are really only 13 bits of 0's for
> redundancy, plus the 0 bit for the version, plus 2 unused bits in
> raw[32..33].
> 
> Do the AONT.  Here G is a hash function mapping 16-byte inputs to
> 18-byte outputs, and H is a hash function mapping 18-byte inputs to
> 16-byte outputs.  Reasonable implementations would be something like:
> 
> G(input) = SHA3-256("Prop224Gv0" || input)[0..17]
> H(input) = SHA3-256("Prop224Hv0" || input)[0..15]
> 
> raw[16..33] ^= G(raw[0..15])
> # Clear the last few bits, since we really only want 13 bits of redundancy
> raw[33] &= 0xf8
> raw[0..15] ^= H(raw[16..33])
> 
> Then base32-encode raw[0..33].  The 56-character result will always end
> in "a=" (the two unused bits at the end of raw[33]), so just remove that
> part.
> 
> Decoding:
> 
> Base32-decode the received address into raw[0..33].  Depending on your
> base32 decoder, you may have to stick the "a=" at the end of the address
> first.  The low two bits were unused; be sure the base32 decoder sets
> them to 0.  The next lowest bit (raw[33] & 0x04) is the version bit.
> Ensure that (raw[33] & 0x04 == 0); if not, this is a different address
> format version you don't understand.

I do understand the problem (I think) with the version field being longer than
a single bit but it kind of causes some problem on the engineering and
protocol side. Here is why:

The current plan is to put the HS protocol version in the address because when
we fetch the descriptor from an HSDir, we use an URL that is on the form of
"/tor/hs//" where  is the blinded key.

The reason we put the version number in the URL like the in the above is
because we might NOT use a 32 bytes key in future version when looking up the
descriptor so the version tells us what  is. Second, imagine a world in few
years where we have v3, v4 and v5 all living happily together and the
addresses are all 54 characters. On the client side, it would be really not
good that we do a fetch for all possible version and see which one works thus
having the version in the address prevents that.

I get that the solution to "which version to look up" with this proposed
change is that if v3 address, the version bit is 0, else if that bit is 1, try
decode v4. Then repeat 

Re: [tor-dev] ***SPAM*** Re: Proposition: Applying an AONT to Prop224 addresses?

[George Kadianakis]

Ian Goldberg  writes:

> On Mon, Apr 03, 2017 at 02:53:17PM +0100, Alec Muffett wrote:
>> On 3 April 2017 at 13:04, George Kadianakis  wrote:
>> 
>> > I'm calling it weird because I'm not sure how an
>> > attacker can profit from being able to provide two addresses that
>> > correspond to the same key, but I can probably come up with a few
>> > scenarios if I think about it.
>> 
>> 
>> Hi George!
>> 
>> I'll agree it's a weird edge case :-)
>> 
>> I think the reason my spider-sense is tingling is because years of cleaning
>> up after intrusions has taught me that sysadmins and human beings are very
>> bad at non-canonical address formats, especially where they combine them
>> with either blacklisting, or else case-statements-with-default-conditions.
>> 
>> If one creates scope for saying "the address is .onion but you can
>> actually use .onion or .onion which are equivalent" - then
>> someone will somehow leverage that either a) for hackery, or b) for social
>> engineering.
>> 
>> Compare:
>> 
>> * http://01770001
>> * http://2130706433
>> * http://0177.0.0.1  <- this one tends to surprise people
>> * http://127.0.0.1
>> 
>> …and the sort of fun shenanigans that can be done with those "equivalent
>> forms"
>> 
>> People who've been trained not to type [X] into their browser, might be
>> convinced to type [X']
>> 
>> It's a lot easier for people to cope with there being one-and-only-one
>> viable form for any given hostname or address-representation.
>
> But as I said to Alec in AMS, anyone on the internet can register
> "facebook.mydomain.com" and have the A record point to the same thing as
> facebook.com.  So there are always alternate names for any given
> website.  TLS, of course, is designed to protect against these
> shenanigans.
>

Hey,

sorry for the slow responses to this thread. Got lots of post-meeting
backlog to handle, and I'm also working on the various ed25519 stuff.

Specifically, I'm now working on the suggested check of multiplying any
received curve25519 point with the group order and ensuring the result
is the identity element.

> Prop224 *also* (mostly) protects against these shenanigans, because even
> if there were two onion addresses that resolved to the same pubkey, the
> daily blinded version incorporates the original onion address (not just
> the pubkey, right?  *Right?*), so the alternate address-with-same-pubkey
> won't actually point anywhere.  However, an adversary can upload a
> descriptor there; I'm not sure what the implications of that are just
> now.
>

Actually, I *don't* think that the blind factor of the derived key
incorporates the actual onion address. Citing the proposal:

  Let the basepoint be written as B. Assume B has prime order l, so
  lB=0. Let a master keypair be written as (a,A), where a is the private
  key and A is the public key (A=aB)

  To derive the key for a nonce N and an optional secret s, compute the
  blinding factor h as H(A | s, B, N), and let:

Perhaps we can add another component to h as follows:
 h = H(A, s, B, N, ONIONADDRESS)
where ONIONADDRESS is a string representation of the service's onion address.

I think this code is already implemented, but this might be worth fixing anyhow.
I'll make a ticket.

> The other thing to remember is that didn't we already say that
>
> facebookgbiyeqv3ebtjnlntwyvjoa2n7rvpnnaryd4a.onion
>
> and
>
> face-book-gbiy-eqv3-ebtj-nlnt-wyvj-oa2n-7rvp-nnar-yd4a.onion
>
> will mean the same thing?  So we're already past the "one (st)ring to
> rule them all" point?
>

I don't think we have actually decided on such a feature yet. It was
suggested but the tradeoffs are not clearly skewed to the "let's do it"
direction.

Cheers!
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev