Subject: [saag] I-D Action: draft-birk-pep-trustwords-00.txt (fwd)

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 23 Feb 2018 11:42:28 +0100 (CET)

Please be informed that another I-D of the pEp (Pretty Easy Privacy) 
series has just been published. You can find it on:

   https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/

Abstract:

   In public-key cryptography comparing the public keys' fingerprints of
   the communication partners involved is vital to ensure that there is
   no man-in-the-middle (MITM) attack on the communication channel.
   Fingerprints normally consist of a chain of hexadecimal chars.
   However, comparing hexadecimal strings is often impractical for
   regular users and prone to misunderstandings.

   To mitigate these challenges, this memo proposes the comparision of
   trustwords as opposed to hexadecimal strings.  Trustwords are common
   words in a natural language (e.g., English) to which the hexidecimal
   strings are mapped to.  This makes the verification process more
   natural.

Anyways, we are looking forward to your feedback!

All the best
  Bernie

---------- Forwarded message ----------
From: <[email-masked]>
Date: Thu, Feb 22, 2018 at 9:17 AM
Subject: I-D Action: draft-birk-pep-trustwords-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

        Title           : pretty Easy privacy (pEp): Trustwords concept
        Authors         : Volker Birk
                          Hernani Marques
                          Bernie Hoeneisen
        Filename        : draft-birk-pep-trustwords-00.txt
        Pages           : 6
        Date            : 2018-02-22

Abstract:
   In public-key cryptography comparing the public keys' fingerprints of
   the communication partners involved is vital to ensure that there is
   no man-in-the-middle (MITM) attack on the communication channel.
   Fingerprints normally consist of a chain of hexadecimal chars.
   However, comparing hexadecimal strings is often impractical for
   regular users and prone to misunderstandings.

   To mitigate these challenges, this memo proposes the comparision of
   trustwords as opposed to hexadecimal strings.  Trustwords are common
   words in a natural language (e.g., English) to which the hexidecimal
   strings are mapped to.  This makes the verification process more
   natural.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-birk-pep-trustwords/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-birk-pep-trustwords-00
https://datatracker.ietf.org/doc/html/draft-birk-pep-trustwords-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

From: Yoav Nir <[email-masked]>
Date: Fri, 23 Feb 2018 15:30:35 +0200

Hi, Bernie.

How is this better/different from RFC 1751?

Thanks

Yoav

> On 23 Feb 2018, at 12:42, Bernie Hoeneisen <[email-masked]> wrote:
> 
> Please be informed that another I-D of the pEp (Pretty Easy Privacy) series has just been published. You can find it on:
> 
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Bernie Hoeneisen <[email-masked]>
Date: Fri, 23 Feb 2018 16:06:47 +0100 (CET)

Hi Yoav

Thanks for you email.

This work is different from RFC1751 in many ways, e.g.:

1) The target audience for this new work to use are ordinary human users, 
i.e. not technical stuff (or IT geeks) only. (Even grandma shall be able 
to use it.)

2) The hexadecimal (sub-)strings mapped into a single trustword are 
longer. This results in fewer trustwords to compare, but more trustwords 
in the dictionary.

3) The keywords are only read (and compared), but not written down by 
humans

4) The keywords will be available in many languages as opposed to English 
only

Does this answer you question?

All the best
  Bernie

--

http://ucom.ch/
Modern Telephony Solutions and Tech Consulting for Internet Technology

---

From: Yoav Nir <[email-masked]>
Date: Fri, 23 Feb 2018 19:05:17 +0200

Hi.

At a former employer we used the function described in RFC 1751 to show a user the CA or server fingerprint so as to make sure that their VPN client was connecting to the correct server. It would be used as part of the instructions for the user:  Type in “192.0.2.5” or “vpnserver.example.com <http://vpnserver.example.com/>” at the server box, click “Connect” and you will see a fingerprint field. Make sure it says “TIDE ITCH SLOW REIN RULE MOT”.

This has proved OK for ordinary non-technical users, but I can’t be sure any of them ever compared the strings. It’s easier to just click OK. Similarly for point #3, I don’t think either of them calls for the user to write anything down, except in the instructions from the administrator.

BTW: even if you make sure your dictionary contains only innocuous words (no swear words), the combinations sometimes can be open to interpretations: HERO JAKE LAID JAIL BAIT GLAD can come out of the algorithm in RFC 1751.

Anyway, I think your draft should reference RFC 1751 and state these differences.

Yoav

> On 23 Feb 2018, at 17:06, Bernie Hoeneisen <[email-masked]> wrote:
> 
> Hi Yoav
> 
> Thanks for you email.
> 
> 1) The target audience for this new work to use are ordinary human users, i.e. not technical stuff (or IT geeks) only. (Even grandma shall be able to use it.)
> 
> 2) The hexadecimal (sub-)strings mapped into a single trustword are longer. This results in fewer trustwords to compare, but more trustwords in the dictionary.
> 
> 3) The keywords are only read (and compared), but not written down by humans
> 
> 4) The keywords will be available in many languages as opposed to English only
>

---

From: Michael Richardson <[email-masked]>
Date: Fri, 23 Feb 2018 13:45:21 -0500

> 4) The keywords will be available in many languages as opposed to English

I guess if two people speak different languages, then a mapping could exist
between languages?

While some might think this is too trivial for the IETF, I am rather in
favour such a specification.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 23 Feb 2018 13:57:49 -0500

> favour such a specification.

I don't think it's too trivial.  I think it's too hard.  We can't even
get people to review internationalization considerations for protcols
we understand.  Translating among languages strikes me as something
some distance past our set of skills.

I would not be opposed to setting up the registry for mappings to be
generated by someone else, however.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Hernâni Marques (p≡p foundation) <[email-masked]>
Date: Fri, 23 Feb 2018 21:55:51 +0100

> some distance past our set of skills.

I agree to this: what we're doing for now in implementations already
existing for opportunistic email encryption on pEp basis is to use the
system-lang to determine the default words to be shown by default. Word
lists exist in Catalan, Spanish, English, Turkish, French, German and
Dutsch, cf.

  https://pep.foundation/dev/repos/pEpEngine/file/68b7fb2ad5b2/db

If no Trustwords for system-lang exist, English is shown in fallback.

The words for now are taken from LibreOffice and cleaned from swearwords
(by native language speakers) in order to most probably less offense
people (somewhat taking into consideration cultural contexts, sense for
humour etc.).

It's assumed that most people will compare words to people of their own
region, i.e. in the system-lang. In any case, if people not speaking the
sames languages use a phone line or a physical meeting to compare the
Trustwords, they will need to agree on a wordlist of language (most
probably English makes sense here) -- in pEp languages can easily be
switched.

For fallback or to retain full entropy, also fingerprints should exist
in implementations using Trustwords for OpenPGP contexts. This also
allows for interoperability with OpenPGP users not knowing anything
about Trustwords.

However, Trustwords -- as stated in the document -- can also be used for
any other mapping where fingerprints play a role.

-- 
p≡p foundation: https://pep.foundation/

---

From: Volker Birk <[email-masked]>
Date: Fri, 23 Feb 2018 22:14:30 +0100

> any other mapping where fingerprints play a role.

BTW: I'm using them for SSH already.

Yours,
VB.
-- 
Volker Birk, p≡p project
mailto:[email-masked]
https://prettyeasyprivacy.com
https://pep.foundation

---

From: Hernâni Marques (p≡p foundation) <[email-masked]>
Date: Fri, 23 Feb 2018 23:38:47 +0100

> Anyways, we are looking forward to your feedback!

Neal Walfield (CC), working at p≡p foundation on Sequoia (a new OpenPGP
implementation in Rust: https://www.sequoia-pgp.org/), suggested to take
this two documents into consideration when discussing such mappings:

https://www.eff.org/de/deeplinks/2016/07/new-wordlists-random-passphrases

    https://www.ibr.cs.tu-bs.de/papers/schuermann-usenix2016.pdf

Thanks, Neal!

---

From: Bernie Hoeneisen <[email-masked]>
Date: Mon, 26 Feb 2018 10:09:53 +0100 (CET)

Hi Michael

What particular use case do you have in mind?

If people talk already with eachother (to compare fingerprints), I would 
assume they are already in agreement on a language they talk with 
each other, which then is the natural option to be used for trustwords.

Or do have use cases in mind where said language is not available for 
trustwords?

cheers,
  Bernie

--

http://ucom.ch/

---

From: Michael Richardson <[email-masked]>
Date: Mon, 26 Feb 2018 11:56:24 -0500

> assume they are already in agreement on a language they talk with each
    > other,
    > which then is the natural option to be used for trustwords.

That's a good point... it's certainly true if they are in direct communication.

It would not be true if I was authenticating a key printed in a newspaper
in a language I did not speak.  I guess it's enough if the UI can change
languages, and the user can attempt to pattern match languages they do not speak.