Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 8:10 PM, Viktor Dukhovni via Exim-dev  
> wrote:
> 
> If they have a default certificate chain that works with TLS 1.2
> withholding it with TLS 1.3 seems rather rude...  I'll chat with
> David Benjamin, perhaps he'll have good reasons for this that I'm
> missing, but off hand it seems counter-productive.

I've reproduced this with [gmail-smtp-in.l.google.com] and posttls-finger
linked against the OpenSSL 1.1.1 library.  When sending a TLS client HELLO
that supports TLS 1.3, but no SNI the Google SMTP server negotiates TLS
1.2 (not 1.3), but with the self-signed cert.  When using the OpenSSL 1.1.0
liobraries, it negotiates TLS 1.2 with the usual certificate chain.

This is rather annoying, and we may have to bump the OpenSSL library SONAME
as a result, so that applications don't suddenly find themselves unable
to authenticate servers they could previously authenticate.

This could affect users who've configured secure-channel TLS with Gmail,
but have not set up SNI (not presently configurable outside of DANE in
Postfix, for example).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 8:03 PM, Viktor Dukhovni  wrote:
> 
>> This came up because, today, Google's servers are responding to TLS1.3
>> connections which don't send SNI with a self-signed certificate which
>> has DN:
>> 
>> OU=No SNI provided; please fix your client., CN=invalid2.invalid
>> 
>> So Google are telling sending systems that they're broken and need to be
>> fixed.  I saw that string in my MTA logs and went investigating.
> 
> Which Google servers are these?  Are they MX hosts for some domains???
> If so, I need to tell Google urgently to cease and desist, this is
> wrong.

On the other hand, for opportunistic TLS, who cares if they return some
self-signed certificate, so long as the handshake completes with that
certificate, we're good.

The real problem will be if applications that previously sent no SNI
with TLS 1.2 in OpenSSL 1.1.0 are run-time linked with the OpenSSL
1.1.1 libraries (same SONAME) and no start doing TLS 1.3, and find
that they now fail to authenticate Google.  This sort of enforcement
will backfire and have the effect of turning off TLS 1.3, not getting
users to rewrite applications to send SNI.

If they have a default certificate chain that works with TLS 1.2
withholding it with TLS 1.3 seems rather rude...  I'll chat with
David Benjamin, perhaps he'll have good reasons for this that I'm
missing, but off hand it seems counter-productive.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 7:09 PM, Phil Pennock  wrote:
> 
> I agree the spec shows we can argue it's not required, but the spec also
> allows recipients to argue that it is required.
> 
> This came up because, today, Google's servers are responding to TLS1.3
> connections which don't send SNI with a self-signed certificate which
> has DN:
> 
>  OU=No SNI provided; please fix your client., CN=invalid2.invalid
> 
> So Google are telling sending systems that they're broken and need to be
> fixed.  I saw that string in my MTA logs and went investigating.

Which Google servers are these?  Are they MX hosts for some domains???
If so, I need to tell Google urgently to cease and desist, this is
wrong.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] TLS 1.3 *does not* mandate SNI.

[Viktor Dukhovni via Exim-dev]

The mandatory to implement language in the TLS 1.3 spec does not mean 
"mandatory to use", in particular, while servers must tolerate the extension, 
clients are not obligated to sen d it:

https://tools.ietf.org/html/draft-ietf-tls-tls13-28#section-4.4.2.2

   -  The "server_name" [RFC6066] and "certificate_authorities"
  extensions are used to guide certificate selection.  As servers
  MAY require the presence of the "server_name" extension, clients
  SHOULD send this extension, when applicable.

SHOULD is of course a strong incentive, but it is not a MUST, and, if no SNI 
can be reasonably inferred, and particularly if not authenticating the peer, 
the SNI can
be left out.  Time will tell whether there are more servers that screw up by 
aborting
when receiving an SNI for which they don't have an exactly matching 
certificate, or
by mandating SNI with TLS 1.3 despite serving a mostly opportunistic protocol!

While the TLS 1.3 protocol does allow servers to insist on SNI:

   Additionally, all implementations MUST support use of the
   "server_name" extension with applications capable of using it.
   Servers MAY require clients to send a valid "server_name" extension.
   Servers requiring this extension SHOULD respond to a ClientHello
   lacking a "server_name" extension by terminating the connection with
   a "missing_extension" alert.

Such insistence will quickly run into interop issues with opportunistic
TLS from e.g. Postfix, where SNI will not be sent by default.  I expect
that MTAs (as opposed to perhaps MSAs) will not require SNI.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 4:37 PM, admin--- via Exim-dev  wrote:
> 
> SNI for a DANE-advertising site has to be different than one that does not?
> Sheesh.  Does that not implicitly require that _all_ clients be DANE-aware,
> or that _all_ DANE-advertising hosts be prepared to be hit with SNI from
> non-DANE-aware clients (and still do the right thing)?
> 
> I think SNI just became useless.

A host with TLSA records should expect DANE clients to send the MX hostname
as the SNI name.  Other clients might use other SNI names or none at all.
I don't see how SNI becomes useless.  If you've got a matching cert, send
that, if not send a default cert.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2266] New: TLS SNI should default set

[Jeremy Harris via Exim-dev]

On 17/04/18 22:23, Viktor Dukhovni via Exim-dev wrote:
> Not sure what you mean by "$domain",

It's an Exim variable.  The part of a mail address after the @.

 but the DANE SNI *must* be the TLSA
> base domain,

You're commenting with reference to the specifically non-DANE bug
number.

-- 
Jeremy

-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2264] New: DNS lookups should not chase CNAME loops

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 3:58 PM, admin--- via Exim-dev  wrote:
> 
> Per the discussion starting
> https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017449.html
> we should trust that the resolver is doing the right thing, following CNAME
> chains itself - meaning that a CNAME return from a CNAME lookup will always
> be an infinite loop and should be treated as NODATA.  The limited loop we
> have can be removed so we do not hammer the resolver.

Specifically, the relevant guidance is in:

   https://tools.ietf.org/html/rfc6604#section-3

which explains that the RCODE for a response (with qtype != CNAME) in which the 
initial qname leads to a CNAME indicates the status of the query for the 
requested qtype at the final CNAME in the chain.  This means (modulo DNSSEC 
failures, which lead to ServFail):

1.  If the final name has data for the requested type,
it must be present in the response (modulo truncation,
which should lead to TCP retries...).  The RCODE is then NOERROR

2.  If the final name has no data of the requested type, the RCODE
is still NOERROR, and no data of the requested type is provided.
(thus effectively NODATA).

3.  If the final name does not exist, the RCODE is NXDOMAIN

4.  If the resolver exceeded its recursion limit the RCODE is SERVEFAIL

5.  If there's a CNAME loop, the RCODE is typically SERVFAIL, but some
nameservers return the looping CNAMEs and NOERROR, only reported
with BIND when the final CNAME is a direct loop (x -> x).

This means that the DNS client can always infer all it needs from a single
response, and should make iterative queries for each (or any) returned
CNAMEs.  Instead it should be willing to iteratively parse the original
response chasing CNAMEs within the response to find the requested data.
Note that the order of RRsets in the response is not guaranteed, and in
theory the answer may come before the CNAMEs and the CNAMEs might not be
in order (neither "pathology" is common, but sadly one must be prepared).

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

Re: [exim-dev] [Bug 2266] New: TLS SNI should default set

[Viktor Dukhovni via Exim-dev]

> On Apr 17, 2018, at 4:17 PM, admin--- via Exim-dev  wrote:
> 
> Handling for DANE should be in issue 2265.  DANE should stop using the tls_sni
> SMTP Transport option and DANE handling is not in-scope for _this_ tracking
> bug.
> 
> IMO tls_sni should default to $domain, which requires disabling multi_domain 
> by
> default.

Not sure what you mean by "$domain", but the DANE SNI *must* be the TLSA
base domain, which is typically the MX hostname (but sometimes its full
CNAME expansion).  It is only the nexthop domain when the domain has no
MX records (implicit MX) or an explicit MX whose name is the domain itself.

Thus for:

example.net. IN MX 0 smtp.example.net.
smtp.example.net. IN A 192.0.2.1
_25._tcp.smtp.example.net. IN TLSA 3 1 1 ...

the SNI value must be "smtp.example.net" not "example.net".
The SMTP server must not abort the handshake when it finds
no matching certificate, rather it must select some
appropriate default chain.

-- 
Viktor.


-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2265

--- Comment #2 from Phil Pennock  ---
DANE requires that SNI point to the MX hostname, to make it easier to manage
mass-hosting.  This is a good stance but requires DNSSEC to be safe.  The
hostname to be verified in a certificate should be the hostname from SNI and
without DNSSEC, that would mean verifying a potentially-tampered-with hostname.

The name to be verified must always have a trustworthy path back to user input.

We _could_ auto-switch to MX for DNSSEC, not just for DANE, but that adds more
scenarios and IMO it's better to reduce to "DANE vs non-DANE".

Thus for the non-DANE case we should stick to $domain by default, if picking a
default, else something from per-site configuration of OOB configuration for
some domains.  That's being addressed in 2266.

In a world pre-DANE, SNI is pointless because there's no certificate
verification performed.  If you're not going to verify, why set a name to
select a certificate?  It's only because TLS 1.3 _mandates_ SNI if not
explicitly countered in an application profile, and I can't be bothered to
spend three years fighting under-informed people to push through an application
profile for SMTP MX delivery matching reality rather than idealism, that I'm
shrugging and picking "something" for SNI in 2266.

For submissions/submission+starttls the use of SNI for key/certificate
selection makes a lot of sense.  For a DANE world it could make sense in the
future.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2265] TLS SNI not auto-set for DANE clients

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2265

--- Comment #1 from Jeremy Harris  ---
SNI for a DANE-advertising site has to be different than one that does not?
Sheesh.  Does that not implicitly require that _all_ clients be DANE-aware,
or that _all_ DANE-advertising hosts be prepared to be hit with SNI from
non-DANE-aware clients (and still do the right thing)?

I think SNI just became useless.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2266] TLS SNI should default set

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2266

--- Comment #1 from Phil Pennock  ---
Oh crap, I just remembered something I lost in the mess of juggling mental
state before creating a tracking bug.

The documentation change in the branch above explicitly states behavior for
tls_sni when expansion is empty or forced to fail.  That's not the current
behavior, but part of what I intended to include as part of this work.  It's
another reason for the commit being a WIP outside the main repo.

Mentioning this here so it doesn't get lost.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2266] New: TLS SNI should default set

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2266

Bug ID: 2266
   Summary: TLS SNI should default set
   Product: Exim
   Version: N/A
  Hardware: x86
OS: All
Status: NEW
  Severity: bug
  Priority: medium
 Component: TLS
  Assignee: jgh146...@wizmail.org
  Reporter: p...@exim.org
CC: exim-dev@exim.org

With TLS 1.3 mandating SNI from clients unless an application profile prohibits
that, we should be providing a default value of SNI.

Handling for DANE should be in issue 2265.  DANE should stop using the tls_sni
SMTP Transport option and DANE handling is not in-scope for _this_ tracking
bug.

IMO tls_sni should default to $domain, which requires disabling multi_domain by
default.

My first pass proposal is in:
https://git.exim.org/users/pdp/exim.git/shortlog/refs/heads/tls_sni_mandatoryish

That is a WIP-do-not-merge because I discovered when wrapping up that I was
wrong about our DANE handling.  It could go in now, but would result in us
actively sending the wrong value for DANE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2265] New: TLS SNI not auto-set for DANE clients

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2265

Bug ID: 2265
   Summary: TLS SNI not auto-set for DANE clients
   Product: Exim
   Version: N/A
  Hardware: x86
OS: All
Status: NEW
  Severity: bug
  Priority: medium
 Component: TLS
  Assignee: jgh146...@wizmail.org
  Reporter: p...@exim.org
CC: exim-dev@exim.org

We should be auto-setting SNI for DANE, ignoring the manual tls_sni control,
when a domain is DANE-secured.  The SNI field is the MX hostname.  RFCs 7671
and 7672.
("base domain" in DANE is the name before adding the _25._tcp stuff to do the
lookup, so the MX hostname).

This means we're missing an RFC MUST requirement for DANE.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2264] DNS lookups should not chase CNAME chains

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2264

Jeremy Harris  changed:

   What|Removed |Added

Summary|DNS lookups should not  |DNS lookups should not
   |chase CNAME loops   |chase CNAME chains

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2264] New: DNS lookups should not chase CNAME loops

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2264

Bug ID: 2264
   Summary: DNS lookups should not chase CNAME loops
   Product: Exim
   Version: 4.91
  Hardware: All
OS: All
Status: NEW
  Severity: bug
  Priority: low
 Component: Networking
  Assignee: ni...@exim.org
  Reporter: jgh146...@wizmail.org
CC: exim-dev@exim.org

Per the discussion starting
https://lists.dns-oarc.net/pipermail/dns-operations/2018-April/017449.html
we should trust that the resolver is doing the right thing, following CNAME
chains itself - meaning that a CNAME return from a CNAME lookup will always
be an infinite loop and should be treated as NODATA.  The limited loop we
have can be removed so we do not hammer the resolver.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2199] Exim use-after-free vulnerability while reading mail header

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2199

Jhon Merced  changed:

   What|Removed |Added

 CC||jhonmerc...@gmx.com

--- Comment #20 from Jhon Merced  ---
Seems to work. Thanks for the fix guys.

Jhon
https://mrkortingscode.nl/

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##