Subject: Re: [Uta] flake ho, was MTA-STS with lots of domains

From: "John Levine" <[email-masked]>
Date: 13 Jan 2019 23:46:29 -0500

In my continuing effort to run my mail server the way I always have* I
added SNI to my mail server, which wasn't very hard, and generated
about a hundred certs.

The good news is that it mostly works -- I sent myself a message from
my gmail account, I can see that google does SNI, my system sends it
the cert, and it works fine.

The bad news is that it's really flaky.  When I send myself mail from
my Comcast account, same SNI, same cert, and kaboom.  I don't know
whether it's gnutls or what.

Any helpful suggestions?

R's,
John

(Those hex numbers are djb timestamps, but don't panic, this is mailfront,
not qmail-smtpd.)

@400000005c3c0fa223836c4c tcpserver: ok 78670 mail1.iecc.com:2001:470:1f07:1126:33:5370:616d:6d31:25 :2001:558:fe16:19:96:114:154:171::36062
@400000005c3c0fa31eddb9cc mailfront[78670]: Starting TLS handshake
@400000005c3c0fa322a0865c mailfront[78670]: SNI value: mx1.taugh.com
@400000005c3c0fa3231479f4 mailfront[78670]: Using SNI cert file for mx1.taugh.com
@400000005c3c0fa32d79b364 mailfront[78670]: TLS handshake failed: A TLS fatal alert has been received.
@400000005c3c0fa32d79bf1c mailfront[78670]: bytes in: 0 bytes out: 0

* - cue Frank Sinatra singing "My Way"

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Jan 2019 00:00:51 -0500

> On Jan 13, 2019, at 11:46 PM, John Levine <[email-masked]> wrote:
> 

Plausibly, based on the logs, the client did not like the handshake,
and sent some sort of alert.  Sadly, the logging omits the crucial
alert number or description, so there's not much to go on.

Perhaps these SNI configurations fail to include the intermediate CA
certs?  And the client is enforcing use of TLS?

Also, keep in mind that Comcast implements DANE, and you're now
serving a different certificate, that does not match the TLSA
record, then all the pieces fit together...

On the other hand, though I had trouble connecting to your IPv4 service,
your IPv6 SMTP server does seem to have the correct TLSA RRs:

taugh.com. IN MX 20 mx1.taugh.com. ; AD=1 NoError
mx1.taugh.com. IN A 64.57.183.56 ; AD=1 NoError
mx1.taugh.com. IN AAAA 2001:470:1f07:1126:33:5370:616d:6d31 ; AD=1 NoError
_25._tcp.mx1.taugh.com. IN CNAME _25._tcp.mail1.iecc.com. ; AD=1 NoError
_25._tcp.mail1.iecc.com. IN TLSA 3 1 1 eb6cbfd29e89b8debba18703ae532eb1bf76c92d8c421c0f6d8ae49c96427a0d ; AD=1 NoError
  mx1.taugh.com[64.57.183.56]: connection timeout
  mx1.taugh.com[2001:470:1f07:1126:33:5370:616d:6d31]: pass: TLSA match: depth = 0
    TLS = TLS12 with ECDHE-RSA-AES256GCM-SHA384
    name = mail1.iecc.com
    depth = 0
      Issuer CommonName = Let's Encrypt Authority X3
      Issuer Organization = Let's Encrypt
      notBefore = 2018-12-09T08:00:40Z
      notAfter = 2019-03-09T08:00:40Z
      Subject CommonName = mail1.iecc.com
      pkey sha256 [matched] <- 3 1 1 eb6cbfd29e89b8debba18703ae532eb1bf76c92d8c421c0f6d8ae49c96427a0d
    depth = 1
      Issuer CommonName = DST Root CA X3
      Issuer Organization = Digital Signature Trust Co.
      notBefore = 2016-03-17T16:40:46Z
      notAfter = 2021-03-17T16:40:46Z
      Subject CommonName = Let's Encrypt Authority X3
      Subject Organization = Let's Encrypt
      pkey sha256 [nomatch] <- 2 1 1 60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18

But the returned certificate, does not match the SNI name.

If your server has "multiple personality disorder", trying to make
both MTA-STS and DANE work can be daunting, though by using
the same underlying public key, with "3 1 1" records the TLSA
records might be "personality-agnostic". :-)

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2019 00:15:26 -0500

>alert number or description, so there's not much to go on.

Yeah, tomorrow I'll try and get better logging.

>certs?  And the client is enforcing use of TLS?

No, it's the full chain.

>But the returned certificate, does not match the SNI name.

That might be it.  I published new TLSA records to match the new certs
but between the 1 hour TTL and one of my DNS servers being slow to
pick up updates, I can imagine you might see an old one.

>records might be "personality-agnostic". :-)

Let me see if I can persuade acme.sh to generate certs with the same key.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2019 14:48:58 -0500

>>record, then all the pieces fit together...

That was it.  I got acme.sh to reissue the certs so that all the certs
on the same IP have the same key and hence the same TLSA.  Now
Comcast's mail is happy.

Today's question: I would like to log the SNI in the Received header.
Where should I put it?  

One possibilty would be to use the SNI name as the by-domain in the BY
clause, but that makes it hard to tell that the name came from SNI
rather than by default.  I suppose I could put it in a comment but
that's ugly.  In retrospect, RFC8461 should have added an SNI clause
to Received, like RFC 8314 added tls and group clauses.

Any suggestions?

R's,
John

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 14 Jan 2019 19:54:05 +0000

>    One possibilty would be to use the SNI name as the by-domain in the BY
    clause,

How about BY xxx/sni-host ?

---

From: "John R Levine" <[email-masked]>
Date: 14 Jan 2019 15:22:10 -0500

On Mon, 14 Jan 2019, Salz, Rich wrote:
>>    One possibilty would be to use the SNI name as the by-domain in the BY  clause,
>

RFCs 2821 and 5321 define the syntax of trace headers, to make it easy to 
parse a correctly formed one.  The syntax is roughly

BY domain1 (domain2 1.2.3.4)

where domain1 is usually the host's own idea of its name and domain2 is 
usually the rDNS.  I suppose that domain2 is rarely used in BY so I could 
stick it there.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 14 Jan 2019 15:13:19 -0500

> to Received, like RFC 8314 added tls and group clauses.

I like the idea of a formalized place to record SNI in the Received:
header, and would be happy to see a document that specifies how to do
it.

        --dkg

---

From: Grant Taylor <[email-masked]>
Date: Mon, 14 Jan 2019 13:36:54 -0700

> Today's question: I would like to log the SNI in the Received header. 

Wouldn't it go in with the rest of the TLS information?

For example, here's the Received: header for the message that I'm 
replying to.

Received: from mail.ietf.org (mail.ietf.org 
[IPv6:2001:1900:3001:11:0:0:0:2c])
	by tncsrv06.tnetconsulting.net (8.15.2/8.15.2/Debian-3) with ESMTPS id 
x0EJn9u3003563
	(version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO 
  ***Wouldn't*SNI*information*go*here?***)
	for <REDACTED>; Mon, 14 Jan 2019 13:49:11 -0600

I'd think that you would add the SNI information in the parentesis with 
the rest of the TLS information.  As opposed to modifying the by line.

-- 
Grant. . . .
unix || die

---

From: "John R Levine" <[email-masked]>
Date: 14 Jan 2019 16:20:53 -0500

> header, and would be happy to see a document that specifies how to do

Per the subsequent note, I'm sticking it in the BY header which allows a 
second domain name in the parens that nobody ever uses.

I could write an I-D easily enough to add a new received clause, but it 
has to be experimental or standards track so the process overhead is 
significant.  Perhaps wait a while as we see how well MTA-STS works in 
practice.

I've yet to get any STS reports, even though a fair number of mail clients 
send SNI info.

Regards,

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2019 16:43:15 -0500

In article <[email-masked]> you write:
>-=-=-=-=-=-

I am so sorry to be reminded that I am the only person in the
world who actually reads the fricking RFCs.

Would everyone who's planning to continue this discussion please stop
right now and read the relevant RFCs rather than guessing wrong?

RFC 5321 section 4.4 describes the syntax of a Received header.  RFC 8314
section 7.4 defines the "tls" and "group" clauses.

To show that you read it, please include the first word in the text
on page 50 or RFC 5321 in your reply.

>  ***Wouldn't*SNI*information*go*here?***)

As anyone who has looked at RFC 5321 should know, that's a comment.
You can put anything in a comment, but downstream code can't parse it
reliably.

R's,
John

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Jan 2019 17:05:57 -0500

> to Received, like RFC 8314 added tls and group clauses.

FWIW, Postfix puts TLS connection details in comments:

    Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])
	    (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	    (No client certificate requested)
	    by straasha.imrryr.org (Postfix) with ESMTPS id 7D12433E8F
	    for <[email-masked]>; Mon, 14 Jan 2019 15:22:19 -0500 (EST)

The "using TLS X with cipher Y" syntax admits further refinement, thus
for TLS 1.3 the comment becomes (when client certs are also present):

    Received: from example.com (localhost [127.0.0.1])
	    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	     key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	     client-signature ECDSA (P-256) client-digest SHA256)
	    (Client CN "example.com", Issuer "example.com" (not verified))
	     by example.com (Postfix) with ESMTPS id 8956D2012E3208
	    for <[email-masked]>; Mon, 14 Jan 2019 15:46:32 -0500 (EST)

so, just the like the trace header itself, the comment content,
after "with", is a list of key-value pairs.  My plan is to add SNI
there:

    Received: from example.com (localhost [127.0.0.1])
	    (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
	     key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
	     client-signature ECDSA (P-256) client-digest SHA256
	     server_name example.com)

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2019 17:39:07 -0500

>FWIW, Postfix puts TLS connection details in comments:

That's not wrong, but now that RFC 8314 has defined the tls clause, why
not put the data where the spec says?  If you have more than what 8314
includes, put the rest in a comment but at least we can parse the stuff
that meets the spec.

R's,
John

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 14 Jan 2019 17:48:19 -0500

> on page 50 or RFC 5321 in your reply.

I'm sorry to spoil it for everyone that the word is "The" :P

John, i think you're talking about (ab)using the Domain variant of the
TCP-info variant of Extended-Domain in the By-domain expansion of Stamp.
While the Domain part of that ABNF doesn't describe how it's supposed to
be derived from "Information derived by server from TCP connection" for
the BY clause specifically, i think using it for SNI is entirely
reasonable.

Many implementations don't even use the TCP-info variant for the BY
clause.  for example, from a copy of a message i received on this
thread:

Received: from mail.ietf.org (mail.ietf.org [4.31.198.44])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by foo.example.com (Postfix) with ESMTPS
	for <[email-masked]>; Mon, 14 Jan 2019 15:22:20 -0500 (EST)

the BY clause here just uses Extended-Domain as Domain (no TCP-info at
all), and "(Postfix)" is just a Comment.

> You can put anything in a comment, but downstream code can't parse it

Hm, you'd need to read RFC 5322 to get to the definition of CFWS to know
that's a comment, not just RFC 5321 :P

I know that you're frustrated, but please be gentler with people who
don't have as much in-depth knowledge of the RFCs as you do.

I really appreciate the specific pointers you've given in this thread.

Regards,

  --dkg

---

From: "John R Levine" <[email-masked]>
Date: 14 Jan 2019 18:09:41 -0500

On Mon, 14 Jan 2019, Daniel Kahn Gillmor wrote:

>> on page 50 of RFC 5321 in your reply.
>

Sigh.  Nope.

> the BY clause specifically, i think using it for SNI is entirely

Right.  As far as I can tell, it's there for symmetry with the FROM clause 
where the first domain is the HELO/EHLO and the second is the rDNS for the 
connecting IP.  I don't think I've ever seen the second name used in the 
BY clause.

> don't have as much in-depth knowledge of the RFCs as you do.

Wait a minute -- this is the UTA working group of the IETF.  The point of 
this group is to revise and extend and update and write RFCs.  If people 
can't be bothered to read the RFCs they're purportedly working on, why are 
they here?  I realize that some of the RFCs are long, but they have tables 
of contents.  It's not hard to check the syntax of something rather than 
guessing and wasting everyone's time.  I checked the syntax in RFCs 5321, 
5322, and 8314 before I asked my question, and other people can too.

Regards,

---

From: Jeremy Harris <[email-masked]>
Date: Tue, 15 Jan 2019 00:28:45 +0000

On 14/01/2019 22:39, John Levine wrote:
>  now that RFC 8314 has defined the tls clause, why
> not put the data where the spec says?

8314 talks about an MSA adding a Received: header.
Should we assume the same for a general MTA?

It seems reasonable to me, and I can probably get
it added to the default Exim definition.
-- 
Cheers,
  Jeremy

---

From: Grant Taylor <[email-masked]>
Date: Mon, 14 Jan 2019 18:22:23 -0700

> I'm sorry to spoil it for everyone that the word is "The" :P

Agreed.

> While the Domain part of that ABNF doesn't describe how it's supposed 
> to be derived from "Information derived by server from TCP connection" 
> for the BY clause specifically, i think using it for SNI is entirely 
> reasonable.

That seems like a layering violation to me.  I would think that the 
information about the TCP connection would consist of the IPs and ports. 
  It seems to me like anything TLS related would be at a higher layer 
than "the TCP connection".

I would think that any information about STARTTLS and associated SNI 
would be excluded from "information derived by server from TCP 
connection (source IP, destination IP, source port, destination port)". 
Thus I think SNI information would need to be indicated elsewhere.

I feel like the Domain of the TCP-info of the Extended-Domain of the 
By-domain could / would / should be used to identify which IP address of 
a multi-homed ""host (I use that term loosely), that has many IP 
addresses that are each associated with different FQDNs.

Example 1:

	by multi-homed-host.example.net (client-mx-1.client-1.example [192.0.2.1])

Example 2:

	by multi-homed-host.example.net (client-mx-2.client-2.example 
[198.51.100.2])

Example 3:

	by multi-homed-host.example.net (client-mx-3.client-3.example 
[203.0.113.3])

I feel like the Domain of the TCP-info of the Extended-Domain of the 
By-domain is for information to identify the TCP/IP endpoint of the SMTP 
connection.

> clause.  for example, from a copy of a message i received on this thread:
> 

Agreed.

> that's a comment, not just RFC 5321 :P

Yep.

> don't have as much in-depth knowledge of the RFCs as you do.

Agreed.

I don't know about other people, but I've found that it works both ways, 
people that know less about a topic can ask questions that stump people 
that know more about said topic.  I've worn both hats, many times.

Also keep in mind that some people (like myself) participate in this 
list / community to learn.  Not everybody is trying to steer things and 
make decisions.

Finally, please do not presume that people don't read RFCs.  I know that 
I've read many.  I retain many, but certainly not all, aspects of the 
RFCs that I've read.  I frequently need to go back and reference them. 
I know that I make mistakes more often than I'd like to know about.  I 
like to extend the courtesy to people to make similar mistakes and 
afford them the same opportunity to correct them that I'd like them to 
afford to me.

-- 
Grant. . . .
unix || die

---

From: Grant Taylor <[email-masked]>
Date: Mon, 14 Jan 2019 18:31:25 -0700

> Sigh.  Nope.

I agree with Daniel.

Remember that the page numbers are at the bottom of the page.

> Right.  As far as I can tell, it's there for symmetry with the FROM 
> clause where the first domain is the HELO/EHLO and the second is the 
> rDNS for the connecting IP.

I feel like both Domains in the From-domain and the By-domain are for 
different things:

From-domain = from $EHLO ($ReverseDNSofConnectingIP [$ConnectingIP])
By-domain = $ReceivingFQDN ($ReverseDNSofReceivingIP [$ReceivingIP])

> I don't think I've ever seen the second name used in the BY clause.

I haven't knowingly done so either.  But I'm tempted to re-configure my 
MTA to use my understanding of the By-domain.

> Wait a minute -- this is the UTA working group of the IETF.  The point 
> of this group is to revise and extend and update and write RFCs.  If 
> people can't be bothered to read the RFCs they're purportedly working 
> on, why are they here?

To learn from others?

To ask questions of the people in the know.  Questions that may make the 
people in the know second-guess themselves & their answers.

> I realize that some of the RFCs are long, but they have tables of 
> contents.  It's not hard to check the syntax of something rather than 

You listed three of more than 8 thousand RFCs.  Not everybody has read 
all (related) RFCs.  Not everybody can keep the fine minutia in their 
head.  They may even think they have the minutia and be wrong or simply 
misremember something and not realize it.

I'm guessing that most of the subscribers here are human.  As such, are 
subject to error.  Please allow them to (occasionally) do so and treat 
them like you would like to be treated if the situation was reversed.

-- 
Grant. . . .
unix || die

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2019 22:29:50 -0500

>than "the TCP connection".

The syntax of the Received header was defined in RFC 2821 in 2001 and
copied verbatim into 5321.  STARTTLS was added by RFC 3207 in 2002,
and SNI was added to TLS by RFC 3546 in 2003.*

When the ABNF about extended-domain was written with the comment about
info derived from the TCP connection, the TCP connection was
synonymous with the transport.  Now the transport is TCP plus STARTTLS
in various versions plus SNI, none of which was contemplated back in
2001.  I think it's reasonable to use extended-domain for info about
the underlying transport, even if the details are not strictly about
TCP.  After all, the rDNS name in the FROM extended-domain comes from
a DNS PTR lookup of the IP address which uses IP over UDP so it's
never been strictly about TCP.

R's,
John

* I spent five minutes looking this history up so as not to waste
other people's time.  It's not hard.

---

From: "John Levine" <[email-masked]>
Date: 14 Jan 2019 22:38:43 -0500

In article <[email-masked]>,
>Should we assume the same for a general MTA?

Good question but the answer is clearly yes.  

Message submission is defined as ESMTP with some minor rule changes
(e.g., the connection must be authenticated.)  Submission doesn't
change the rules for Received headers so any clauses defined for
submission received headers are also defined form SMTP and vice versa.

If you look at the IANA registry for received clauses, there's only
one registry, used for both submission and SMTP:

https://www.iana.org/assignments/mail-parameters/mail-parameters.xhtml#mail-parameters-8

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 14 Jan 2019 23:19:11 -0500

> never been strictly about TCP.

I agree with this reasoning -- the TCP-info ABNF doesn't even
contemplate a way to indicate source port, which it would if it was
trying to accurately describe a TCP session in detail specific to TCP.
It's about transport and routing ("how did the inbound MTA get here?"),
so it seems fair game for SNI.

  --dkg

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 14 Jan 2019 23:13:08 -0500

>> I'm sorry to spoil it for everyone that the word is "The" :P

Maybe you're reading a different RFC 5321 than i am.

https://tools.ietf.org/html/rfc5321#page-50 begins with:

     The reply text may be longer than a single line; in these cases the

If you'd like to share what you think it is, i'd be happy to learn from
you.  But i'm telling you my best interpretation of the RFC as i
understand it.  Anyway …

> connecting IP.  I don't think I've ever seen the second name used in the 

yep, it looks like it might even be an accident of some sort of ABNF
consolidation.  It's a good observation, and seems like a reasonable
place to slip in the SNI without needing any extra specifications for
now.

I do observe that in the presence of a single parenthetical aside
between the mandatory part of the BY clause and the next stated clause,
it's pretty hard to see how an interpreter can distinguish whether the
contents of the parenthetical is a TCP-info (part of the BY clause) or a
Comment (not part of the BY clause), particularly if it matches the ABNF
for TCP-Info.  That makes interpretation potentially ambiguous in the
most perverse corner cases.  Is this a TCP-info or a comment with a
weirdly-formatted timestamp:

 "(Postfix [19.01.14.23])"

Probably fine to interpret it as a a TCP-info since it matches the ABNF,
but it's still a little weird that the ambiguity can exist.

> they here?

I didn't ask you to not urge people to read the RFCs.  I asked you to be
gentler with people.  RFCs are written in an, um, peculiar form of
English, and ABNF itself is an even more peculiar communication style.
Not everyone has the same background in reading and interpreting these
things, and even those of us who are native English speakers and who
have years of experience reading this particular literary genre can come
to disagreements about things like, say, what the first line of page 50
actually says. :P

> I checked the syntax in RFCs 5321, 5322, and 8314 before I asked my
> question, and other people can too.

Sure, and people can look at examples that they have, and people can get
stuff wrong too.  We want *more* people to understand this stuff and
engage with the IETF on how to proceed, let's not drive off the folks
who are clearly trying to enagage helpfully. :) Your pointers to the
specific references and your explanation of how you expect to address
your implementation are both super helpful to the community here.
Claiming that you're the only one who reads the RFCs and claiming that
RFCs are obviously obviously comprehensible to anyone who tries to read
them, not so much.

When i commit my next public misinterpretation of an RFC on a mailing
list we share (it will happen!), i'm asking you nicely to please point
me in the right direction if you know it, with a minimum of eye-rolling
and harrumphing.  It's scary enough for newcomers to participate in
these lists, and we all have made mistakes here.

All the best,

    --dkg

---

From: Grant Taylor <[email-masked]>
Date: Mon, 14 Jan 2019 21:43:37 -0700

On 1/14/19 8:29 PM, John Levine wrote:
> info derived from the TCP connection, the TCP connection was synonymous 
> with the transport.

I don't accept that at face value.

IANA has UUCP defined as a VIA link type.  I highly doubt that it was 
added /after/ the TCP in 5321 (which you state is functionally a copy of 
2821).  Or even if it was posthumously added, I would expect there to be 
a reference to an RFC for it.  Seeing as how there isn't a reference, 
I'm going to believe that UUCP link types were around /before the TCP 
link type was defined in 5321 ~> 2821.  As such, I'm going to assert 
that UUCP link types were around (and still in use) when the ABNF about 
extended-domain was written.  As such, I don't agree that TCP 
connections were synonymous with the transport.

> Now the transport is TCP plus STARTTLS in various versions plus SNI,

I don't agree.  SMTP transport may be predominantly TCP (UUCP is still 
out there, as are some other more esoteric things).

Very simply the fact that we have on going efforts to add / require 
STARTTLS (MTA-STS and DANE-TLS come to mind) or bare TLS (SMTPS in one 
form or another) tells me that the current defacto transport does not 
/include/ STARTTLS.

> none of which was contemplated back in 2001.

I find that highly suspect.  I think that someone working on SMTP in 
2001 would have had some knowledge of ongoing STARTTLS work.  I'll 
concede that it was not enough or stable enough knowledge to influence 2821.

> I think it's reasonable to use extended-domain for info about the 
> underlying transport, even if the details are not strictly about TCP.

I'm going to disagree with you.  However that disagreement is more 
opinion and interpretation, which we obviously differ on.

> After all, the rDNS name in the FROM extended-domain comes from a DNS 
> PTR lookup of the IP address which uses IP over UDP so it's never been 
> strictly about TCP.

The "information derived by the server from (or about) the TCP 
connection" is independent of how the server derives said information. 
It is possible that the server used TCP for DNS, or NIS(+) via TCP, or 
via hosts file entries.  The method used to derive the information is 
immaterial of what the derived information is.  The RFC is concerned 
with what the information is, NOT how it was derived.

-- 
Grant. . . .
unix || die

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jan 2019 01:50:33 -0500

> On Jan 14, 2019, at 10:29 PM, John Levine <[email-masked]> wrote:
> 

To make sure that we're talking about the same thing, I want to check
that you're proposing:

   Received: from client.example.com (client.example.com [192.0.2.1])
     by mta.example.net (split-personality-sni.example.net [192.0.2.2])
     ...

where the "TCP-Info" in the "BY" clause records the SNI name?  Is that
right?  It is an interesting idea, but perhaps that boat had sailed
many decades ago?  Starting with Sendmail versions going back to at
least the mid 1980's, the "comment" after the "BY" clause has been
used primarily used to record the MTA software version, though usages
do very.  Here are some trace headers from a single message:

  Received: from zardoc.esmtp.org (zardoc.esmtp.org [75.101.48.117])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by mournblade.imrryr.org (Postfix) with ESMTPS id AB5307A3309
	for <[email-masked]>; Fri, 22 Jun 2018 16:30:20 +0000 (UTC)
	(envelope-from [email-masked])
  Received: from x2.esmtp.org (localhost. [127.0.0.1])
	by zardoc.esmtp.org (MeTA1-1.1.Alpha10.0) with ESMTPS
	(TLS=TLSv1.2, cipher=ECDHE-RSA-AES256-GCM-SHA384, bits=256, verify=OK)
	id S000000000033346B00; Fri, 22 Jun 2018 09:30:18 -0700
  Received: (from ...@localhost)
	by x2.esmtp.org (8.14.6/8.12.10.Beta0/Submit) id w5MGUIOU003106
	for [email-masked]; Fri, 22 Jun 2018 09:30:18 -0700 (PDT)

None of the "BY" clauses look like "TCP-Info".  Looking at Exim messages in
my mailbox, it puts no comments after "BY".  Only your messages from Qmail
seem to have transport related information int the comment following the
"BY" clause...

-- 
	Viktor.

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Jan 2019 11:49:22 +0000

> second domain name in the parens that nobody ever uses.

Hi, I'm nobody :-) Our mail servers populate the BY clause like

	BY servername (servicename [ipaddr])

The servers have different service personalities (e.g. MX vs submission)
depending on the IP address the client connects to. In Exim terms, the
ACLs vary per interface address, but the message routing after that point
is always the same.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Mull of Kintyre to Ardnamurchan Point: Southwesterly 5 to 7, occasionally gale
8 in north, veering westerly 6 to gale 8. Rough or very rough, but mainly
moderate in shelter. Occasional rain, squally showers later. Moderate or good,
occasionally poor.

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 15 Jan 2019 12:14:48 +0000

Hi Tony,

> ACLs vary per interface address, but the message routing after that point

Can you give some examples of "servicename"?

Are you suggesting that we add a new Received header field clause for 
recording TLS SNI (instead of [ab]using BY)?

Thank you,

Alexey

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 15 Jan 2019 09:52:01 -0500

> seem to have transport related information int the comment following the

the TCP-info and the Comment are distinct parenthetical clauses.  If you
read the ABNF from 5322 and 5321 closely, you can have both a
parenthetical TCP-info, followed by a parenthetical Comment.

So this is legitimate, afaict:

  Received: from bar.example.net (bar.example.net [192.2.0.156])
    with ESMTPS by foo.example.org (mx.example.org [192.2.0.15])
    (MailTransportAgentPro 1.2.1); Tue, 15 Jan 2019 09:49:30 -0500

The ambiguity comes in if there is exactly one parenthetical, and it
matches the ABNF for a TCP-info.  then it's not clear whether it was
intended as a TCP-info, or is a free-form comment that happened to
match.

    --dkg

---

From: Tony Finch <[email-masked]>
Date: Tue, 15 Jan 2019 14:53:19 +0000

> Can you give some examples of "servicename"?

A specific example is like:

Received: from mail.[snip]
    by ppsw-32.csi.cam.ac.uk (mx.cam.ac.uk [131.111.8.148]:25)
    with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256)
	[snip]

so ppsw-32 is the server that handled the message and mx.cam.ac.uk is the
name of the service it was providing (as opposed to smtp.hermes.cam.ac.uk
etc.)

> recording TLS SNI (instead of [ab]using BY)?

Not really, I'm just providing an example of how the TCP-info field can be
used.

The way we are using it is (I think) reasonably consistent with the idea
of putting the SNI in there. I'm getting the service name from the IP
address, and it's equally sensible to get it from the SNI. It's like
recapitulating the history of HTTP virtual hosting :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy: Cyclonic 5 at first in southeast, otherwise southwesterly 5 or 6,
veering northwesterly 5 to 7. Moderate in southeast, but moderate or rough,
occasionally very rough later, elsewhere. Rain or showers. Moderate or good.

---

From: "John R Levine" <[email-masked]>
Date: 15 Jan 2019 10:43:22 -0500

> recording TLS SNI (instead of [ab]using BY)?

To circle back to the original question, I am not opposed in principle to 
adding a new SNI clause.  But since it requires a published experimental 
or standards track RFC, that is a lot of work for something that may turn 
out not to be useful.

That why's I'll be using the BY name for now, and once we have experience 
with MTA-STS we'll have a better idea of what if anything else we should 
do.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jan 2019 11:05:49 -0500

> On Jan 14, 2019, at 5:39 PM, John Levine <[email-masked]> wrote:
> 
> now that RFC 8314 has defined the tls clause, why not put the data
> where the spec says?

Speaking of TLS handshake data in headers, while the "cipher" and
"group" are sufficient for TLS 1.2, where the cipher includes at
least the public key algorithm name.  They are noticeably inadequate
for TLS 1.3, because the cipher includes only the bulk encryption
algorithm and PRF, but not signature algorithm.  And there can be
two signature algorithms (one in each direction) when client certs
are in use.  And I like to log the RSA key bit size or ECDSA curve
name.  Hence the some elaborate Received header comment from the
upcoming Postfix release:

Only hte "TLS_AES_256_GCM_SHA384" and "X25519" parts are covered by
the RFC.  Don't whether anyone would care to formalize clauses for
the other parts...

-- 
	Viktor.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 15 Jan 2019 09:00:25 -1000

> On Jan 15, 2019, at 6:05 AM, Viktor Dukhovni <[email-masked]> wrote:
> 
> name.

That's a lot of information. How do we balance the privacy effect of volunteering that information versus the management benefits?

-- Christian Huitema

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jan 2019 14:27:28 -0500

> On Jan 15, 2019, at 2:00 PM, Christian Huitema <[email-masked]> wrote:
> 

The information is only available to readers of the message.
The fact the handshake used X25519 or ECDSA (P-256) does not
look sensitive to me.  An MSA can choose to not log it, while
MTA to MTA traffic really has nothing to hide here.

-- 
	Viktor.

---

From: "John Levine" <[email-masked]>
Date: 15 Jan 2019 15:53:48 -0500

No, I just can't count.  But you knew that.

>most perverse corner cases.

ABNF does not have to provide an unambigous parse, which often
confuses people.  You are correct that this could either be a TCP-info

>but it's still a little weird that the ambiguity can exist.

There's a lot of places where you need to use contextual clues to
figure out what's going on.  In this example, the fact that Postfix
doesn't contain a dot is a strong clue that it's not a domain name.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 15 Jan 2019 16:05:17 -0500

In article <[email-masked]> you write:
>where the "TCP-Info" in the "BY" clause records the SNI name?

Yup.

>	by mournblade.imrryr.org (Postfix) with ESMTPS id AB5307A3309

Ah, but they're not the same thing. The SNI string goes in the
tcp-info part of the extended-domain rule, but your (postfix) is just
a comment.  There's no IP address after the postfix so you can tell it's
not tcp-info.  "(zardoc.esmtp.org [75.101.48.117])" is tcp-info since
it's the correct syntax.

I realize all of this is hairsplitting and a reasonably good header
parser can look in all of the places where you might hide something,
but when possible I'd prefer to use the syntax we've got rather than
faking up something new.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 15 Jan 2019 22:21:43 +0000

> MTA to MTA traffic really has nothing to hide here.

Well, not until you get to ESNI and fingerprinting different
handshake instances as a way to track a message down a chain
of MTAs. If ESNI were used you'd likely not want to put any
SNI (or just some public/cover name in). As you add more info
about the TLS session, you also make it a little easier to
match the eventual mail (accessed via some later leak) with
recorded traffic. (I recall some of us being surprised that
DKIM signatures validated the leaked DNC mails, so we do
have real evidence that this kind of metadata can have
unexpected consequences.)

Not hard to handle though, probably a couple of simple statements
is all that'd be needed, e.g. to not add this information when
ESNI was used inbound, and to provide some configuration for
when and what to add, might be fine.

That said, I'm not clear on the actual purpose for adding this.
Other than tidiness, what's it really needed for? (I'm not
arguing against, just wondering in case it affects the analysis.)

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Jan 2019 18:21:48 -0500

> On Jan 15, 2019, at 5:21 PM, Stephen Farrell <[email-masked]> wrote:
> 
> of MTAs.

This is mail, not HTTP.  If you get to read the resulting
headers, the trace headers are all there.  So whatever your
concern was, it seems rather moot.

-- 
	Viktor.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 16 Jan 2019 09:22:32 -0500

> concern was, it seems rather moot.

I agree with Victor that what we're looking at in the headers is more
like the "inside" of the TLS tunnel, so there's not as much of a risk as
there would be on the outside of the message.

That said, Received: headers (and other e-mail headers) do have privacy
implications and it would be a mistake to wave them all away with "it's
not HTTP".  For example, some MSAs add a Received: header that
identifies the incoming IP address of the submitting MUA.  This can be
used by the recipient of the message to learn where on the network the
message sender was when they sent the message. This is probably not a
good thing in terms of privacy from the user's perspective, and MSAs
probably should not be doing it.

Whether the SNI used by an incoming client falls in the same category is
a different question, of course.

    --dkg

---

From: "Chris Newman" <[email-masked]>
Date: Wed, 23 Jan 2019 15:55:54 -0800

On 14 Jan 2019, at 20:43, Grant Taylor wrote:
>> When the ABNF about extended-domain was written with the comment 
>> about info derived from the TCP connection, the TCP connection was 
>> synonymous with the transport.
>
> added /after/ the TCP in 5321 (which you state is functionally a copy 
> of 2821).  Or even if it was posthumously added, I would expect there 
> to be a reference to an RFC for it.  Seeing as how there isn't a 
> reference, I'm going to believe that UUCP link types were around 
> /before the TCP link type was defined in 5321 ~> 2821.  As such, I'm 
> going to assert that UUCP link types were around (and still in use) 
> when the ABNF about extended-domain was written.  As such, I don't 
> agree that TCP connections were synonymous with the transport.
>

Yes, we knew about STARTTLS, but we didn't understand the 
impact/consequences of SNI back then. The DRUMS WG charter also 
prevented the addition of new features outside specifically identified 
exceptions (e.g., IPv6). Without that restriction, I doubt we could have 
completed RFC 2821 & RFC 2822.

I think it would be very useful to write an RFC that changes the 
registry for fields in the received header to an "expert-review 
registry", and also adds an SNI field. Then it would subsequently be 
easy to add new received fields. The overuse of comments in Received 
headers suggests the strict registry classification for Received headers 
was a design error, just as the overuse of X- headers in email led to 
publication of RFC 3864 which loosened the rules and RFC 6648 which 
discouraged the naming wart.

		- Chris

>> PTR lookup of the IP address which uses IP over UDP so it's never 
>> been strictly about TCP.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

---

From: "John Levine" <[email-masked]>
Date: 23 Jan 2019 20:33:53 -0500

>completed RFC 2821 & RFC 2822.

Since the first SNI code for OpenSSL was written in 2004, and it
wasn't added to production version until 2007, I'd say it's excusable
that you didn't mention it in RFCs published in 2001.

Also, until MTA-STS came along there was little reason to expect the
mail server's cert to match the name the client used to find it.
Until fairly recently, most STARTTLS certs were self-signed since
there was no benefit to paying a CA to sign them.

>registry", and also adds an SNI field. ...

Excellent idea.

R's,
John