Subject: [keyassure] signalling use of crypto as well as service keys

From: Tony Finch <[email-masked]>
Date: Thu, 19 Aug 2010 19:43:02 +0100

Phillip Hallam-Baker <hallam at gmail.com>
>
> At the moment the biggest holes in smime and ssl are
>
> * there is no way to know if the web site uses ssl
> * there is no way to know if the recipient can accept smime
> * there is no way to find an smime recipient cert that is widely supported
>
> All of these stem from the fact that x.509 certs are not properly
> integrated into dns. And those are the areas where I see big potential
> for creating a unique value for dnssec.

Yes.

This is a particular problem for SMTP. There is no certificate
verification in inter-domain SMTP+TLS, so the crypto doesn't provide much
benefit.

The cause of the problem was that it was never specified what the TLS
certificate identifies in SMTP: hostname? mail domain? and at the time
there was no way to signal to a mail server what certificate the client
expected. As a result mail server certificates are never validated so most
of them present certificates that cannot be validated since any old cert
will work.

The only way to fix this is to clearly specify how authentication must
work, and add some kind of signal so the server can indicate that it
supports this spec and so clients should be able to authenticate it.

One of the key differences between the web and SMTP is the extra
indirection in MX records. SRV records have the same property. This is a
great boon for virtual hosting - it's so normal for a mail server to host
multiple mail domains that it isn't even called virtual hosting. It's also
normal for a mail domain's DNS, primary, and backup MXs to be hosted by
three or more different organizations.

If the DNS associates keys directly with a mail domain [1] then there's a
coupling problem between the DNS host and the application host: an app key
rollover will require updating hundreds of domains which may be hosted by
many third parties. If the DNS associates keys with host names (i.e. the
targets of MX records) then we have to think very carefully about the
security properties of that indirection, since normally we want to
directly secure the identity that the user sees.

Perhaps the policy RR should be associated with the mail domain, but the
app key RR should be associated with the host name. This also deals with
the problem of backup MX keys.

[1] I'm being concrete for simplicity but you can replace "mail domain"
with your favourite application identity.

Nicholas Weaver has also been talking about the next layer of indirection,
associating keys with IP addresses. I'm doubtful that this would be useful
since it is even further from securing the identity that the user sees,
and it does not have obvious vhosting benefits.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
SOUTHEAST ICELAND: NORTHEASTERLY 6 TO GALE 8. ROUGH OR VERY ROUGH. RAIN. GOOD,
OCCASIONALLY POOR.

---

From: "Richard L. Barnes" <[email-masked]>
Date: Thu, 19 Aug 2010 14:58:55 -0400

These are not DNS problems or TLS problems, hence out of scope for  
this group.

>> * there is no way to know if the web site uses ssl

This is being discussed in the HASMAT group.  See, for example:
<http://tools.ietf.org/html/draft-hodges-strict-transport-sec>

>> * there is no way to find an smime recipient cert that is widely  

DNS is not the proper mechanism for distributing information of this  
character, since it's bound to email addresses, not domain names.

> supports this spec and so clients should be able to authenticate it.

The fact that SMTP has a poorly specified security mechanism is not  
something for this group.  That would be an APPAREA group that would  
update the SMTP specs to do proper server identity checking.

> directly secure the identity that the user sees.

The underlying problem here is that MX records aren't authenticated.   
If they are, then you just do the same thing as with the web and  
authenticate against the server's host name; if not, then you have to  
authenticate against the mail domain.  This is exactly the problem  
discussed in these drafts...
<http://tools.ietf.org/html/draft-ietf-xmpp-dna>
<http://tools.ietf.org/html/draft-barnes-hard-problem>
... and it goes away if you have DNSSEC.  So it's really not germane  
here, where we're starting with the assumption of DNSSEC.

> and it does not have obvious vhosting benefits.

On this at least we agree :)