0003 XAS-3d — Email Wallets for Xahau

[RichardAH]

XAS 3d — Email Wallets for Xahau

Title:       Email Wallets for Xahau
Revision:    1 (2024-08-12)

Author:      Richard Holland

Affiliation: XRPL-Labs, InFTF, Evernode Labs

Background

Email is one of the longest running and most widely used protocols on the Internet today. Despite this email was largely considered insecure until the advent of RFC 8301 and 8463.

DomainKeys Identified Mail (DKIM) is an add-on protocol to email that allows an email provider (like Gmail, Hotmail, et al.) to publish a public key on their domain whilst using the corresponding private key to sign your outgoing emails. This allows the recipient of the email to check that the email really did come from your provider (and therefore from you) and that it was not modified in transit.

Herein proposed is an amendment that leverages this signing as a form of transaction authentication on Xahau, eliminating the need for additional wallet software, and allowing Xahau to be used with just a modern email address.

Qualifying emails

For an email to qualify as a transaction it must contain:

• A From address,
• A valid DKIM signature where the domain in the From address matches the DKIM domain,
• An instruction, either REMIT or REKEY as discussed below,
• The parameters to the instruction, being either an amount and currency or an address to rekey to, and
• In the instance of a REMIT, a To email address.

Address conversion

Each email address ( From / To ) is canonicalized by removing optional comments and tags, capitalization and in some case dots, before being SHA512 hashed twice (with the inner hash prepended with 0xEEEEFFFF). The first 20 bytes of the outer hash become an AccountID with a corresponding r-address. The r-address is unique to the email-address, and is a 1-1 mapping. Existing Xahau accounts created by other means cannot be linked to emails. An email address becomes a Xahau address and is activated in the normal way by sending sufficient gas funds to it.

Relaying and submission

A public relay is a daemon that listens at a specific email address for incoming qualifying emails that cc it. Upon receiving a qualifying email, it forwards the raw email content to a new websocket API provided by xahaud: submitEmail.

The submitEmail API verifies the email is a qualifying email, constructs an equivalent transaction, but does not sign it. The raw email is then placed in the first Memo of the transaction and a global transaction flag tfEmailSig is set.

The transaction is then circulated into consensus as per normal. If the featureEmail amendment is enabled then the memo will act as the signature in consensus.

Should a relay fail, the recipient of the email may manually submit it for a period of up to 5 days. It is important that the email provider supplies accurate t= tags in their DKIM headers, to avoid replay attacks. If you do not trust your email provider, change email providers!

Replay attacks

To prevent replay attacks the DKIM signature of the message is hashed and recorded against the sender's Xahau account. This hash is held for 5 days in a ledger object up to a nominal maximum number of entries. Cleanup is amortized across further submissions. Fees are adjusted according to the burden of storing this extra data. Emails older than 5 days cannot be submitted.

A transaction failure also results in an entry.

Instructions

A qualifying email contains either a REMIT instruction or a REKEY instruction. The instruction must come at the beginning of a new line and the entire line must contain only the instruction and its parameters.

The REMIT instruction follows these formats:

REMIT 10.15 USD/rIssuerAddress
REMIT 0.5 XAH

Any variation invalidates the instruction, including trailing characters or preceding characters. The instruction is translated into a Remit transaction from the From email address (or more specifically its corresponding r-address) to the To email address for the amount and currency specified.

The REKEY instruction follows this format:

REKEY rSomeNewKeyingAddress

Any variation invalidates the instruction, including trailing characters or preceding characters. The instruction is translated into a SetRegularKey transaction changing the keying of the From address. The To address is ignored.

Conclusion

With this proposed amendment it is possible to operate a Xahau wallet for payments without using wallet software. All that is required is a DKIM-enabled email provider... which most are in 2024. A user can receive and send multiple currencies and interact with Hooks using only their email address and browser. Should a user want to upgrade to a fully functional wallet software, they can do so by setting a Regular Key using the REKEY instruction. This provides a simple and powerful new way for inexperienced users to benefit from, and being included in, Xahau.

[Cadey]

Hiya @RichardAH

DKIM normally is a means to trust a server has sent an email for a domain and the signatures are done at the domain level. The public key being singular for the domain.

I understand the approach your taking but im not sure how you will know "Neil" sent the email and not just the service "@neilsdomain.com" has said can send emails for my domain?

I cant recall the name now but there used to be another form of secure email, i think literally just signed mail. Which encoded the body of the enail using the private key and the public key was in the email body for verification. The certs name being the email address.

Or did i misunderstanding somthing :)

[Cadey]

The issue with each email having its own cert however moves to the issuer, since multiple issues can issues email address certs you still need the dns to point to a trusted CA for the domain and only accept email certs issues from that cert chain.

Typing while thinking 🤔

[jscottbranson]

DKIM includes the 'from' address in the signature, so while signing happens at the domain level, the sending address within that domain can also be verified.

There are some implementations using PGP for secure email, but that typically involves a need for encryption, rather than just signature verification.

[Cadey]

Yes indeed - this is my issue. DKIM only verifies the SMTP relay is allowed to send on-behalf of the domain. Its not intended to prove "cadey" sent and email from "cadey@mydomain.com"

The risk here is that e-mail is one of the most weakly secured mediums in the world.

It will bring in trust issues with e-mail service providers too - If an bad actor decided to send an e-mail from the relay the ledger would have no idea it wasn't really "cadey" that sent it.

Its 100% something which needed to be considered before people create a wallet this way.

[RichardAH]

No you're thinking of SPF. DKIM does indeed verify that the email is from a particular address, assuming the email provider is run properly.

[Cadey]

Sorry I mean that "Cadey" actually sent the e-mail from "cadey@mydomain.com" - "Cadey" being the human who owns the email alias.

I understand DKIM verifies that the e-mail you got hasn't been changed (spoofed from address, etc, in transit)

[jscottbranson]

Thanks so much for drafting this, Richard, it is a really neat and convenient idea!

Can you please clarify more how the submitEmail API endpoint would function? As I read your draft, it seems like DKIM verification would take place in xahaud (as opposed to calling OpenDKIM or relying on the public relay you describe to verify the signature). If this is the case, can users define parameters like the DNS servers used to retrieve the DKIM public key?

Also, it seems like this could provide a rouge system administrator with a massive attack vector. Perhaps users should be warned that their email provider has the ability to submit transactions on their behalf. It seems like users should consider their email r addresses similar to their personal wallet - a place to keep some spending money, not one's entire life savings.

DNS servers would provide another potential attack vector, but that's a larger issue that seems outside the scope of this.

[RichardAH]

My pleasure.

Yes DKIM verification happens in 3 places:

1. The relayer should refuse to accept the email if it fails DKIM checks
2. The submitEmail API in xahaud will run the check locally and will refuse to submit it to consensus if it fails.
3. Every node on the xahaud network will perform a DKIM check when the transaction is circulated into consensus, and only if the DKIM check passes can the email be considered a valid signature for the transaction.

There's no config option to set DNS servers, but they are simple to configure on the host.

[Cadey]

Can any one host an e-mail relay and submit to the ledger, and is it open source?

If anyone can host one, could they not just accept (or even just make up that an email was sent) any emails (ignoring the DKIM check) and submit like above? or do all the nodes check the e-mails content in the memo, compare it to the transaction and also perform a DKIM check to verify the e-mail?

[RichardAH]

All nodes perform DKIM check in consensus, there's no trust required of the relayers.

[Cadey]

ok cool :)

[marklikeapenny]

Could you please supply some information how private keys of those email accounts would be managed by xahaud ?

[Cadey]

I think its how i said, the r address is created from that hash data. Its not a cryptographically generated r address which would have a seed. The hash bytes creates the address.

[marklikeapenny]

So this would mean xahaud would be extended to greenlight a completely new type of signed transactions (DKIM approval vs traditional private key signature) ?

[Cadey]

I think so yes. Let see what @RichardAH confirms.

Keep in mind the signing part is just a proof a wallet actually sent the instruction to the ledger. This proposal is essentially adding a new way to prove an instruction was sent by the address and not anything else.

[jscottbranson]

It seems like the REKEY feature can be invoked to add the keys from another r address to the wallet, thus allowing transactions even if one's email provider is no longer accessible, correct?

I would also appreciate more clarification on @Cadey's point - is it possible to derive a master key for the email r address?

[Cadey]

Yeah - you can send any transaction - so you can add a new wallets address as a second yet to use it like a normal wallet.

You could use this to recover a lost E-mail - however in the case of a lost email (lost domain name for example) this does raise a very good point.

Don't do things like issues an NFT collection with an E-mail wallet because at least in theory, you could lose your domain name (accident or not) and inadvertently give them access to your on-chain stuff.

[mvadari]

nit: shouldn't the API be called submit_email to match with the snake_case formatting of the other APIs?