Re: Additional reviews of draft-daboo-srv-email-02.txt needed

[Shumon Huque <[e-mail]>]

On Mon, Aug 24, 2009 at 01:33:07PM -0500, Vijay K. Gurbani wrote:
> Shumon Huque wrote:
> >Quite true, although an important question is how the domain part
> >is advertised in the certificate. Most likely it will be put in
> >the the common name or the subjectaltname's DNSname field. But
> >in many cases that poses a security problem, if other services
> >unrelated to IMAP (or POP3 and submission) are also hosted at
> >the domain part. If we issue an "example.com" certificate to the
> >IMAP service, it could use that to impersonate any TLS service at
> >that domain unrelated to IMAP (eg. jabber, https, etc).
> 
> That is quite true (though I am not sure whether it is
> "impersonation", per se; after all, it is a signed and issued
> certificate.)

Well, it may have been signed and issued correctly. But since the 
embedded identity wasn't specified with sufficient granularity, it 
could be used for purposes other than intended. And this leads to
the impersonation threat.

In a large enough organization, different services at the same
domain name may be operated by different folks, on different
systems, with different security requirements. You normally
don't want the operator of one of those services being able
to impersonate the identity of another. Either deliberately,
or because it got compromised by an attacker.

> >I'm not sure we have a good practical solution to this problem.
> 
> The notion of tying an identity in the certificate to a specific
> use is reasonable, I think.  The way we did this in our SIP
> work was to have a SIP-specific extended key usage (EKU) -- see
> http://tools.ietf.org/html/draft-ietf-sip-eku-05.
> 
> However, EKUs have their own set of emotional baggage,
> including the fact that existing certificates will not have
> the specific extension specified.

Yeah, that's an interesting way to address this. But I think
it has an even bigger deployment problem than RFC 4985. You'd
need to define a new EKU for each new service. With RFC 4985,
one general purpose spec could potentially be used for all
services that use DNS SRV records.

--Shumon.