Subject: [dane] Review draft-hoffman-dane-smime-04.txt

From: "Jim Schaad" <[email-masked]>
Date: Tue, 11 Sep 2012 17:04:36 -0700

1.  Based on the set of email messages I think that the introduction needs
some expansion. My previous question on the scope of the problem had to do
with the first sentence of the introduction as this implies that
certificates coming with messages are the main point of this document.   I
will try and address this in a separate message.

2.  In order to deal with issues that are present for S/MIME and not for
TLS, I believe that a new conjunction items is required to be added to the
Certificate Usage field that says a) this is the EE certificate to be used
and b) this is the trust anchor to be used.

3.  If the certificate lookup problem is to be solved, then it needs to be
made clear that the full certificate selector is going to be the common one
for the EE certificate of an S/MIME recipient for encryption, but it may not
be for an S/MIME sender that is signing.  

4.  I think a new security consideration needs to be placed in for dealing
with certificate revocation.  In the TLS case if a server knows that a
certificate has been revoked, it can just not present it and the only
problem will be that the client cannot validate the certificate until the
TTL has expired.  This is not the case for encryption certificates for
recipients of S/MIME messages.  It is highly probable that the recipient
will still want the sender to do a revocation check as that might be faster
than the TTL expiration.  In this case the sender will be unable to get a
valid certificate and must defer sending.  If this is not the case then a
certificate which has been revoked by the CA might still be used by an RP
because it is valid in the DNS.  At a minimum this is a discussion that is
needed for setting TTL times on these records.

5.  I think a new security consideration needs to be placed in for dealing
with the fact that the DNS authority might not be authorative for any
information in the association.  As presented elsewhere, consider the case
where I put up a CA for my enterprise, but decide to all the use of Gmail
accounts for some employees.  This means that I now need to have Google
publish into its DNS the EE and trust root certificates for my employees
that are using the Gmail accounts.  Google however does not control any of
the security properties of the CA that is being used to issues and maintain
the certificates involved.  This different from the usual TLS case where the
DNS provider and the service provider have a tight association.  Even in the
case where things are outsourced there is a contractual relationship between
the DNS provider and the service provider.  This is not the case for the
email world.

6.  It might be worthwhile to consider allowing for publication of trust
anchor records (only type 2) at the _smimecert level for those cases where a
small number of trust anchors should be used for all of the recipients for a
domain.  This does not solve the EE certificate look up problem, but does
make a simpler way to advertise the TA for a domain without allowing trolls
to find all of the email addresses associated with a domain.

7.  This document does not refer to the registries created in 7.2, 7.3 and
7.4 of the DANE TLSA document.  This means it is not clear that if a
document defines a new TLSA certificate usage, that it would or would not
apply to the SMIMEA record.  A this time I would assume that it would not.

8.  As mentioned elsewhere, the problem of looking up certificates in the
presence of mail servers that are willing to do collapse of local parts
needs to be addressed.  The problem needs to be described, but a solution
does not need to be stated as this is highly dependent on how the collapse
is going to be done.

Jim

---

From: Carl Wallace <[email-masked]>
Date: Tue, 11 Sep 2012 20:29:20 -0400

On 9/11/12 8:04 PM, "Jim Schaad" <[email-masked]> wrote:
><snip>

Why the trust anchor?  It's far more common (in my experience) to have to
install a trust anchor to exchange email with someone than to interact
with a web server.  It's also common for the trust anchor considered by
the sender to vary from the trust anchor used by the verifier.  A CA
constraint should work well here.

>be for an S/MIME sender that is signing.

Certificate lookup for encryption seems like something that might be
better solved using a certificate transparency log.

<snip>

---

From: "Jim Schaad" <[email-masked]>
Date: Tue, 11 Sep 2012 19:54:52 -0700

> -----Original Message-----
> From: Carl Wallace [mailto:[email-masked]]
> Sent: Tuesday, September 11, 2012 5:29 PM
> To: Jim Schaad; 'IETF DANE WG list'
> Subject: Re: [dane] Review draft-hoffman-dane-smime-04.txt
> 
> >2.  In order to deal with issues that are present for S/MIME and not
> >for TLS, I believe that a new conjunction items is required to be added
> >to the Certificate Usage field that says a) this is the EE certificate
> >to be used and b) this is the trust anchor to be used.
> 
with a
> web server.  It's also common for the trust anchor considered by the
sender
> to vary from the trust anchor used by the verifier.  A CA constraint
should
> work well here.

You are quite right that a CA constraint would also work here as well.
However part of the effort is to reduce the need to install the trust anchor
as is currently required today.  I would agree that that one would be able
to say a) this EE cert and b) through this CA as well.  I would argue that
we want to create the AND statement that I argued for back in the days of
DANE base spec but nobody else thought was needed.

> 
> >3.  If the certificate lookup problem is to be solved, then it needs to
> >be made clear that the full certificate selector is going to be the
> >common one for the EE certificate of an S/MIME recipient for
> >encryption, but it may not be for an S/MIME sender that is signing.
> 
better
> solved using a certificate transparency log.

It will be interesting to see if this really amounts to anything, but the
authors have said that this is one goal of the current work.

Jim