ietf
[Top] [All Lists]

Re: UTA: Server certificate management (Re: Last Call: <draft-ietf-uta-email-tls-certs-05.txt>)

2015-12-02 06:17:15
On 02/12/2015 12:06, Harald Alvestrand wrote:
Den 01. des. 2015 18:37, skrev Viktor Dukhovni:
On Tue, Dec 01, 2015 at 03:34:32PM +0100, Harald Alvestrand wrote:

If I understand this draft correctly, I object.

It says:


    2.  When using email service discovery procedure specified in
        [RFC6186] the client MUST also use the right hand side of the
        email address as another "reference identifier" to compare
        against SRV-ID identifier in the server certificate.
The key word in that text is "another".  This does not require the
server to have a certificate that matches this identifier, provided
there is some other some suitable identifier.  It provides additional
flexibility, not a constraint.

NOTE HOWEVER, that use of the server name from the SRV record as
a DNS-ID reference identifier offers no security at all absent
DNSSEC.  So "another" might become "only" in that case.  The 6186
approach to address lack of trustworthy identifiers basically boils
down to "ask the user".  Once the user confirms the SRV record it
becomes pinned, and the server name becomes one of the reference
identifiers.
Which server name? I couldn't tell from this draft either which would be
presented or which would be stored (I assume you'd want them to be the
same).

Actually this highlights another problem: The draft claims to replace
section 2.4 of RFC 2591, "Server identity check", but fails to provide
replacement text for a crucial part of that document:

"If the match fails, the client SHOULD either ask for explicit user
    confirmation, or terminate the connection and indicate the server's
    identity is suspect."

This document doesn't say anything about what should happen once the
match is finished.
It does by reference, see RFC 6125.
My question upthread was whether this draft continues that legacy,
or departs from it.

HOWEVER:

If I understand RFC 6186 correctly, a (possibly large scale) IMAP email
service provider that wishes to serve a new domain "example org"
according to RFC 6186 must do two things:
I am not aware of any adoption of RFC 6186.  Are there are any MUAs
actually doing RFC 6186 SRV lookups?  If there are none, is it worth
debating?
The draft claims to have a normative dependency on RFC 6186. If the use
of RFC 6186 is not worth debating, the reference is worth deleting.
There are some uses of RFC 6186. How widespread? I don't know.

<Prev in Thread] Current Thread [Next in Thread>