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

[Alessandro Vesely <[e-mail]>]

Alexey Melnikov wrote:
> Cyrus Daboo wrote:
>>> I'm not sure we have a good practical solution to this problem. 
>>> today. RFC 4985 (SRVName SAN) could be used in theory to compartmentalize 
>>> certificates to specific services at a domain name. But I'm not 
>>> sure any commercial CAs today will issue certs with such extensions.
>>
>> Right. This was why I suggested using the SRV query string in the 
>> subjectAltName, i.e. '_imap._tcp.example.com'. That way a client that 
>> gets to that cert via an SRV lookup can verify that it is valid, 
>> whilst other clients will effectively ignore that, and the cert can't 
>> "impersonate" another service.
>
> If you are going to do that, you need to update IMAP and POP3 specs 
> properly, i.e. to define TLS server identity verification procedure for 
> these protocols that requires that clients check srvName.

Will the spec be flexible about that? I mean, checking them only if 
they are present?

To recap, say mail.example.com hosts mail services for example.org and 
example.net. Assume its certificate may have SAN fields for any of the 
following:

* otherName dNSName mail.example.com
* iPAddress 192.0.2.3
* otherName srvName _imap.example.org
* otherName srvName _imap.example.net
* rfc822Name [e-mail]
* rfc822Name [e-mail]

The question is whether a suitable tradeoff among interoperability, 
compartmentalization, and other security issues may be obtained by 
tailoring those SAN fields, even without Server Name Indication. To 
complete the example, also assume the following RRs are set, and 
obtainable by regular DNS over UDP queries.

mail.example.com IN A 192.0.2.3
mail.example.net IN A 192.0.2.3
3.2.0.192.in-addr.arpa IN CNAME 3.0-24.2.0.192.in-addr.arpa
0-24.2.0.192.in-addr.arpa IN NS ns.example.com
3.0-24.2.0.192.in-addr.arpa IN PTR mail.example.com
3.0-24.2.0.192.in-addr.arpa IN PTR mail.example.net

_imap._tcp.example.org IN SRV 0 0 143 mail.example.com
_imap._tcp.example.net IN SRV 0 0 143 mail.example.net

example.com IN MX 0 mail.example.com
example.org IN MX 0 mail.example.com
example.net IN MX 0 mail.example.com

Note that example.org is served by an host in a different domain zone. 
However, as far as DNS queries can be trusted, the client can check 
that example.com is compatible with example.org (because they share a 
primary MX.) If [e-mail] is included in the certificate, 
the client may trust that the signing CA had verified who got mail for 
it, and consider that as corroborating the value of the SRV RR. Am I 
missing something?

IMHO, any MUST/MUST NOT in the spec should only prevent cases where 
phishing can actually be operated, so as not to standardize ill 
defined practices. I would suggest that the spec exemplifies, in an 
appendix, various cases of DNS and certificate settings, telling in 
what cases the client should trust the info, ask confirmation, or 
strongly discourage the user. The spec may also suggest that (in some 
cases) challenge/response authentication takes place even if the 
channel is crypted, to avoid phishing.