Subject: [dane] case sensitivity and draft-ietf-dane-smime / draft-wouters-dane-openpgp

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Sep 2013 10:52:26 -0400 (EDT)

It was brought to my attention by Matthias Wimmer that we overlooked
an important issue with respect to the base32 generation of the base32
encoded left hand side of the email address.

Mail servers and mail clients do not treat email addresses as
case-insensitive. When encoding an LHS with base32, the case matters.
Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY
record.

paul@bofh:$ python
Python 2.7.3 (default, Aug  9 2012, 17:23:57) 
[GCC 4.7.1 20120720 (Red Hat 4.7.1-5)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import base64
>>> base64.b32encode("paul")
'OBQXK3A='
>>> base64.b32encode("Paul")
'KBQXK3A='

We should probably add a section explaining this, and perhaps suggest to
lowercase before base32'ing the LHS for the lookup.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 9 Sep 2013 15:16:46 +0000

> Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY

This is not accurate.  While domain part of an email address is
case-insensitive, the case-sensitivity of the local-part  is a
local matter.  SMTP relays MUST NOT change the case of the local
part of envelope addresses.  On arrival at the destination domain,
that domain's mail system may choose to treat local-parts case
insensitively, but remote systems must not rely on this.

Therefore, <[email-masked]> and <[email-masked]> are a-priori
distinct addresses except perhaps in the hands of the MTAs that
handle example.com mail.

[ The fact that most systems are in practice case-insensitive is not
  sufficient to invalidate the right of some to be case sensitive as
  they see fit. ]

-- 
	Viktor.

---

From: Francis Dupont <[email-masked]>
Date: Mon, 09 Sep 2013 17:18:46 +0200

In your previous mail you wrote:

>  case-insensitive.

=> in fact the specs said they are case-sensitive (so Dupont and dupont
are not the same) at the exception of postmaster (or Postmaster or
PosTMAstEr or ...) so all implementations make them case-insensitive
(or with other words implementers didn't read the specs: another proof
is the space in left part of email addresses, allowed or not? :-).

>  We should probably add a section explaining this,

=> I assume that "should probably" is a style effect...

Regards

[email-masked]

---

From: Jakob Schlyter <[email-masked]>
Date: Mon, 9 Sep 2013 17:26:48 +0200

> lowercase before base32'ing the LHS for the lookup.

Yes, this would be the reasonable thing to do.

	jakob

---

From: Paul Wouters <[email-masked]>
Date: Mon, 9 Sep 2013 11:49:57 -0400 (EDT)

>  sufficient to invalidate the right of some to be case sensitive as

The _last_ thing I want to do is having an email client not encrypt a
message because someone mailed [email-masked] instead of
[email-masked].

So I think our choices are:

1) do a lookup for the case "as is" and a lookup for lowercased (serial
    or parallel)

2) lowercase and lookup once.

What I do _not_ think is a valid choice is "only do the as is case
lookup".

Paul

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Sep 2013 10:05:25 -0600

On 9/9/13 9:26 AM, Jakob Schlyter wrote:
>> We should probably add a section explaining this, and perhaps
>> suggest to lowercase before base32'ing the LHS for the lookup.
> 

And let's not forget that "lowercase" can mean something less
intuitive outside the ASCII range...

http://datatracker.ietf.org/doc/rfc6530/

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 9 Sep 2013 20:43:11 +0200

>  sufficient to invalidate the right of some to be case sensitive as

Just for the record - in SIP the username part is case-sensitive.

/O

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Sep 2013 13:50:25 -0400

> encoded left hand side of the email address.

"We" did not overlook that: as author, I made that decision completely purposefully.

> Mail servers and mail clients do not treat email addresses as

That is sometimes-true statement.

> When encoding an LHS with base32, the case matters.

Yes, exactly. And so does internationalization.

> Using the wrong case will cause you to not find the SMIMEA / OPENPGPKEY

Yep. And will cause you to sometimes send mail to the wrong recipient.

> lowercase before base32'ing the LHS for the lookup.

Yes; no.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 10 Sep 2013 16:09:06 -0400 (EDT)

> "We" did not overlook that: as author, I made that decision completely purposefully.

Perhaps documentation of that decision belonged in the Security Section
of that document? :)

> Yep. And will cause you to sometimes send mail to the wrong recipient.

I'm really not okay with a protocol where I encrypt to the wrong key
based on the case of the email address.

>> lowercase before base32'ing the LHS for the lookup.
     [citation needed]

Paul

---

From: "Dickson, Brian" <[email-masked]>
Date: Tue, 10 Sep 2013 21:13:39 +0000

Jumping in a bit late, but hopefully without having missed any of the fun.

The smime draft is silent on the whole MTA thing, probably because it
presumes that both processing received signed messages, and
sending/signing messages, is being done by the MUA.

As such, (finding the key and encrypting on its basis) is not a "protocol"
issue (case mismatch on input by the user), but an application thing.
Selecting the recipient through any UI interaction, rather than explicit
entry of the RFC 822-style address, is not a protocol issue.
If the UI and/or the user makes an error, that is not a protocol thing.

BTW - in case it isn't clear, my opinion of the inclusion of the letters
"M", "T", and "A" together in the PGP draft, is that it does not belong.
Encrypting contents falls clearly in the MUA space, and does NOT belong in
the MTA space.

DANE has excellent use cases in the MTA space, but only on use of TLS for
transport, not for message content.

That's my opinion, at least, and I'd be surprised if that doesn't reflect
consensus.

Brian

On 9/9/13 10:52 AM, "Paul Wouters" <[email-masked]> wrote:

>_______________________________________________
>dane mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/dane

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 10 Sep 2013 17:16:51 -0400

> Perhaps documentation of that decision belonged in the Security Section

I'm not clear what the security consideration of this is for DANE outside of what it is for all RFC 821(+bis)(+bis)(+bis) email has been.

> based on the case of the email address.

Errr, then maybe you should not send mail with PGP or S/MIME? Seriously: this issue precedes DANE by well over a decade.

>>> lowercase before base32'ing the LHS for the lookup.

We should add a note that case is preserved and that might be surprising; we should not suggest breaking RFC 821(+bis)(+bis)(+bis) in this protocol.

--Paul Hoffman

---

From: [email-masked] (Martin Rex)
Date: Tue, 17 Sep 2013 20:26:21 +0200 (CEST)

> message because someone mailed [email-masked] instead of

I do not think that anyone proposed that a MUA should silently fail
to encrypt (and send in the clear instead) if lookup of
"[email-masked]" does not provide a result.

> 2) lowercase and lookup once.

I definitely prefer (1), an would want the MUA to tell the user
if the lookup result for "as is" differs from the lookup result
for the lowercased Email address (this is both, for lookup failure for "as is"
and for different EMail address result between "as is" and "all lowercase".

> What I do _not_ think is a valid choice is "only do the as is case

While it is technically a valid implementation choice (and the only option
when there is no user present to confirm), it would not be very user
friendly, and alternative, much more user friendly behaviour seems
obvious and easy to implement.

-Martin