Subject: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then for draft-ietf-dane-smime)

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Apr 2015 18:22:57 -0700

Greetings again. The discussion about exact-match and discovery in draft-ietf-dane-openpgpkey has been useful for finding out what the use cases are, and it's time to settle on a design that works for most people (we're never going to make everyone happy). My motivation for this message is that Jakob and I will match whatever the WG comes up with for draft-ietf-dane-openpgpkey in our draft-ietf-dane-smime draft.

Proposal:

- Lookup of OpenPGP and S/MIME keys and certs in the DNS are exact-match, following the DNS's database model. This is known to possibly fail when the party looking up the address has a copy of the email address different than what might be entered in the zone, such as with different casing. There is no expectation in this design that all variants that might be delivered to for a particular address will have key records. This design keeps the security model understandable: it's all authenticated just by DNSSEC.

- Discovery of delivery variants is better handled by a more flexible protocol, such as WebFinger. In fact, instead of just looking for variants and then coming back to the DNS to get the key, that protocol can instead hand back the keys and certs directly in a single response. The security model for that protocol would also be simple: it's all authenticated by the TLS cert of the server. This new protocol should probably be designed somewhere in the Applications Area, not here, even though some of what is being delivered are objects similar to what we are delivering here.

If folks agree with this proposal, we can move forwards with draft-ietf-dane-openpgpkey pretty much as it is. (PaulW: you threw in downcasing before hashing, which is definitely not what people agreed to at the meeting.) For draft-ietf-dane-smime, we can then use the same format and semantics, and add in the LDAP access model proposed by Eric and Scott, which historically has never applied to OpenPGP.

Thoughts?

--Paul Hoffman

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 5 Apr 2015 18:56:54 -0700

On Apr 5, 2015, at 6:22 PM, Paul Hoffman <[email-masked]> wrote:

> Greetings again. The discussion about exact-match and discovery in draft-ietf-dane-openpgpkey has been useful for finding out what the use cases are, and it's time to settle on a design that works for most people (we're never going to make everyone happy).

How can we possibly do that without real experience in the field?

I know for a fact the case insensitive hashing rules will break Cyrus, where foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is distinct from foo+bar@mumble, delivering to 'inbox.bar'.  Folder names are case sensitive, so the two addresses are not equivalencies.

Ultimately, I don't see a way out of this other than to make a standard for sub-addressing, with a well defined cut-point delimiter.

But that still doesn't change how the LHS has been defined as case-sensitive since the dawn of time.  If we are to change this, RFC5322 3.4.1 needs a change in its last paragraph.  As things stand, we cannot treat <local-part> as case-insensitive in any interpretation of the grammar.

--lyndon

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 5 Apr 2015 19:19:09 -0700

> How can we possibly do that without real experience in the field?

How can we possibly get real experience in the field unless we get at-least-rough consensus on a direction and publish a document?

> I know for a fact the case insensitive hashing rules will break Cyrus, where foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is distinct from foo+bar@mumble, delivering to 'inbox.bar'.  F…

I'm not sure what "break" means in this context. It means, as I proposed, that Cyrus will not be able to do exact-match lookup of key/cert records, but that doesn't "break" Cyrus any more than the current situation where no lookup is possible.

> Ultimately, I don't see a way out of this other than to make a standard for sub-addressing, with a well defined cut-point delimiter.

That's an alternative for the second point I proposed, one that I think would be much harder to get agreement on than "Webfinger to find keys/certs".

> But that still doesn't change how the LHS has been defined as case-sensitive since the dawn of time.  If we are to change this, RFC5322 3.4.1 needs a change in its last paragraph.  As things stand,…

Nothing in what I proposed (or what has been proposed before now) changes anything about how LHSs are treated. The address in mail messages don't change at all.

--Paul Hoffman

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 5 Apr 2015 19:50:41 -0700

> How can we possibly get real experience in the field unless we get at-least-rough consensus on a direction and publish a document?

Then at the very least, the security section needs to call out explicitly the potential for hash collisions caused by the case-folding behaviour mandated by the draft.  And that should include a specific reference to RFC 5322 section 3.4.1.  (And an informative reference to 5322.)

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 5 Apr 2015 19:56:00 -0700

> -----Original Message-----
> From: dane [mailto:[email-masked]] On Behalf Of Lyndon Nerenberg
> Sent: Sunday, April 05, 2015 6:57 PM
> To: Paul Hoffman
> Cc: [email-masked]
> Subject: Re: [dane] Proposed design for draft-ietf-dane-openpgpkey (and
> then for draft-ietf-dane-smime)
> 
> 
> > Greetings again. The discussion about exact-match and discovery in
draft-
> ietf-dane-openpgpkey has been useful for finding out what the use cases
are,
> and it's time to settle on a design that works for most people (we're
never
> going to make everyone happy).
> 
> I know for a fact the case insensitive hashing rules will break Cyrus,
where
> foo+Bar@mumble will deliver to mailbox 'inbox.Bar', which is distinct from
> foo+bar@mumble, delivering to 'inbox.bar'.  Folder names are case
sensitive,
> so the two addresses are not equivalencies.

What I read of Paul's message was that the hashing would be on case
sensitive strings.  This means that the two strings above will produce
different results.  

> 
> Ultimately, I don't see a way out of this other than to make a standard
for sub-
> addressing, with a well defined cut-point delimiter.

If this is going to be done, then it will need to be back ported into the
S/MIME and PGP specifications as well.  The S/MIME specification says that
names SHOULD be matched case insensitive,   I was unable to find any rules
in the OpenPGP spec for how user IDs and email address are matched.
However, neither of these documents dealt with sub-addressing in any way and
would ignore the fact that one is trying to do this.  Thus foo+Bar and
foo+bar are going to be matched, but [email-masked] and [email-masked]
are not going to be matched by S/MIME implementations.

In S/MIME this decision was made to make most people happy.  However, I do
know that there are implementations where the names are matched case
sensitive rather than case insensitive.

Jim

> 
> But that still doesn't change how the LHS has been defined as
case-sensitive
> since the dawn of time.  If we are to change this, RFC5322 3.4.1 needs a
> change in its last paragraph.  As things stand, we cannot treat
<local-part> as
> case-insensitive in any interpretation of the grammar.
> 
> --lyndon

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 5 Apr 2015 19:56:49 -0700

+1

Until somebody else solves the matching problem it should be acknowledged
and ignored.

Jim

> From: dane [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Sunday, April 05, 2015 6:23 PM
> To: [email-masked]
> Subject: [dane] Proposed design for draft-ietf-dane-openpgpkey (and then
for
> draft-ietf-dane-smime)
draft-ietf-
> dane-openpgpkey has been useful for finding out what the use cases are,
and
> it's time to settle on a design that works for most people (we're never
going to
> make everyone happy). My motivation for this message is that Jakob and I
will
> match whatever the WG comes up with for draft-ietf-dane-openpgpkey in our
> draft-ietf-dane-smime draft.
> 
> Proposal:
> 
> - Lookup of OpenPGP and S/MIME keys and certs in the DNS are exact-match,
> following the DNS's database model. This is known to possibly fail when
the
> party looking up the address has a copy of the email address different
than
> what might be entered in the zone, such as with different casing. There is
no
> expectation in this design that all variants that might be delivered to
for a
> particular address will have key records. This design keeps the security
model
> understandable: it's all authenticated just by DNSSEC.
> 
> - Discovery of delivery variants is better handled by a more flexible
protocol,
> such as WebFinger. In fact, instead of just looking for variants and then
coming
> back to the DNS to get the key, that protocol can instead hand back the
keys
> and certs directly in a single response. The security model for that
protocol
> would also be simple: it's all authenticated by the TLS cert of the
server. This
> new protocol should probably be designed somewhere in the Applications
> Area, not here, even though some of what is being delivered are objects
> similar to what we are delivering here.
> 
> If folks agree with this proposal, we can move forwards with
draft-ietf-dane-
> openpgpkey pretty much as it is. (PaulW: you threw in downcasing before
> hashing, which is definitely not what people agreed to at the meeting.)
For
> draft-ietf-dane-smime, we can then use the same format and semantics, and
> add in the LDAP access model proposed by Eric and Scott, which
historically
> has never applied to OpenPGP.
> 
> Thoughts?
> 
> --Paul Hoffman
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane

---

From: Lyndon Nerenberg <[email-masked]>
Date: Sun, 5 Apr 2015 20:00:16 -0700

> sensitive strings.  This means that the two strings above will produce

That's not what I'm reading out of the draft, which seems to me to call out for explicit case folding before generating the hash.

---

From: "Jim Schaad" <[email-masked]>
Date: Sun, 5 Apr 2015 20:23:17 -0700

> From: Lyndon Nerenberg [mailto:[email-masked]]
> Sent: Sunday, April 05, 2015 8:00 PM
> To: Jim Schaad
> Cc: [email-masked]
> That's not what I'm reading out of the draft, which seems to me to call
out for
> explicit case folding before generating the hash.

Yes - that is what the note at the bottom of Paul's message was about

(PaulW: you threw in downcasing before hashing, which is definitely not what
people agreed to at the meeting.)

Jim

---

From: Paul Wouters <[email-masked]>
Date: Sun, 5 Apr 2015 23:51:43 -0400 (EDT)

> people agreed to at the meeting.)

Which I did, based on the following related text in a draft by John
Levine that I thought was something shared amongst the app/email people:

https://tools.ietf.org/html/draft-levine-dns-mailbox-00#section-1

    Mail systems usually handle variant forms of local-parts.  The most
    common variants are upper and lower case, which are now invariably
    treated as equivalent.

This would greatly enhance the lookup mechanism to help in case of "auto
uppercasing" that is very common in webforms and mobile phone input
methods via virtual keyboards. That is, if I start composing an email to
myself, after I type "paul@" it will help me and correct it to "Paul@".

I believe this use case is MANY times more common than case sensitive
LHS. And as PaulH already said, we are not changing the case of the
actual email delivery.

Otherwise, everyone generating OPENPGPKEY records basically has to add
a CNAME for hash(Paul) pointing to the hash(paul) OPENPGPKEY record.

So it is the lesser of two evils,

Paul

---

From: "John Levine" <[email-masked]>
Date: 6 Apr 2015 14:37:56 -0000

In article <[email-masked]> you write:
>-=-=-=-=-=-
>-=-=-=-=-=-
>> Greetings again. The discussion about exact-match and discovery in draft-ietf-dane-openpgpkey
>has been useful for finding out what the use cases are, and it's time to settle on a design that
>works for most people (we're never going to make everyone happy).
>

Publish the thing as experimental and be done with it.

It's not an accident that SMTP and DNS have both been around for 30
years and nobody has ever published mailbox info in the DNS.  It's a
really hard problem with no good solution.  Every approach has
security problems (address guessing), doesn't scale (static zones
particularly if they include address variants), and/or works in ways
the DNS crowd doesn't like (dynamic replies to base32 requests.)
Throughout this argument, there's been nothing new.

It's evident that a few people want to try retrieving keys for mail
messages from the DNS. This allows a way to experiment with it.

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 6 Apr 2015 07:49:57 -0700

> Publish the thing as experimental and be done with it.

The proposals are no more "experimental" than TLSA is. Further, they don't follow the guidelines from the IETF process for what is called "experimental" (RFC 2026, section 4.2.1) any more than over half of the RFCs produced by WGs these days. These are standards-track proposals that, like a large percentage of standards-track RFCs, might or might not garner much deployment.

--Paul Hoffman

P.S. And, no, let's not turn this into an argument about IETF process and what "should" be "experimental".

---

From: Pieter Lexis <[email-masked]>
Date: Tue, 07 Apr 2015 12:53:16 +0200

Hi,

On 04/06/2015 03:22 AM, Paul Hoffman wrote:
> - Lookup of OpenPGP and S/MIME keys and certs in the DNS are
> exact-match, following the DNS's database model. This is known to
> possibly fail when the party looking up the address has a copy of the
> email address different than what might be entered in the zone, such
> as with different casing. There is no expectation in this design that
> all variants that might be delivered to for a particular address will
> have key records. This design keeps the security model

Yes, if that is made explicit in the draft, it won't lead to false
assumptions by implementors. The draft does need some information on
UIDs on the keys and whether or not to match the recipients address
against them.

> protocol, such as WebFinger. In fact, instead of just looking for
> variants and then coming back to the DNS to get the key, that
> protocol can instead hand back the keys and certs directly in a
> single response. The security model for that protocol would also be
> simple: it's all authenticated by the TLS cert of the server. This
> new protocol should probably be designed somewhere in the
> Applications Area, not here, even though some of what is being
> delivered are objects similar to what we are delivering here.

Agreed, I started a write-up for a somewhat generic 'email metadata'
lookup mechanism with the intention of grabbing OpenPGP and S/MIME data
via webfinger. I hope to have an initial version done this week.

> draft-ietf-dane-openpgpkey pretty much as it is. (PaulW: you threw in
> downcasing before hashing, which is definitely not what people agreed
> to at the meeting.) For draft-ietf-dane-smime, we can then use the
> same format and semantics, and add in the LDAP access model proposed
> by Eric and Scott, which historically has never applied to OpenPGP.

Yes, with the remarks above :).

Regards,

Pieter