Subject: [Uta] Call for draft-ietf-uta-email-tls-certs-01 reviews

From: Leif Johansson <[email-masked]>
Date: Thu, 19 Mar 2015 12:06:13 +0100

Folks,

We need to get this document out the door! Getting a few reviews would
help a great deal!

	Cheers Leif

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 21 Mar 2015 07:38:25 +0000

> We need to get this document out the door! Getting a few reviews would

Overall the document is in good shape.

    In section 3 a sentence is truncated:

       3.  URI-ID identifier type (subjectAltName of
	   uniformResourceIdentifier type [RFC5280]) MUST NOT be used by
	   clients for server verification, as

Below is a proposal to expand the scope to cover use of email
certificates (still other than MTA-to-MTA) with DANE.

Since the DANE SRV draft is almost ready for IETF LC, I think it is
reasonable to also discuss the use-case for DNSSEC/DANE validated
indirection:

	_imaps._tcp.example.com. IN SRV 0 0 993 mail.example.com.
	_993._tcp.mail.example.com. IN TLSA 3 1 1 <ee-digest>
	_993._tcp.mail.example.com. IN TLSA 2 0 1 <ta-digest>

	https://tools.ietf.org/html/draft-ietf-dane-srv-11

When an IMAP or submission client locates the service endpoint via
SRV records (as described in RFC 6186), and said clients supports
DNSSEC and DANE, an alternative to the use of SRV-ID reference
identifiers at the service domain is to use DNSSEC to authenticate
the redirection and DANE to authenticate the certificate of the
target host.  

When the DANE usage is not DANE-EE(3) (which ignores any names in
the certificate) the domain part of the reference identifier in
that case would be as described in the DANE SRV draft.  This could
be with or without the corresponding service prefix.

Such servers would then be authenticated via any of:

    * Standard PKIX CA validation with name checks per this
      draft.

    * A DANE-EE(3) match of the certificate or key blob with
      TLSA base domains per the SRV draft.

    * Any other DANE usage with the same name checks as in
      the draft.

    * Any other DANE usage with the TLSA base domain rather
      than the service domain as the domain part of the reference
      identifier, with or without an _service prefix.

There is also a use-case for DANE without SRV indirection.  In
which case, the service domain is typically the TLSA base domain,
except as modified by DNSSEC-validated CNAME chasing with TLSA
records located at the end of the CNAME chain.

    https://tools.ietf.org/html/draft-ietf-dane-ops-07

See also

    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-7
    http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-15#section-3.1.3

that may relevant for clients that use DNS for service discovery
and potentially employ TLS "opportunistically" based on whether
TLS-capable services are located.  Such clients should probably
limit their DANE usages to DANE-TA(2) and DANE-EE(3).

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Mar 2015 15:10:52 +0000

> We need to get this document out the door! Getting a few reviews would
In the latest version I split the requirements into different sections 
talking about Mail User Agent implementors, Mail Service Providers and 
CAs. I found some bugs, so this was a useful exercise.
I also added another example of a single host where multiple services 
are running, when all of them are reusing the same server certificate.

Please review and comment, in particular about SHOULDs versa MUSTs. I 
can explain my motivation for different choices, but it would be good to 
discuss on the mailing list if any choices are not clear.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Mar 2015 15:12:31 +0000

> 	   clients for server verification, as
Thank you, I will fix. The rest of the sentence was commented out for 
some unknown to me reason.
  [snip]

---

From: Leif Johansson <[email-masked]>
Date: Sun, 22 Mar 2015 16:49:03 +0100

> discuss on the mailing list if any choices are not clear.

Sorry - did you cut a 02 yet or did you want addl reviews first? I'm all
for pushing this to WGLC during IETF week if we can rustle up (forgive
the pun) some warm bodies to do review-for-beer :-)

	Cheers Leif

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Mar 2015 15:54:23 +0000

> the pun) some warm bodies to do review-for-beer :-)
I have a version of -02 that fixes the unterminated sentence provlem 
spotted by Victor. But I think the published -01 is ready for WGLC.

---

From: Leif Johansson <[email-masked]>
Date: Sun, 22 Mar 2015 16:55:45 +0100

> spotted by Victor. But I think the published -01 is ready for WGLC.

Don't underestimate the value of a ping :-)

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 22 Mar 2015 19:37:51 +0000

On Sun, Mar 22, 2015 at 03:12:31PM +0000, Alexey Melnikov wrote:

> Thank you, I will fix. The rest of the sentence was commented out for some
> unknown to me reason.

I have a couple of questions about SRVNAME.

    1.  Which TLS libraries implement support for SRVNAME, beyond
	any generic support for generic "other name"?  In other
	words, is vefication of SRVNAME likely to be easily available
	to applications now, or will application developers have to
	wait for TLS library developers to add support for this?

	A quick look at OpenSSL shows no support for SRVNAME.

    2.  MTAs are sometimes configured to act as submission clients.
	Most frequently on single-user machines.  When should such
	an MTA use an SRVNAME reference identifier for the target
	SMTP server?  To clarify, a typical configuration might be:

		relayhost = [smtp.example.net]:587

	    or less frequently indirection via /etc/services:

		relayhost = [smtp.example.net]:submission

	thus in current practice often no explicit indication that
	the service is "submission" (could just be a private peering
	relay that happens to use port 587) and no explicit SRV
	lookup of "_submission".

	When should such an MTA choose to accept an SRVNAME of
	"_submission.smtp.example.com" in the peer's certificate?

	Would that only be applicable if new code is written to
	support SRV indirection?  Should use of "_submission"
	SRVNAMES be inferred from the target port?  Or enabled via
	per-destination configuration?

	[ I know that the document is not about MTA-to-MTA, but
	  I think the intention there is to exempt forward-path
	  port 25 relaying, and not necessarily "stub" MTAs that
	  try to emulate user agents. ]

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Mar 2015 20:11:35 +0000

Hi Victor,

> 	A quick look at OpenSSL shows no support for SRVNAME.
OpenSSL does or at least it is very easy to add it on top of OpenSSL. My 
co-workers at isode implemented that.

I am thinking about your question #2 now and will reply separately.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 22 Mar 2015 20:23:04 +0000

> co-workers at isode implemented that.

Well, there's generic support for "otherName".  But recent improvements
in OpenSSL (1.0.2 and later) strive enable applications to as much
as possibe delegate certificate peername verification to the library,
rather the hand-rolling their own (often incorrect) peername checks.

So I think that for SRVNAME verification to be practical, in addition
to CAs being willing to issue such certificates (don't know if any
are as yet), libraries should support matching them on behalf of
applications that signal the appropriate service name and domain
name and leave the rest to the library.

I'll probably be the one writing a bunch of that code for OpenSSL.

I'm curious whether this is already supported in (m)any other
libraries.

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Sun, 22 Mar 2015 20:34:56 +0000

Hi Victor,

On 22/03/2015 19:37, Viktor Dukhovni wrote:
> 	SRVNAMES be inferred from the target port?
No.
>          Or enabled via
I think direct host configuration must disable SRV lookups and checking 
for sRVName in certificates.

This is the same as manually configuring an IMAP server in an email 
client: sRVName don't apply.

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 22 Mar 2015 20:43:19 +0000

On Sun, Mar 22, 2015 at 08:34:56PM +0000, Alexey Melnikov wrote:

> >	Should use of "_submission"

OK.

> I think direct host configuration must disable SRV lookups and checking for
> sRVName in certificates.

> This is the same as manually configuring an IMAP server in an email client:
> sRVName don't apply.

So SRVNAME does not apply when using submission/imap/pop with a
statically configured hostname?  Why not?  Or in any case, it was
not 100% clear to me from the draft that SRVNAME was not intended
to apply.

[ One might suppose that SRVNAME certs being more specific and
provide better security, even when the hostname is fixed. ]

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Mar 2015 02:22:28 +0000

Hi Viktor,

> provide better security, even when the hostname is fixed. ]
I always thought of sRVName as implying DNS SRV lookup and RFC 4985 seem 
to support my interpretation. But you are right, dNSName doesn't provide 
necessary granularity if one wants to limit a certificate to a 
particular service.

I don't mind using sRVName in the way you describe, but I would like to 
hear other opinions on whether this is a good idea.
Another alternative is to allow for uniformResourceIdentifier for the 
purpose you describe (they are currently prohibited by the draft, but 
only because they are not used).

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 23 Mar 2015 04:29:01 +0000

On Mon, Mar 23, 2015 at 02:22:28AM +0000, Alexey Melnikov wrote:

> purpose you describe (they are currently prohibited by the draft, but only
> because they are not used).

I think I would avoid URI, too much unnecessary flexibility.
Other than the "authority", the rest of the URI is not meaningful
for submission/imap/pop once we know the service.

You're likely tracking the discussion of URI on kitten, there the
URI really does carry more information (protocol TCP vs UDP and
path information for KDC proxy via HTTP).

So I'm not keen on seeing an overly general solution here, unless
I'm missing what URI has to offer.

-- 
	Viktor.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 23 Mar 2015 18:32:54 +0000

[...]
> limit their DANE usages to DANE-TA(2) and DANE-EE(3).
I would like to be able to use DANE for verifying DNS SRVs, but the 
scope of this document is to try use existing primitives and not trying 
to tie this to DANE/DNSSEC deployments.
I would be happy to work later on an updated document that includes this 
though.

I would again ask other people to weight in on this.