Subject: [dane] Comments on draft-ietf-dane-smime-04

From: "Jim Schaad" <[email-masked]>
Date: Thu, 6 Feb 2014 20:01:34 -0800

1.  Section 1, para 1: The first two sentences imply that a single
certificate is going to be present in a message.  While this is true in a
large number of cases, there are many times in which more than one
certificate may be present.  These include having different signing an
encrypting keys or intermediate certificates for chain building.  I would
request that the first two sentences be modified to make certificate be
plural.  s/a certificate. This certificate assists/certificates.  These
certificates assist/

2. Section 1, para 1: The last sentence is missing a step in the description
of the process of validating that  certificate is bound to a purported
sender.  The current text just looks at the validation process and does not
talk about what is necessary to check the binding itself.  In most cases,
but not all, this involves looking for the senders email address in the
certificate itself.  (In other cases some type of external database would be
required or one could say that the sender and the signer may not be the same
person even though the signature itself validates.)

One thing about this document that I don't remember having seen on the list
is the question of doing the binding check between the senders address and
the contents of a certificate.  Is it going to be considered sufficient if
one does the DNS look up for the certificates?  Is it only a sufficient
check for some types of SMIMEA records but not for others?  I.e. EE
certificate vs CA or TA certificate.

The document needs to distinguish between the steps of validating and
trusting a certificate and doing the binding between an email address and  a
certificate.  While it is possible to both in some cases, in others these
need to be distinct steps.

3.  Section 2, para 1:  First sentence - see the last item.  It may be not
an EE certificate that is being associated.

4.  Section 3, step 1:  It would be nice to be explicit that you are doing a
UTF8 Unicode string to octet string transformation before doing the Base32
conversion.  The referenced document says that this is the case for SMTP
submission in one mode, but it is not clear that the SMTP submission format
is what we are doing here.  Being explicit would be helpful.

There are two general problems that people are looking to solve with this
document.

A) I have an email address and a certificate, I want to validate the
certificate and check the association between the certificate and the email
address.

B) I have an email address, I need to find a certificate.

At present I believe that this document is addressing problem A and not
problem B.  It would be good to state that problem B is out of scope in the
introduction if this is the case.

If problem B is what the document is trying to solve, then there are a
number of issues that need to be addressed:

a) The set of certificate usages needs to be restricted to 1 and 3 so that
one will get a certificate about the EE
b) The set of certificates selectors needs to be restricted to 0 so that the
certificate is always present
c) The matching type needs to be restricted to 0 so that the certificate is
always present.

A mention, but problem not a solution, to the case folding problem for local
parts in email addresses needs to stated so that people understand it
exists.    A quote from RFC 6530 is

  It has long been the case that the email syntax permits choices about
   mailbox names that are unwise in practice, if one actually intends
   the mailboxes to be accessible to a broad range of senders.  The most
   often cited examples involve the use of case-sensitivity and tricky
   quoting of embedded characters in mailbox local parts.  These
   deliberately unusual constructions are permitted by the protocols,
   and servers are expected to support them.  Although they can provide
   value in special cases, taking advantage of them is almost always bad
   practice unless the intent is to create some form of security by
   obscurity.

Which would seem to me to say, yes this is a legal thing to do.  However if
you do it you should be taken back of the wood shed and whipped.  Thus
although it is legal it is highly unadvisable.  Thus one does case folding
in the look up, one may be get a wrong security answer so one should not do
it even if it is tempting.  I.e. - this at a minimum is a security
consideration because people are going to try and do it if we don't tell
them not to do it and why they should not do it.

---

From: "Osterweil, Eric" <[email-masked]>
Date: Thu, 13 Feb 2014 18:19:10 +0000

> plural.  s/a certificate. This certificate assists/certificates.  These

+1

> certificate vs CA or TA certificate.

I agree that we should discuss this.  With PGP, I can use a key with a diff email than the account from which I send it (for ex, I can use my spam account and rely on my full name and friends who know me to make the logical leap), do we all want DANE to outlaw this for S/MIME?  

> c) The matching type needs to be restricted to 0 so that the certificate is

Actually, Scott Rose's suggestions on this draft cover a mechanism to overcome this, by pointing at a place to learn certs.  I think this commentary helps to further underscore the utility of that.

Eric

---

From: James Cloos <[email-masked]>
Date: Thu, 13 Feb 2014 18:05:20 -0500

>>>>> "OE" == Osterweil, Eric <[email-masked]> writes:

OE> With PGP, I can use a key with a diff email than the account from
OE> which I send it (for ex, I can use my spam account and rely on my
OE> full name and friends who know me to make the logical leap), do we
OE> all want DANE to outlaw this for S/MIME?

Absolutely not.

There is no value in forcing the sending email address to match the info
in any signature over the message (or over any part of the message).

(With emphasis on /forcing/.)

Those details may be used as *part* of the trust equation, but only as part.

-JimC
--
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 13 Feb 2014 15:58:28 -0800

So what email address are you going to use to do the dane lookup?  The one
embedded in the PGP key (assuming one exists), the from address?  Does this
need to be spelled out in both of the drafts (S/MIME and PGP).

Jim

> -----Original Message-----
> From: James Cloos [mailto:[email-masked]]
> Sent: Thursday, February 13, 2014 3:05 PM
> To: [email-masked]
> Cc: Osterweil, Eric; Jim Schaad; <[email-masked]>
> Subject: Re: [dane] Comments on draft-ietf-dane-smime-04
> 
in
> any signature over the message (or over any part of the message).
>

---

From: Stephen Kent <[email-masked]>
Date: Fri, 14 Feb 2014 11:07:41 -0500

James,

> (With emphasis on /forcing/.)
 From an OE perspective, I see your point. Form a general security 
perspective,
I disagree. Folks receiving a signed message tend to assume that the "from"
field has been checked against the Subject or SAN in the signer's cert. It's
a reasonable expectation. When that reasonable assumption is not true, users
are surprised, and surprise is a bad outcome wrt security :-).

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 14 Feb 2014 11:17:16 -0800

> plural.  s/a certificate. This certificate assists/certificates.  These

Done.

> need to be distinct steps.

Nope, that's out of scope (and we have added a sentence to that effect). This document should *not* change, nor even repeat, the identity-binding rules for S/MIME.

> an EE certificate that is being associated.

It is *always* an EE cert that is being associated. It may not be an EE cert that was gotten through SMIMEA. I have added wording to that effect.

> is what we are doing here.  Being explicit would be helpful.

Yep.

> introduction if this is the case.

As this is the debate that has happened later in the WG, we have not added that to the new draft, but we expect to have to address this in a later draft. It is a WG-wide issue, not related just to SMIMEA. I have added a placeholder in the introduction for this topic.

I'll post the new draft after PaulW posts his with the new hash-of-LHS text.

--Paul Hoffman