Subject: [Uta] Eric Rescorla's Yes on draft-ietf-uta-email-deep-09: (with COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Oct 2017 10:59:15 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-uta-email-deep-09: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-uta-email-deep/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Line 15
   This specification outlines current recommendations for use of
   Transport Layer Security (TLS) to provide confidentiality of email
Nit: "the use"

Line 103
   not use it in a way that maximizes end-user confidentiality.  This
   specification describes current recommendations for use of TLS in
   interactions between Mail User Agents and Mail Access Services, and
Nit: "the use"

Line 186
   TLS, and to encourage a greater consistency for how TLS is used, this
   specification now recommends use of Implicit TLS for POP, IMAP, SMTP
   Submission, and all other protocols used between a Mail User Agent
Do you want to say RECOMMENDED?

Line 199
   greeting, the server and client MUST enter AUTHORIZATION state, even
   if client credentials were supplied during the TLS handshake.
You mean TLS client certificates here, right? Maybe say so

Line 214
   remainder of the TCP connection.  If client credentials were provided
   during the TLS handshake that the server finds acceptable, the server
   MAY issue a PREAUTH greeting in which case both the server and client
Same comment above about client credentials == certs.

Line 304
      preference to services supporting STARTTLS (if offered).  (See
      also Section 4.5.)
I note that 6186 is kind of unclear on what should go in SNI. It obviously
needs to be what you are checking against (which 6186 gets right) but maybe
it's worth clarifying in this document somewhere.

Line 328
      the TLS ciphersuite of the session in which the mail was received,
      in the Received field of the outgoing message.  (See Section 4.3.)
Do you want to also suggest that it include the name of the DH group, if any?

Line 363
   refuse a ClientHello message from any client sending a protocol
   version number corresponding to any version of SSL or TLS 1.0.
   Another way is for the server to accept ClientHello messages from
It's worth being very clear that you mean ClientHello.version, not the record
version, as this has created a lot of interop problems.

Line 405
   implementation does not know the name of the cipher suite (a
   situation that should be remedied promptly), a four-digit hexadecimal
   cipher suite identifier MAY be used.  The ABNF for the field follows:
Hard to see how you could realistically get into this state...

Line 518
      [RFC7525], TLS 1.1 (or earlier) SHOULD NOT be used unless no
      higher version is available during TLS protocol negotiation.
This text doesn't quite seem right, as the client has no idea what the server
supports, it just knows what it negotiated. Can you explain how this would be
implemented?

Line 594
   accounts SHOULD be at least use of TLS version 1.1 or greater, and
   successful validation of the server's certificate.  (Future revisions
   to this specification may raise these requirements or impose
This second requirement is more important.

Line 672
   the such confidentiality is provided.  Additional advice on
   certificate pinning is present in [RFC6125].
Wow, we have a terrible name clash here, because we also have HPKP which
everyone calls "pinning". I see 6125 calls it that, so maybe on first use (S
5.3) can you please differentiate from HPKP

Line 679
   TLS handshake unless the server requests one and the client has
   determined the certificate can be safely used with that specific
   server, OR the client has been explicitly configured by the user to
Can you note that this is just a restatement of the rules in TLS?

Line 681
   server, OR the client has been explicitly configured by the user to
   use that particular certificate with that server.  How to make this
   determination is presently implementation specific.
The structure of this text is confusing. The rule is:

if (server asked &&
    (client determined safe || certificate configured)) {
    can use
} else {
    can't use
}

Line 781
   or interception; this is not intended to mitigate active attackers
   who have compromised service provider systems.
IMPORTANT: Client auth with TLS 1.2 reveals the user's identity. This is a
privacy issue, and so we need to note it. The options here are not great with <
1.3 because renegotiation is also bad, so I'm not suggesting a normative
change, but I think the doc needs to be clear.

Line 959
   in RFC 6186 resolves that critique for email.  The second bullet is
   correct as well, but not very important because useful deployment of
   security layers other than TLS in email is small enough to be
The second bullet is less correct than it used to be because we no longer
support export suites. Ordinarily I wouldn't bother to make this point, but if
we're revisiting this point by point, I think we should note that.

---

From: Keith Moore <[email-masked]>
Date: Tue, 24 Oct 2017 20:31:41 -0400

(inline)

> Do you want to say RECOMMENDED?

Lower case "recommends" (non-2119 meaning) was intentional, though my 
reasoning may be unclear:  One of the first things I learned while 
studying engineering was to not specify the same thing in two different 
ways, because subtle differences between the two could create 
ambiguity.   (I remember this point clearly because about a year before, 
someone had constructed a beautiful piece of cabinetry to my 
specifications, which completely did not fit into the intended space 
because I had made this very error.)

So when writing technical specifications, I believe there should be a 
clear distinction between summary text (which glosses over details), and 
the text that actually defines the requirements of the specification.   
Admittedly this could be called out more explicitly, though it doesn't 
seem conventional for IETF RFCs to do so.

> You mean TLS client certificates here, right? Maybe say so

agreed; fixed in -10.
> Same comment above about client credentials == certs.
also fixed in -10.

> it's worth clarifying in this document somewhere.
Hmm.    I might need to come back to that one.   Lots of layers to sift 
through.  Feel free to suggest text.

> Do you want to also suggest that it include the name of the DH group, if any?

I've attempted to add that attribute but please check the text:

       The ESMTPS transmission type <xref target="RFC3848"/> provides trace
       information that can indicate TLS was used when transferring mail.
       However, TLS usage by itself is not a guarantee of confidentiality or
       security. The TLS cipher suite provides additional information 
about the
       level of security made available for a connection. This defines a new
       SMTP "tls" Received header additional-registered-clause that is 
used to
       record the TLS cipher suite that was negotiated for the 
connection. The
       value included in this additional clause SHOULD be the registered 
cipher
       suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) included 
in the TLS
       cipher suite registry. In the event the implementation does not 
know the
       name of the cipher suite (a situation that should be remedied 
promptly),
       a four-digit hexadecimal cipher suite identifier MAY be used.
       In addition, the Diffie-Hellman group name associated with the
       ciphersuite MAY be included (when applicable and known) following the
       ciphersuite name.   The ABNF for the field follows:
       <figure>
         <artwork type="abnf">
tls-cipher-clause  =  CFWS "tls" FWS tls-cipher [ "group" dh-group ]

tls-cipher         =  tls-cipher-name / tls-cipher-hex

tls-cipher-name    =  ALPHA *(ALPHA / DIGIT / "_")
; as registered in IANA cipher suite registry

tls-cipher-hex     =  "0x" 4HEXDIG

dh-group           = ALPHA *(ALPHA / DIGIT / "_")
; as registered in IANA TLS Supported Groups Registry
</artwork>
       </figure>
> version, as this has created a lot of interop problems.

ok
> Hard to see how you could realistically get into this state...
Chris wrote this so this is just a guess on my part:   I'm assuming 
there are TLS APIs out there that let the caller query which ciphersuite 
is being used, but the implementation returns an integer rather than the 
name, and provides no convenience routine to look up the name text.

> supports, it just knows what it negotiated. Can you explain how this would be

No, I can't explain it either.  The client can specify that it can 
handle TLS version 1.2 or greater, and the server is supposed to return 
the highest TLS version that it supports that is <= the TLS version 
specified by the client.  But the client has no way to force the server 
to negotiate the highest TLS version that it supports.  The only options 
the client has are things like abort the connection, and perhaps to try 
again under different circumstances. Or maybe the client could abort the 
connection if it knows (by some unspecified mechanism) that the server 
really does support a higher version.   So I think that the 
corresponding text from RFC 7525 doesn't really apply to a client.

Since I don't know what else to suggest here, I'll comment out that 
sentence.

> This second requirement is more important.

Agree, or at least I think I do (are MiTM attacks taking advantage of no 
or weak cert validation really more of a threat than attacks on TLS < 
1.1 protocol or ciphersuites?  yeah, I could see that.).  But I 
certainly want implementors to pay more attention to cert validation.

I'm not sure what change to the text you had in mind, but I reversed the 
order to put cert validation first.

> 5.3) can you please differentiate from HPKP

added a note about this.
> Can you note that this is just a restatement of the rules in TLS?

I attempted to fix this as well as the next item, though it's possible 
I'm still missing something:

     MUAs MAY implement client certificate authentication on the
     Implicit TLS port.  An MUA MUST NOT provide a client certificate
     during the TLS handshake unless the server requests one AND at
     least one of the following is true: the client has determined the
     certificate can be safely used with that specific server, OR the
     client has been explicitly configured by the user to use that
     particular certificate with that server. How to make this
     determination is presently implementation specific. (The
     requirement that the server request a certificate is just a
     restatement of the TLS protocol rules, e.g.
     <xref target="RFC5246"/> section 7.4.6.  The requirement that the 
client
     not send a certificate not known to be acceptable to the server is
     pragmatic in multiple ways: the current TLS protocol provides no 
way for
     the client to know which of potentially multiple certificates it
     should use; also, when the client sends a certificate it is
     potentially disclosing its identity (or its user's identity) to
     the server - perhaps unnecessarily and for no useful purpose.
>      (client determined safe || certificate configured)) {

reworded text in -10 to try to make this clearer.

> change, but I think the doc needs to be clear.

Added a paragraph:

Implementors should be aware that use of client certificates with TLS
1.2 likely reveals the user's identity to the server and therefore may
compromise the user's privacy.  There seems to be no easy fix other
than to avoid presenting client certificates except when specifically
configured to do so.
> we're revisiting this point by point, I think we should note that.

added a note for this.

Keith

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 25 Oct 2017 14:33:24 +0100

Hi Keith,

One little thing about your new ABNF for DH group:

On 25/10/2017 01:31, Keith Moore wrote:

>       value included in this additional clause SHOULD be the 
> registered cipher
>       suite name (e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) 
> included in the TLS

Is lack of some kind of delimiter before and after "group" intentional? 
(FWS? Or maybe ";" before group).

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Oct 2017 15:29:21 -0700

On Tue, Oct 24, 2017 at 5:31 PM, Keith Moore <[email-masked]>
wrote:

> reasoning may be unclear:  One of the first things I learned while studying
> engineering was to not specify the same thing in two different ways,
> because subtle differences between the two could create ambiguity.   (I
> remember this point clearly because about a year before, someone had
> constructed a beautiful piece of cabinetry to my specifications, which
> completely did not fit into the intended space because I had made this very
> error.)
>
> Admittedly this could be called out more explicitly, though it doesn't seem
> conventional for IETF RFCs to do so.

OK, this was just a note.

>       security. The TLS cipher suite provides additional information about
> the
>       SMTP "tls" Received header additional-registered-clause that is used
> to
>       record the TLS cipher suite that was negotiated for the connection.
> The
>       cipher suite registry. In the event the implementation does not know
> the

I might want to include hyphen here because "P-256"

> Chris wrote this so this is just a guess on my part:   I'm assuming there
> are TLS APIs out there that let the caller query which ciphersuite is being
> used, but the implementation returns an integer rather than the name, and
> provides no convenience routine to look up the name text.

OK. Chris?

Line 594
> or weak cert validation really more of a threat than attacks on TLS < 1.1
> protocol or ciphersuites?  yeah, I could see that.).

No, they're not.

> But I certainly want implementors to pay more attention to cert validation.
>

I think that success validation needs to be a MUST.

added a note about this.
> I attempted to fix this as well as the next item, though it's possible I'm
> still missing something:
>
>     pragmatic in multiple ways: the current TLS protocol provides no way
> for

This is fine.

Line 681
> than to avoid presenting client certificates except when specifically

The issue here is that it exposes it not to the  server (though it does)
but to anyone on the
wire. This is actually better with TLS 1.3.

-Ekr

Line 959

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Oct 2017 18:48:49 -0400

> I might want to include hyphen here because "P-256"

done.
>     Chris wrote this so this is just a guess on my part:   I'm
>     assuming there are TLS APIs out there that let the caller query
>     which ciphersuite is being used, but the implementation returns an
>     integer rather than the name, and provides no convenience routine
>     to look up the name text.
>
>
> OK. Chris?
>
>
>
>         Line 594
>     Agree, or at least I think I do (are MiTM attacks taking advantage
>     of no or weak cert validation really more of a threat than attacks
>     on TLS < 1.1 protocol or ciphersuites?  yeah, I could see that.). 
>
>
> No, they're not.
>
>     I'm not sure what change to the text you had in mind, but I
>     reversed the order to put cert validation first.
>
>

Ah, now I understand.  Changed to MUST validate + SHOULD TLS >= 1.1.

> The issue here is that it exposes it not to the  server (though it 
> does) but to anyone on the

ok, clarified the paragraph that I wrote.

Keith

---

From: "Chris Newman" <[email-masked]>
Date: Thu, 26 Oct 2017 16:18:14 -0700

On 24 Oct 2017, at 17:31, Keith Moore wrote:

> studying engineering was to not specify the same thing in two 
> different ways, because subtle differences between the two could 
> create ambiguity.   (I remember this point clearly because about a 
> year before, someone had constructed a beautiful piece of cabinetry to 
> my specifications, which completely did not fit into the intended 
> space because I had made this very error.)
>
> clear distinction between summary text (which glosses over details), 
> and the text that actually defines the requirements of the 
> specification.   Admittedly this could be called out more 
> explicitly, though it doesn't seem conventional for IETF RFCs to do 
> so.
>
>> Line 199
> Hmm.    I might need to come back to that one.   Lots of layers to 
> sift through.  Feel free to suggest text.

I believe RFC 7817 handles this issue sufficiently.

>       security. The TLS cipher suite provides additional 
> information about the
>       SMTP "tls" Received header additional-registered-clause 
> that is used to
>       cipher suite registry. In the event the implementation does 
> not know the
>       name of the cipher suite (a situation that should be 
> remedied promptly),
> there are TLS APIs out there that let the caller query which 
> ciphersuite is being used, but the implementation returns an integer 
> rather than the name, and provides no convenience routine to look up 
> the name text.

That was deliberate. I've seen too many libraries that botch number to 
name lookup, so I wanted to err on the side of including precise and 
correct information over information in the preferred form.

> handle TLS version 1.2 or greater, and the server is supposed to 
> return the highest TLS version that it supports that is <= the TLS 
> version specified by the client.  But the client has no way to force 
> the server to negotiate the highest TLS version that it supports.  
> The only options the client has are things like abort the connection, 
> and perhaps to try again under different circumstances. Or maybe the 
> client could abort the connection if it knows (by some unspecified 
> mechanism) that the server really does support a higher version.   
> So I think that the corresponding text from RFC 7525 doesn't really 
> apply to a client.
>

Yeah, there's no way for the client to determine a higher version of TLS 
should be used after the WG leadership insisted we remove the STS-like 
functionality from this document; so this text has to go.

> Agree, or at least I think I do (are MiTM attacks taking advantage of 
> no or weak cert validation really more of a threat than attacks on TLS 
> < 1.1 protocol or ciphersuites?  yeah, I could see that.).  But I 
> I'm not sure what change to the text you had in mind, but I reversed 
> the order to put cert validation first.
>
>> Line 672
>     <xref target="RFC5246"/> section 7.4.6.  The requirement that 
> the client
>     pragmatic in multiple ways: the current TLS protocol provides 
> no way for

I don't view statements of fact as normative changes to a protocol :-). 
However, given the adjusted wording I suggested for the client 
certificate text based on another IESG comment, I'd tweak this proposed 
text to say "avoiding presenting client certificates unless explicit 
authorization to do so is present." I'd also have no objection to an 
informative reference to the TLS 1.3 draft as a likely future option to 
address the concern.

		- Chris

---

From: Keith Moore <[email-masked]>
Date: Thu, 26 Oct 2017 22:56:38 -0400

> I believe RFC 7817 handles this issue sufficiently. 

Not sure whether EKR was referring specifically to the use of SNI with 
SRV records or not, but that's what I had assumed he meant.  So far I 
haven't found any specific advice for (a) what name the MUA should 
specify in SNI, or (b) what names the server should recognize and have 
certificates for.   It's pretty clear that the server needs to have a 
certificate for the name on the right hand side of the SRV record, but 
should it also have a certificate for the name on the left hand side?  
(e.g. _pop3s._tcp.example.com?)  That would potentially make SRV 
discovery more secure.

But I think that's well beyond what the WG (and IESG) approved.   So I 
guess I'm inclined to leave the -10 text as it is now without 
specifically addressing this issue.

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 04:48:17 -0700

On Thu, Oct 26, 2017 at 7:56 PM, Keith Moore <[email-masked]>
wrote:

> Not sure whether EKR was referring specifically to the use of SNI with SRV
> records or not, but that's what I had assumed he meant.  So far I haven't
> found any specific advice for (a) what name the MUA should specify in SNI,
> or (b) what names the server should recognize and have certificates for.
> It's pretty clear that the server needs to have a certificate for the name
> on the right hand side of the SRV record, but should it also have a
> certificate for the name on the left hand side?  (e.g. _pop3s._
> tcp.example.com?)  That would potentially make SRV discovery more
> secure.
>

The entire principle here is that (absent DNSSEC) TLS operates on what was
fed into the client.

> guess I'm inclined to leave the -10 text as it is now without specifically
> addressing this issue.
>

Hmm..... No, I don't think that that's good. IESG approval or not, this
text needs to be clear and safe....

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Fri, 27 Oct 2017 10:16:24 -0400

> On Oct 27, 2017, at 7:48 AM, Eric Rescorla <[email-masked]> wrote:
> 
> The entire principle here is that (absent DNSSEC) TLS operates on what was fed into the client.

Could you elaborate a bit?  I feel like I'm missing some context.  

Thanks,

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 07:21:19 -0700

Perhaps it would be useful if Chris could walk through the example he gave
in more detail.

My point is that if the client is configured to connect to "pop.example.com"
that has to be in the
certificate, regardless of how many SRV records there are.
-Ekr

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 27 Oct 2017 11:03:24 -0700

On 26 Oct 2017, at 19:56, Keith Moore wrote:
>>> Hmm.    I might need to come back to that one.   Lots of layers 
>>> to sift through.  Feel free to suggest text.
>>
> certificates for.   It's pretty clear that the server needs to have 
> a certificate for the name on the right hand side of the SRV record, 
> but should it also have a certificate for the name on the left hand 
> side?  (e.g. _pop3s._tcp.example.com?)  That would potentially make 
> SRV discovery more secure.
>
> But I think that's well beyond what the WG (and IESG) approved.   So 
> I guess I'm inclined to leave the -10 text as it is now without 

I just re-read the related text a bit more carefully. Although RFC 7817 
adequately covers what subjectAltName identities mail servers need to 
support in certificates, it doesn't cover what goes in SNI (although it 
mentions SNI). Ditto for RFC 6186. This is annoying; the issue really 
should have been addressed in 7817 or 6125 :-(

I suspect in practice that most MUAs use the post-SRV-lookup hostname in 
TLS SNI. And server support for that name form in SNI will be necessary 
to interoperate with MUAs that don't support RFC 6186 (or use an 
alternative autodiscovery mechanism in preference to RFC 6186). So the 
remaining question is would it be useful/helpful for a server to also 
support an SNI based on the SRV record or SRV-ID name? I don't think the 
answer to that question is important enough to justify a normative 
change to this document.

To address this, I suggest we add a sentence to the end of section 4.4 
(just before the sentence referencing 7817):

--
Mail servers supporting SNI need to support the post-SRV hostname to 
interoperate with MUAs that have not implemented RFC 6186.
--

I view that as a statement of fact rather than a normative change so I 
think it's kosher. Saying more on the topic would probably cross the 
normative change line so I'd prefer not to go there.

		- Chris

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Oct 2017 14:21:00 -0400

> On Oct 27, 2017, at 2:03 PM, Chris Newman <[email-masked]> wrote:
> 
> I just re-read the related text a bit more carefully. Although RFC 7817 adequately covers what subjectAltName identities mail servers need to support in certificates, it doesn't cover what goes in SNI (although it mentions SNI). Ditto for RFC 6186. This is annoying; the issue really should have been addressed in 7817 or 6125 :-(

My take is that use of SRV-ID will see negligible or no adoption, and so
despite https://tools.ietf.org/html/rfc7817#section-5.1 there is no
likely value in sending anything other than the target hostname in SNI.
Validation of the SRV record via the WebPKI rather than DNSSEC is
from this perspective basically unrealistic.

> I suspect in practice that most MUAs use the post-SRV-lookup hostname in TLS SNI.

Agreed, where most is ~100%.

> And server support for that name form in SNI will be necessary to interoperate
> with MUAs that don't support RFC 6186

Agreed.

> (or use an alternative autodiscovery mechanism in preference to RFC 6186). So the remaining question is would it be useful/helpful for a server to also support an SNI based on the SRV record or SRV-ID name? I don't think the answer to that question is important enough to justify a normative change to this document.

My take is that support for SRV-ID in SNI would be largely pointless.

> To address this, I suggest we add a sentence to the end of section 4.4 (just before the sentence referencing 7817):
> 
> --
> Mail servers supporting SNI need to support the post-SRV hostname to interoperate with MUAs that have not implemented RFC 6186.
> --
> 
> I view that as a statement of fact rather than a normative change so I think it's kosher. Saying more on the topic would probably cross the normative change line so I'd prefer not to go there.

Works for me.  Of course another way to interoperate (for servers
that don't TLS virtual hosting) is to simply ignore any SNI extension
from the client and always present the same (sole) server certificate
chain.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 11:34:21 -0700

On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman <[email-masked]>
wrote:

>> haven't found any specific advice for (a) what name the MUA should specify
>> in SNI, or (b) what names the server should recognize and have certificates
>> for.   It's pretty clear that the server needs to have a certificate for
>> the name on the right hand side of the SRV record, but should it also have
>> a certificate for the name on the left hand side?  (e.g. _pop3s._
>> tcp.example.com?)  That would potentially make SRV discovery more secure.
>>
> TLS SNI. And server support for that name form in SNI will be necessary to
> interoperate with MUAs that don't support RFC 6186 (or use an alternative
> autodiscovery mechanism in preference to RFC 6186). So the remaining
> question is would it be useful/helpful for a server to also support an SNI
> based on the SRV record or SRV-ID name? I don't think the answer to that
> question is important enough to justify a normative change to this document.
>

So to be clear, what you are saying is that when I enter "mail.example.com"
but it's hosted on "mailhosting.com", and that indirection is done via SRV,
that the certificate contains "mail.example.com" but the SNI contains "
mailhosting.com"?

-Ekr

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 27 Oct 2017 15:20:42 -0400

> On Oct 27, 2017, at 2:34 PM, Eric Rescorla <[email-masked]> wrote:
> 
> So to be clear, what you are saying is that when I enter "mail.example.com" but it's hosted on "mailhosting.com", and that indirection is done via SRV, that the certificate contains "mail.example.com" but the SNI contains "mailhosting.com"?

I would expect a mail user agent that actually uses RFC 6186 to
obtain the target name from SRV records (do any MUAs support this
yet?) to set the reference identifier also to the SRV target,
either because it was validated via DNSSEC, or via a confirmation
dialogue.

Thus both the SNI name and the reference identifier will the same,
in your example "mailhosting.com".

One might also secure the MUAs use of SRV records with DANE,
see also https://tools.ietf.org/html/rfc7672#section-7
https://tools.ietf.org/html/rfc7673 in which case the SNI
would again be the target domain.  The server cannot know
whether the client is statically configured to use the target
name, used SRV with DANE, or SRV with just DNSSEC and WebPKI.

The bottom line is that no matter how the client gets there,
the SNI and reference identifier are the SRV target, but
without DNSSEC, and with SRV-ID unlikely to be practiced,
RFC 6816 requires user confirmation, with all its flaws...

-- 
	Viktor.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Oct 2017 12:24:13 -0700

Yeah, this doesn't seem like an actually secure set of practices, which is
why we don't do it for HTTPS even when there are CNAMEs.

-Ekr

On Fri, Oct 27, 2017 at 12:20 PM, Viktor Dukhovni <[email-masked]>
wrote:

> > So to be clear, what you are saying is that when I enter "
> mail.example.com" but it's hosted on "mailhosting.com", and that
> indirection is done via SRV, that the certificate contains "
> mail.example.com" but the SNI contains "mailhosting.com"?
>

---

From: "Chris Newman" <[email-masked]>
Date: Fri, 27 Oct 2017 13:55:02 -0700

On 27 Oct 2017, at 11:34, Eric Rescorla wrote:
>>>>>> needs to be what you are checking against (which 6186 gets right) 
>>>>>> but
>>>>>> maybe
>>> specify
>>> I

Partly correct, but insufficient to support MUAs that don't implement 
RFC 6186 (which is presently the majority of MUAs). If a mail hosting 
company wants to use SNI to host multiple domains, it has two naming 
approaches for non-6186 customers:

1. customer1.mailhosting.example, customer2.mailhosting.example
2. or customer1.example, customer2.example
(these names can point to the same IP addresses)

These names will be used both for SNI and as the DNS-ID in the 
certificate. If the site chooses to support RFC 6186, then RFC 7817 
requires the certificates have an SRV-ID _in addition to_ the DNS-ID 
(and 6186 clients are required to check the SRV-ID).

So I think my proposed additional statement in combination with the 
requirements in RFC 7817 is sufficient to clarify what goes in SNI and 
to define secure use of RFC 6186 discovery.

		- Chris

---

From: Keith Moore <[email-masked]>
Date: Sat, 28 Oct 2017 06:45:46 -0400

I've taken a stab at writing a non-normative appendix explaining this.

-------------------------
Appendix.  Use of Server Name Indication (SNI) in conjunction with SRV 
records

This section attempts to explain the considerations involved when using 
SNI in conjunction with SRV records, because they do not seem to be 
adequately explained elsewhere.  This section is not normative.

There are two scenarios:

1. When an MUA contacts a mail server using configuration information 
derived from an SRV record.

This case is very similar to the case in which an MUA contacts a mail 
server using configuration explicitly supplied by the user. In either 
case the server name that the MUA uses to obtain the server's IP 
address(es), the server name which is compared with the server 
certificate, and the server name presented in the SNI extension, should 
all be the server's DNS name - i.e. the target of the SRV record when 
SRV is used to discover it.

For a concrete example, assume that a user has address [email-masked] 
and the mail service for example.com is hosted at 
mailserver.example.net.  The SRV record that Joe's MUA uses to learn its 
configuration information might be

_imaps._tcp.example.com.        SRV  0 1 993 mailserver.example.net.

When attempting to access Joe's message store, Joe's MUA would connect 
to an IP address associated with mailserver.example.net on port 993, and 
begin negotiating TLS, sending an SNI extension with HostName = 
mailserver.example.net.   Joe's MUA would then expect the certificate 
returned to have CN-ID or DNS-ID matching mailserver.example.net.   Per 
section X.Y of this document, if the server's certificate doesn't match 
mailserver.example.net, Joe's MUA must abandon the connection.

2. When a MUA derives, or refreshes, account configuration information 
from the user's email address using an SRV record.

When initially configuring Joe's mail account, and perhaps occasionally 
thereafter (say when the TTL from the SRV record returned from the 
previous query for that information has expired or is nearing 
expiration), Joe's MUA may repeat the SRV query for 
_imaps._tcp.example.com.   One way for Joe's MUA to verify that the SRV 
record were authentically issued by example.com would be to verify a 
DNSSEC signature on the SRV record; however, DNSSEC is deploying very 
slowly and therefore might not be available.   An alternate way for 
Joe's MUA to verify that the SRV record were authentically issued by 
example.com would be for Joe's MUA to contact mailserver.example.net on 
port 993, negotiate TLS and include an SNI extension with HostName == 
example.com, and expect a server certificate with either a DNS-ID or an 
SRV-ID matching example.com.

If the target of the current SRV record differs from the server name in 
the MUA's previous configuration for that account and server, the MUA 
must not attempt to authenticate to the server on Joe's behalf as 
[email-masked] unless the server presents a certificate which contains 
an DNS-ID or SRV-ID matching example.com.   If, however, the server 
certificate returned does match example.com, and the authentication 
succeeds, the MUA can then tentatively use the configuration information 
for that account and server based on the new SRV record. However, the 
MUA should then close the connection (without further interaction with 
the server) and reconnect to the server using an IP address associated 
with the server's DNS name, send the server's DNS name in SNI, and 
expect the certificate to match the server's DNS name.   If that is 
successful, Joe's MUA can then update its configuration; otherwise, it 
should retain its previous configuration settings.[*]   (RFC7817 
requires MSPs to return certificates with SRV-IDs if the services are 
advertised using SRV records, but this is relatively recent, and an MSP 
does not necessarily have control over the DNS records advertised by its 
customers).

If the server doesn't return a valid, trusted certificate matching the 
main domain, it doesn't mean that the new SRV record is inauthentic, but 
it does mean that the new SRV record cannot be assumed to be authentic 
based on only unsigned DNS records.  Per section X.Y of this document, 
the MUA must not automatically update its configuration information 
based on an unsigned SRV record, but must require confirmation from the 
user before updating it.   For reasons similar to those listed elsewhere 
in this document when an MUA encounters invalid certificates, the MUA 
should not permit the user to simply "click through" to change the 
configuration.  The MUA should probably not even offer to change the 
configuration at all unless the new SRV records persist over an extended 
period of time.

In the absence of DNSSEC, and assuming that multiple services are 
associated with an email address in the MUA's configuration, this 
process needs to be repeated independently for each SRV record and 
corresponding service that would alter the MUA's configuration for that 
account.  (In other words, successful validation of one SRV record using 
this method does not imply that other SRV records for that mail domain 
are also valid.)

This has implications for both MUAs and mail servers.

MUAs supporting SNI should send SNI with the service name when initially 
configuring an account, and send SNI with the mail server's name when 
accessing the account normally.

Mail servers supporting SNI need to be able to return certificates for 
their own DNS names, and should also be configurable to utilize SNI to 
return certificates containing SRV-IDs for the mail domains for which 
they provide service.   In some cases this means that a domain 
example.com will need to supply a certificate matching a SRV-ID of 
example.com (along with the private key corresponding to the public key 
in the certificate) to the company or companies that provide its mail 
service.   Note that if the certificate only contains a SRV-ID for 
example.com, the certificate and corresponding key pair is somewhat less 
useful to an imposter as compared to a certificate with a DNS-ID.  Of 
course, the same key pair should not be used for both a SRV-ID 
example.com certificate (where the private key is disclosed to a mail 
service provider), and a normal DNS-ID and/or CN-ID certificate for 
example.com.

Mail service providers supporting SNI to verify service name 
certificates for any particular mail domain, need to do so for all 
services associated with that mail domain.
-------------------------

[*] I'm not sure whether this should be included or not.  It strikes me 
as possible (and perhaps reasonable) that an MSP could provision 
different servers for customers using SRV records than for customers not 
doing so, so an MUA should not automatically update its configuration 
based on a changed SRV record if the configuration was not originally 
derived from SRV records.  It also strikes me as possible (and perhaps 
reasonable) that the server could behave differently when given an SNI 
of example.com than when given an SNI of mailserver.example.net, much as 
an HTTP server can behave differently when given a Host request header 
of example.com than a Host request header of mailserver.example.net.   
So my sense is that when actually reading or sending mail, the MUA 
should behave consistently each time and always present the server's 
name in SNI.   (And if I were writing an MUA and the SRV record pointing 
to a user's IMAP or POP server changed, I'd want to be sure that the new 
server actually had the user's mail before committing the change to the 
configuration.)

Anyway, given the length of the above and the difficulty of explaining 
it I can see why Chris would like to keep it to one sentence.

Keith

---

From: Keith Moore <[email-masked]>
Date: Mon, 30 Oct 2017 22:30:19 -0400

After a bit more thought on this, I've concluded that using the mail 
server's server certificates to verify authenticity of SRV records 
probably isn't a good idea - or at least there are more considerations 
and pitfalls than can reasonably be thought through in the context of 
this document.

One consideration is that TLS "reverse proxies" can (and likely do/will) 
use SNI to dispatch to different hosts on the back end, as one way to 
implement "virtual hosting" of mail services.   So if [email-masked] 
needs to be able to authenticate to mailserver.example.net after 
presenting "example.com" in SNI, in addition to being able to 
authenticate to "mailserver.example.net" after presenting 
"mailserver.example.net", that's essentially going to constrain mail 
service providers to configure such reverse proxies to map "example.com" 
and "mailserver.example.net" to the same internal hosts, or at least 
have both of those hosts consult the same servers for authentication.  
This would in some cases make such reverse proxies essentially useless 
as a means to dispatch different traffic to different servers.

Also, of course, being able to authenticate to two different servers 
(even if both present valid certificates for their respective domain 
names) is not the same thing as those two servers being the same.

So now I'm inclined to add a simple sentence or two along the lines of 
Chris's suggestion.   I think that's the best we can do in a short time 
without additional review cycles.

Keith

On 10/28/2017 06:45 AM, Keith Moore wrote:
> This section attempts to explain the considerations involved when 
> using SNI in conjunction with SRV records, because they do not seem to 
> be adequately explained elsewhere.  This section is not normative.
>
> There are two scenarios:
>
> server using configuration explicitly supplied by the user.   In 
> either case the server name that the MUA uses to obtain the server's 
> IP address(es), the server name which is compared with the server 
> certificate, and the server name presented in the SNI extension, 
> should all be the server's DNS name - i.e. the target of the SRV 
> record when SRV is used to discover it.
>
> mailserver.example.net. The SRV record that Joe's MUA uses to learn 
> its configuration information might be
>
> to an IP address associated with mailserver.example.net on port 993, 
> and begin negotiating TLS, sending an SNI extension with HostName = 
> returned to have CN-ID or DNS-ID matching mailserver.example.net.   
> Per section X.Y of this document, if the server's certificate doesn't 
> match mailserver.example.net, Joe's MUA must abandon the connection.
>
> When initially configuring Joe's mail account, and perhaps 
> occasionally thereafter (say when the TTL from the SRV record returned 
> from the previous query for that information has expired or is nearing 
> _imaps._tcp.example.com.   One way for Joe's MUA to verify that the 
> SRV record were authentically issued by example.com would be to verify 
> a DNSSEC signature on the SRV record; however, DNSSEC is deploying 
> very slowly and therefore might not be available.   An alternate way 
> for Joe's MUA to verify that the SRV record were authentically issued 
> by example.com would be for Joe's MUA to contact 
> mailserver.example.net on port 993, negotiate TLS and include an SNI 
> extension with HostName == example.com, and expect a server 
> certificate with either a DNS-ID or an SRV-ID matching example.com.
>
> If the target of the current SRV record differs from the server name 
> in the MUA's previous configuration for that account and server, the 
> MUA must not attempt to authenticate to the server on Joe's behalf as 
> [email-masked] unless the server presents a certificate which 
> contains an DNS-ID or SRV-ID matching example.com.   If, however, the 
> server certificate returned does match example.com, and the 
> authentication succeeds, the MUA can then tentatively use the 
> configuration information for that account and server based on the new 
> SRV record. However, the MUA should then close the connection (without 
> further interaction with the server) and reconnect to the server using 
> an IP address associated with the server's DNS name, send the server's 
> DNS name in SNI, and expect the certificate to match the server's DNS 
> name.   If that is successful, Joe's MUA can then update its 
> configuration; otherwise, it should retain its previous configuration 
> settings.[*]   (RFC7817 requires MSPs to return certificates with 
> SRV-IDs if the services are advertised using SRV records, but this is 
> relatively recent, and an MSP does not necessarily have control over 
> the DNS records advertised by its customers).
>
> main domain, it doesn't mean that the new SRV record is inauthentic, 
> but it does mean that the new SRV record cannot be assumed to be 
> authentic based on only unsigned DNS records.  Per section X.Y of this 
> document, the MUA must not automatically update its configuration 
> information based on an unsigned SRV record, but must require 
> confirmation from the user before updating it. For reasons similar to 
> those listed elsewhere in this document when an MUA encounters invalid 
> certificates, the MUA should not permit the user to simply "click 
> through" to change the configuration.  The MUA should probably not 
> even offer to change the configuration at all unless the new SRV 
> records persist over an extended period of time.
>
> corresponding service that would alter the MUA's configuration for 
> that account.  (In other words, successful validation of one SRV 
> record using this method does not imply that other SRV records for 
> that mail domain are also valid.)
>
> MUAs supporting SNI should send SNI with the service name when 
> initially configuring an account, and send SNI with the mail server's 
> name when accessing the account normally.
>
> example.com (along with the private key corresponding to the public 
> key in the certificate) to the company or companies that provide its 
> mail service.   Note that if the certificate only contains a SRV-ID 
> for example.com, the certificate and corresponding key pair is 
> somewhat less useful to an imposter as compared to a certificate with 
> a DNS-ID.  Of course, the same key pair should not be used for both a 
> SRV-ID example.com certificate (where the private key is disclosed to 
> a mail service provider), and a normal DNS-ID and/or CN-ID certificate 
> for example.com.
>
> [*] I'm not sure whether this should be included or not.  It strikes 
> me as possible (and perhaps reasonable) that an MSP could provision 
> different servers for customers using SRV records than for customers 
> not doing so, so an MUA should not automatically update its 
> configuration based on a changed SRV record if the configuration was 
> not originally derived from SRV records.  It also strikes me as 
> possible (and perhaps reasonable) that the server could behave 
> differently when given an SNI of example.com than when given an SNI of 
> mailserver.example.net, much as an HTTP server can behave differently 
> when given a Host request header of example.com than a Host request 
> header of mailserver.example.net.   So my sense is that when actually 
> reading or sending mail, the MUA should behave consistently each time 
> and always present the server's name in SNI.   (And if I were writing 
> an MUA and the SRV record pointing to a user's IMAP or POP server 
> changed, I'd want to be sure that the new server actually had the 
> user's mail before committing the change to the configuration.)
>

---

From: "Chris Newman" <[email-masked]>
Date: Tue, 31 Oct 2017 11:29:07 -0700

> and pitfalls than can reasonably be thought through in the context of 

I think what RFC 7817 says about certificate validation is fine, so I 
don't want to repeat or contradict what it says.

> One consideration is that TLS "reverse proxies" can (and likely 
> do/will) use SNI to dispatch to different hosts on the back end, as 
> one way to implement "virtual hosting" of mail services.

I don't know if this is done for mail, but SNI routing appears to be in 
use:
    http://proxy.dockerflow.com/sni-routing/

Luckily domain names are cheap, so example.com SRV can point to an 
example.com.mailhosting.example.net domain name or something like that 
so there's no ambiguity and RFC 7817 cert validation will work fine on 
that domain name.

> names) is not the same thing as those two servers being the same.

It's becoming less likely over time that two connections to a particular 
domain name will be handled by the same physical hardware. Luckily 
certificates don't restrict this.

> Chris's suggestion.   I think that's the best we can do in a short 
> time without additional review cycles.

Agreed.

		- Chris

>> Appendix.  Use of Server Name Indication (SNI) in conjunction with 
>> SRV records
>>
>> using SNI in conjunction with SRV records, because they do not seem 
>> to be adequately explained elsewhere.  This section is not 
>> normative.
>>
>> There are two scenarios:
>>
>> For a concrete example, assume that a user has address 
>> [email-masked] and the mail service for example.com is hosted at 
>> When attempting to access Joe's message store, Joe's MUA would 
>> connect to an IP address associated with mailserver.example.net on 
>> port 993, and begin negotiating TLS, sending an SNI extension with 
>> HostName = mailserver.example.net.   Joe's MUA would then expect the 
>> certificate returned to have CN-ID or DNS-ID matching 
>> mailserver.example.net.   Per section X.Y of this document, if the 
>> server's certificate doesn't match mailserver.example.net, Joe's MUA 
>> must abandon the connection.
>>
>> 2. When a MUA derives, or refreshes, account configuration 
>> information from the user's email address using an SRV record.
>>
>> occasionally thereafter (say when the TTL from the SRV record 
>> returned from the previous query for that information has expired or 
>> is nearing expiration), Joe's MUA may repeat the SRV query for 
>> SRV record were authentically issued by example.com would be to 
>> verify a DNSSEC signature on the SRV record; however, DNSSEC is 
>> deploying very slowly and therefore might not be available.   An 
>> alternate way for Joe's MUA to verify that the SRV record were 
>> authentically issued by example.com would be for Joe's MUA to contact 
>> contains an DNS-ID or SRV-ID matching example.com.   If, however, 
>> the server certificate returned does match example.com, and the 
>> configuration information for that account and server based on the 
>> new SRV record. However, the MUA should then close the connection 
>> (without further interaction with the server) and reconnect to the 
>> server using an IP address associated with the server's DNS name, 
>> send the server's DNS name in SNI, and expect the certificate to 
>> match the server's DNS name.   If that is successful, Joe's MUA can 
>> then update its configuration; otherwise, it should retain its 
>> previous configuration settings.[*]   (RFC7817 requires MSPs to 
>> return certificates with SRV-IDs if the services are advertised using 
>> SRV records, but this is relatively recent, and an MSP does not 
>> necessarily have control over the DNS records advertised by its 
>> customers).
>>
>> If the server doesn't return a valid, trusted certificate matching 
>> the main domain, it doesn't mean that the new SRV record is 
>> inauthentic, but it does mean that the new SRV record cannot be 
>> assumed to be authentic based on only unsigned DNS records.  Per 
>> section X.Y of this document, the MUA must not automatically update 
>> its configuration information based on an unsigned SRV record, but 
>> must require confirmation from the user before updating it. For 
>> reasons similar to those listed elsewhere in this document when an 
>> MUA encounters invalid certificates, the MUA should not permit the 
>> user to simply "click through" to change the configuration.  The MUA 
>> should probably not even offer to change the configuration at all 
>> unless the new SRV records persist over an extended period of time.
>>
>> Mail servers supporting SNI need to be able to return certificates 
>> for their own DNS names, and should also be configurable to utilize 
>> SNI to return certificates containing SRV-IDs for the mail domains 
>> for which they provide service. In some cases this means that a 
>> domain example.com will need to supply a certificate matching a 
>> SRV-ID of example.com (along with the private key corresponding to 
>> the public key in the certificate) to the company or companies that 
>> provide its mail service.   Note that if the certificate only 
>> contains a SRV-ID for example.com, the certificate and corresponding 
>> key pair is somewhat less useful to an imposter as compared to a 
>> certificate with a DNS-ID.  Of course, the same key pair should not 
>> be used for both a SRV-ID example.com certificate (where the private 
>> key is disclosed to a mail service provider), and a normal DNS-ID 
>> and/or CN-ID certificate for example.com.
>>
>> differently when given an SNI of example.com than when given an SNI 
>> of mailserver.example.net, much as an HTTP server can behave 
>> differently when given a Host request header of example.com than a 
>> Host request header of mailserver.example.net.   So my sense is 
>> that when actually reading or sending mail, the MUA should behave 
>> consistently each time and always present the server's name in SNI. 
>>   (And if I were writing an MUA and the SRV record pointing to a 
>> user's IMAP or POP server changed, I'd want to be sure that the new 
>> server actually had the user's mail before committing the change to 
>> the configuration.)
>>
>> Anyway, given the length of the above and the difficulty of 
>> explaining it I can see why Chris would like to keep it to one 
>> sentence.
>>
>> Keith
>>
>>

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 31 Oct 2017 14:32:36 -0400

> On Oct 30, 2017, at 10:30 PM, Keith Moore <[email-masked]> wrote:
> 
> So now I'm inclined to add a simple sentence or two along the lines of Chris's suggestion.   I think that's the best we can do in a short time without additional review cycles.

While I might choose differ with some parts of the text
leading to this conclusion, I am fine with the conclusion,
so it is probably best to leave it at that.

-- 
	Viktor.