Subject: [Uta] New Version Notification for draft-levine-additional-registered-clauses-00

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

Apropos of recent discussions about SNI logging, here's a draft that adds 
an SNI clause to Received: headers, and per Chris Newman's suggestion, 
changes the registry criteria to Expert Review so you don't need to 
publish an RFC merely to register a new clause.

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

---------- Forwarded message ----------
Date: Thu, 24 Jan 2019 14:44:52
From: [email-masked]

A new version of I-D, draft-levine-additional-registered-clauses-00.txt
has been successfully submitted by John Levine and posted to the
IETF repository.

Name:		draft-levine-additional-registered-clauses
Revision:	00
Title:		Update to Additional Registered Clauses in SMTP Received Headers
Document date:	2019-01-24
Group:		Individual Submission
Pages:		4
URL:            https://www.ietf.org/internet-drafts/draft-levine-additional-registered-clauses-00.txt
Status:         https://datatracker.ietf.org/doc/draft-levine-additional-registered-clauses/
Htmlized:       https://tools.ietf.org/html/draft-levine-additional-registered-clauses-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-levine-additional-registered-clauses

Abstract:
    SMTP servers add Received: trace headers to mail messages to track
    their progress This document updates the registration criteria for
    Additional Registered Clauses in those headers to Expert Review, and
    adds a new clause for Server Name Indication (SNI).

---

From: "Kurt Andersen (b)" <[email-masked]>
Date: Thu, 24 Jan 2019 10:26:05 -1000

> publish an RFC merely to register a new clause.

The second paragraph trails off with an incomplete sentence.

Otherwise this looks eminently reasonable.

--Kurt

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Jan 2019 20:26:38 +0000

Spec required, so it's written down somewhere what it means?  An I-D is sufficient; you don't have to go through RFC publication.  Or will these things be "intuitively obvious" ?

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 24 Jan 2019 21:41:11 +0000

I suggest calling out ESNI specifically as a reason to not log the
SNI in the security considerations, e.g. via:

OLD:

   In a few
   circumstances, a new Additional-registered-clause might disclose
   information to a recipient that was otherwise unavailable.

NEW:

   In a few
   circumstances, a new Additional-registered-clause might disclose
   information to a recipient or other actor (via data leaks) that
   was otherwise unavailable. In particular, if the SNI value was
   encrypted in the TLS handshake [ESNI] then logging is NOT
   RECOMMENDED.

[ESNI] would point at draft-ietf-tls-esni

Even if this isn't a big leak, I think it's still worth preserving
a way in which SNIs don't leak - if the TLS client and server and
TLS client's DNS setup (and maybe the TLS server's too) are all
such that we've not leaked the SNI in any of those places then I
think we're better off if we can avoid leaking it here.

There have been real data leaks of mails where metadata like
this has been revealing [1] and we can't tell in general if some
new bit of data might be correlated with something else later.

Cheers,
S.

[1] https://labs.rs/en/metadata/

On 24/01/2019 19:56, John R Levine wrote:
> Apropos of recent discussions about SNI logging, here's a draft that
> adds an SNI clause to Received: headers, and per Chris Newman's
> suggestion, changes the registry criteria to Expert Review so you don't
> need to publish an RFC merely to register a new clause.
> 
> Regards,
> URL:           
> https://www.ietf.org/internet-drafts/draft-levine-additional-registered-clauses-00.txt
> 
> Status:        
> https://datatracker.ietf.org/doc/draft-levine-additional-registered-clauses/
> 
> Htmlized:      
> https://tools.ietf.org/html/draft-levine-additional-registered-clauses-00
> Htmlized:      
> https://datatracker.ietf.org/doc/html/draft-levine-additional-registered-clauses
> 
> 
> 
> Abstract:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: John C Klensin <[email-masked]>
Date: Thu, 24 Jan 2019 18:20:24 -0500

--On Thursday, January 24, 2019 20:26 +0000 "Salz, Rich"
<[email-masked]> wrote:

> Spec required, so it's written down somewhere what it means?
> An I-D is sufficient; you don't have to go through RFC
> publication.  Or will these things be "intuitively obvious" ?

Rich,

As I have always understood it, "spec required" means a
published, stable, readily-accessible, etc., specification.
Not necessarily an RFC but, until the definition of an I-D is
changed to eliminate all of the "don't reference except as 'work
in progress'" and "expires in six months" stuff, it would be
unusual (and objectionable) for posting a spec as an I-D to
qualify.

   john

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 24 Jan 2019 23:41:39 +0000

The TLS expert group, in agreement with the Security AD's, did exactly this.  Start your objections. :)

---

From: "John R Levine" <[email-masked]>
Date: 24 Jan 2019 20:31:44 -0500

I don't suppose you guys could look at the "Guidance for Designated 
Expert" in the draft and let me know if you have improvements?

Regards,

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Jan 2019 01:44:30 +0000

It looks fine to me except for the :"recommeneded" typo :)

---

From: "John R Levine" <[email-masked]>
Date: 24 Jan 2019 21:37:05 -0500

> think we're better off if we can avoid leaking it here.

Since this is mail, I would expect that in the vast majority of cases, the 
SNI will be the host name in the MX record of the recipient's domain, 
which the recipient already knows. It's not like the web where requests 
can come unsolicited from anywhere.  If a domain has multiple MXes, the IP 
address of the mail server is already in the Received header so it's not 
hard to triangulate.  The main thing the SNI clause tells you is whether 
the client used SNI at all.

We could have a larger discussion about redacting SMTP trace headers, but 
not in this tiny I-D, please.

Regards,

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 25 Jan 2019 10:45:30 +0000

Hi all,

> The TLS expert group, in agreement with the Security AD's, did exactly this.  Start your objections. :)

I don’t think there is universal agreement with IESG that I-Ds qualify. So you might need to talk to your AD ;-).

Best Regards,
Alexey

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Jan 2019 10:52:02 +0000

On 25/01/2019 02:37, John R Levine wrote:
> Since this is mail, I would expect that in the vast majority of cases,
> the SNI will be the host name in the MX record of the recipient's
> domain, which the recipient already knows. It's not like the web where
> requests can come unsolicited from anywhere.  If a domain has multiple
> MXes, the IP address of the mail server is already in the Received
> header so it's not hard to triangulate.  The main thing the SNI clause
> tells you is whether the client used SNI at all.

Your assumptions may or may not hold. The MTA can't tell. But it
can tell that ESNI was used. (Well, it's likely a TLS stack that
does ESNI will provide a way for the application to know ESNI was
used, but not certain.)

(Aside; I'd have no objection if "SNI=yes" was logged without
the name. Or "ESNI was used" or similar.)

> 
> We could have a larger discussion about redacting SMTP trace headers,
> but not in this tiny I-D, please.

I agree. This discussion is about making a minor new logging
feature appropriately reflect how folks have configured their
systems, which is entirely relevant to this tiny I-D.

Cheers,
S.

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2019 10:00:17 -0500

> does ESNI will provide a way for the application to know ESNI was

Having added SNI to my MTA last week, I can say the MTA can definitely 
tell unless you have an extremely exotic design.  TLS stacks don't do 
certificate management, applications do.

In the pre-SNI case, the application sets up a context with the 
certificate and key and hands it to the TLS stack when it starts the 
handshake.  For SNI, the stack calls back into the application with the 
SNI string, and the application finds a matching certificate and key to 
return to the stack so if can finish the handshake.  If you look at web 
servers, the SNI cert file information is in with the rest of the server 
config so that's how it works there, too.  I also did a prototype MTA-STS 
policy file server, same deal.

More to the point, though, I think you're overlooking two fundamental 
differences between SNI in SMTP and in HTTP.  On the web, only the client 
making the request knows what web page she's looking for, and the log info 
is saved on the server where random presumably hostile third parties can 
look at it.  In mail, neither of those are true.

By the nature of e-mail, the recipient of a message already knows who the 
sender sent it to, since he or she got it.  The Received headers go into 
the message itself, not third party logs.  So the recipient knwos her MXes 
and the SNI doesn't tell her anything new about where the mail went to or 
from.  Even if you add forwarding scenarios, the existing trace info is 
enough to tell what addresses the mail was forwarded through and again SNI 
adds nothing new.

> the name. Or "ESNI was used" or similar.)

I wouldn't be opposed to adding that as an option, but I would not agree 
that it would make a meaningful security difference.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Jan 2019 15:48:03 +0000

Hiya,

On 25/01/2019 15:00, John R Levine wrote:
> differences between SNI in SMTP and in HTTP.  On the web, only the
> client making the request knows what web page she's looking for, and the
> log info is saved on the server where random presumably hostile third
> parties can look at it.  In mail, neither of those are true.
> 
> By the nature of e-mail, the recipient of a message already knows who
> the sender sent it to, since he or she got it.  The Received headers go
> into the message itself, not third party logs. 

Mail list archives and mail corpus leaks do expose that to more
than one recipient.

> So the recipient knwos
> her MXes and the SNI doesn't tell her anything new about where the mail
> went to or from.  Even if you add forwarding scenarios, the existing
> trace info is enough to tell what addresses the mail was forwarded
> through and again SNI adds nothing new.

I think your argument above is more to the effect that ESNI isn't
so compelling for SMTP, and I'd agree that's reasonable.

But, if someone has decided to setup ESNI for an MTA (which will
need them to take action to do that), then I'd assume they have
a reason. At that point, exposing the ESNI value in the message
is what I'm arguing to not recommend.

> that it would make a meaningful security difference.

If we agreed on a statement like "If ESNI was used then just
log the fact of usage and not the value" then I'd be fine.
I guess it'll be a rare enough case but I do think it's safer
as this new field is less likely to cause an unpleasant
surprise for someone for whom it turns out that using ESNI in
SMTP is a good plan.

Cheers,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Jan 2019 15:48:58 +0000

>    I don’t think there is universal agreement with IESG that I-Ds qualify. So you might need to talk to your AD ;-).

It would be really good if the IESG could decide on this; IANA registry requirements shouldn't vary by individual.

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2019 11:36:22 -0500

> Mail list archives and mail corpus leaks do expose that to more

Indeed, but unless they remove the Received: headers (in which case this 
debate is irrelevant) they also expose the recipient and so forth.

To the extent that list archives have those headers, they disclose the 
address of the list and perhaps an internal address used to forward mail 
from the list to the archive.  BFD, I'd think.  The corpora I've seen have 
no Received headers and the addresses in From/To/CC redacted, too.

> is what I'm arguing to not recommend.

Naah, it just means they upgraded to a new library version that supports 
it.

Here's a thought experiment: try and construct a plausible Received header 
that would tell you more about the recipient with SNI than without, 
keeping in mind that the IP address of the server is mandatory, and the 
server name and recipient (the "for" clause) are usually included.  I 
think you'll find it's quite hard unless you do things that MTAs don't 
normally do.

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Jan 2019 16:47:07 +0000

> Naah, it just means they upgraded to a new library version that supports

No. That's not how ESNI works with the current draft, nor
how I guess it'll evolved. The TLS server (MTA in this case)
has to publish a key share and other stuff in the DNS for
ESNI to work and has to keep the DNS content and TLS server
config in-whack. So merely upgrading a library won't turn on
ESNI, it needs specific action from some admin-like being.

> Here's a thought experiment: try and construct a plausible Received
> header that would tell you more about the recipient with SNI than
> without, keeping in mind that the IP address of the server is mandatory,
> and the server name and recipient (the "for" clause) are usually
> included.  I think you'll find it's quite hard unless you do things that
> MTAs don't normally do.

If an MTA acts for loads of domains on one IP address using
different certificates via ESNI where the names in those
certificates aren't easily mapped to other message content.
I'm not claiming that'd be highly sensitive but it does
answer your question as more information is revealed. (If
more information were not revealed then you'd not even want
this new header field value, right?)

Again though I am not arguing for widespread use of ESNI in
SMTP here, just that if someone has decided to use ESNI, we
don't unexpectedly leak the value that they've chosen to try
not expose.

Cheers,
S.

---

From: "John R. Levine" <[email-masked]>
Date: 25 Jan 2019 11:50:23 -0500

> ESNI, it needs specific action from some admin-like being.

Ah, I should take another look.  But I still don't think it matters 
because ...

> certificates aren't easily mapped to other message content.

The cert names are tied to the MX which is tied to the recipient.  If you 
know the recipient, which you do in nearly every situation where there's 
Received headers, game over regardless of how the SNI is communicated.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Jan 2019 16:55:09 +0000

On 25/01/2019 16:50, John R. Levine wrote:
> 
> The cert names are tied to the MX which is tied to the recipient. 

Says who? That's common and sensible but not mandatory.

The cert names could be all sorts of flakey things, incl
having wildcards. E.g. ESNI could be "secret.example.com"
while the cert name is "*.example.com" and there are many
more variations possible (too many, but that's another
day's work;-)

S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Jan 2019 17:04:56 +0000

Yes, the ESNI attribute should be present/not-present and not the actual value.

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2019 12:15:05 -0500

> Yes, the ESNI attribute should be present/not-present and not the actual value.

How about this?

  sni domain.name
  esni yes

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Jan 2019 17:18:57 +0000

>  esni yes

Works for me. With the "esni yes" otpion as a SHOULD level thing,
a MUST is maybe too much (just in case the MTA code can't determine
that ESNI was used).

Thanks,
S.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 25 Jan 2019 17:20:19 +0000

>      esni yes
 
Works for me.

(Stephen's right about ESNI and its use of DNS BTW)

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2019 13:08:35 -0500

I've uploaded a new version that reflects the recent discussions.

Because I am a grumpy old guy I will not tell you what it says so if you 
want to know, you will have to read all four pages of it:

Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 25 Jan 2019 21:38:56 +0000

Hiya,

> want to know, you will have to read all four pages of it:

Sorry to have made you (more:-) grumpy, but I'm not sure that's
quite there. Easily fixed though.

> https://datatracker.ietf.org/doc/draft-levine-additional-registered-clauses/

1. In section two it'd be clearer I think if you explain that
"sni" and "esni" aren't meant to both be in the same line (or
however that's best said), but are alternatives. Or, if that's
not what you meant then you'd need to say what you did mean.
(Or it might be even simpler to go back to one new thing called
"sni" followed by either a domain name or by the string "esni")

2. The new text in s4 is wrong, a mail server will generally
have access to the value from ESNI or the h/s will likely fail,
and the TLS server will treat that as the SNI to use for server
certificate selection. The issue isn't that the server can't
see the ESNI value, just that it oughtn't pass it on. So for
example you might do this:

OLD:

   If the SNI information in a STARTTLS negotiation is exchanged in
   encrypted form [ESNI] a mail server would generally not have access
   to the SNI, and can only log that ESNI was used.

NEW:

   If the SNI information in a STARTTLS negotiation is exchanged in
   encrypted form [ESNI] a mail server SHOULD only log that ESNI was
   used, and not the actual name used.

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 25 Jan 2019 17:11:09 -0500

> On Jan 25, 2019, at 4:38 PM, Stephen Farrell <[email-masked]> wrote:
> 

Yes, to the extent that mail servers are at all likely to implement
support for ESNI on both ends of the connection (I don't expect to
do that in Postfix any time soon), the receiving system would still
primarily be working with the "decrypted" SNI.  So indeed the text in:

 4. Security Considerations

   [...]

is due to an incomplete understanding of (the yet to be specified) ESNI.

Like John, I am very skeptical about the applicability of ESNI to SMTP.
The sender's MSA is generally stable over long time scales, and is easily
deduced from the sender's email address.  The names of SMTP relays have
little bearing on user privacy.  If one is to make a priority of sender
privacy, one would focus on not recording the submission IP address.
Hiding the well known MSA or SMTP relay name is not worth the trouble.

-- 
-- 
	Viktor.

---

From: [email-masked]
Date: Fri, 25 Jan 2019 15:42:05 -0800 (PST)

> [ESNI] would point at draft-ietf-tls-esni

I don't see how this recommendation makes sense given the stated goals
of ESNI. As I understand it, the goal of ESNI is to keep observers of
the TLS connection from being able to determine the server identity via the
SNI information exchange, especially in cases where this is sensitive
information.

This does seem like something you'd want to do SMTP, given that there are an
adundance of servers out there handling many domains with multiple identities.

However, the draft also says:

   The design in this document takes a different approach: it assumes
   that private origins will co-locate with or hide behind a provider
   (CDN, app server, etc.) which is able to activate encrypted SNI
   (ESNI) for all of the domains it hosts.  Thus, the use of encrypted
   SNI does not indicate that the client is attempting to reach a
   private origin, but only that it is going to a particular service
   provider, which the observer could already tell from the IP address.

And this seems applicable as well, since MTAs handling traffic from many
clients is the rule, not the exception.

But the "hide in plain sight" aspect of this means that ESNI needs to be used
for everything on a given server, not just in cases where the domain needs to
be kept private. So if ESNI deploys in SMTP according to this model, it may
erase many/most of the benefits of this draft.

(I note that in SMTP the hide in plain sight aspect might be better implemented
by having shared MX host names between private and public domains - no need to
wait for TLS extension to be fully fleshed out and deploy.)

This limitation might be acceptable if the security considerations for on-wire
exposure are the same as for trace fields. But AFAICT they aren't even close to
comparable. With trace fields the risk is that they can potentially betray the 
message's origins and transfer history to anyone who subsequently sees the
message. These concerns apply regardless of whether or not ESNI is used - and
remember that ESNI won't be available in SMTP for quite a while, if ever.

I think the better approach here is to say that SNI logging adds to the
information about the message's origins and history, and the same
considerations as to whether or not to include things like server IPs also
apply to SNI information.

As to whether or not ESNI is used, I actually think logging that is a bad idea,
as it doesn't really any anything useful that I can see and less is more when
it comes to this sort of stuff.

				Ned

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 26 Jan 2019 00:53:46 +0000

Hiya,

> Like John, I am very skeptical about the applicability of ESNI to

I also agree with John and you that ESNI doesn't seem compelling
for SMTP. Nonetheless, I'm often wrong, and maybe in this case too,
so if ESNI is seen to be used then handling it conservatively seems
wiser.

> The sender's MSA is generally stable over long time scales, and is
> easily deduced from the sender's email address.  The names of SMTP
> relays have little bearing on user privacy.

Yes. ISTM the ESNI discussion in this thread is more about "least
surprise" and not really directly about privacy.

> If one is to make a priority of sender privacy, one would focus on
> not recording the submission IP address. 

That is an interesting topic - if there were energy enough for trying
to really tackle (re-)balancing the various trade-offs in mail metadata
handling that have historically not really considered privacy, then
that'd be great. Part of that is the general topic John mentioned
earlier about redacting information in mail header fields. TBH, I'd
be surprised but happy if folks had the energy for that, but I'm also
pretty sure that'd deserve it's own thread, then mailing list and,
maybe WG:-)

> Hiding the well known MSA or
> SMTP relay name is not worth the trouble.

Partly agree. Not exposing it after the MTA admin has chosen to try
hide it is IMO worth a well-crafted sentence in John's draft and a
handful of lines of code.

Cheers,
S.

---

From: [email-masked]
Date: Fri, 25 Jan 2019 16:43:24 -0800 (PST)

> keeping in mind that the IP address of the server is mandatory,

First, I don't think that's the case. But even if it is, how about a server
servicing multiple domains, some sensitive and some not, and each domain set up
with different MX records?

I'll also note that servers often omit or obfuscate IP address information for
security reasons, irrespective of what the standards say.

> and the

Actually I'm seeing fewer and fewer for clauses over time. But regardless,
as I noted in my previous message, the security considerations of including
SNI information aren't really separable from the security considerations
of what to include in trace fields in general, and don't obviously
align with whether or not ESNI is used.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 25 Jan 2019 22:02:55 -0500

> apply to SNI information.

Seems reasonable.  In the usual case that you can tell who the recipient 
of the message was, does the MX name or SNI or ESNI tell you anything of 
interest that you didn't already know (other than that the client does 
SNI?)  I'm having trouble thinking of a plausible case.

Regards,

---

From: [email-masked]
Date: Fri, 25 Jan 2019 19:45:45 -0800 (PST)

> SNI?)  I'm having trouble thinking of a plausible case.

The case that comes to mind is some sort of alias or list the message passed
through. It might be smart enough to edit the other stuff out of the Received:
field but not the SNI information.

				Ned

---

From: "John R Levine" <[email-masked]>
Date: 26 Jan 2019 12:40:00 -0500

After reading all the discussion I posted an -02 which takes out all 
mention of ESNI.  Here's why.

The most important issue is process.  ESNI is currently described only in 
an early I-D which will not turn into an RFC for a long time.  If I 
reference it, this draft will be stuck behind ESNI, also for a long time. 
If I don't, this draft should be able to progress quickly.  Once it's 
published, if you want to add an ESNI clause, you can do so by expert 
review, no RFC needed.

More substantively, I would be surprised if any MTA ever implements ESNI 
because it makes no sense for mail.  On the web, different hostnames lead 
to different web sites, and clients expect the name in the TLS cert to 
match the hostname in the request.  In mail, we've never expected the name 
of the MTA to match the domain of the recpient, and it is quite normal for 
a million different domains to point their MXes at the same host with the 
same name, e.g. aspmx.l.google.com.

If you don't want your SNI to give anything away, you just do what mail 
systems have done all along, use the same MX names for everyone.  There's 
no problem for ESNI to solve and certainly no reason to go to the effort 
to put all the ESNI glop in the DNS.

Regards,

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 26 Jan 2019 13:07:29 -0500

> On Jan 26, 2019, at 12:40 PM, John R Levine <[email-masked]> wrote:
> 
> After reading all the discussion I posted an -02 which takes out all mention of ESNI.  Here's why.
> 
> More substantively, I would be surprised if any MTA ever implements ESNI because it makes no sense for mail.  On the web, different hostnames lead to different web sites, and clients expect the name in the TLS cert to match the hostname in the request.  In mail, we've never expected the name of the MTA to match the domain of the recpient, and it is quite normal for a million different domains to point their MXes at the same host with the same name, e.g. aspmx.l.google.com.
> 
> If you don't want your SNI to give anything away, you just do what mail systems have done all along, use the same MX names for everyone.  There's no problem for ESNI to solve and certainly no reason to go to the effort to put all the ESNI glop in the DNS.

Sure, works for me.

-- 
	Viktor.

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 26 Jan 2019 19:08:10 +0000

Hiya,

As is probably obvious I don't agree with this. But I can raise
it when the draft gets to IETF LC, so we don't need to bang on
about it.

On 26/01/2019 17:40, John R Levine wrote:
> The most important issue is process.  ESNI is currently described only
> in an early I-D which will not turn into an RFC for a long time.  If I
> reference it, this draft will be stuck behind ESNI, also for a long
> time. If I don't, this draft should be able to progress quickly.  Once
> it's published, if you want to add an ESNI clause, you can do so by
> expert review, no RFC needed.

An informative reference is all that'd be needed and wouldn't hold
up your draft at all. The above is bogus unless you make the ESNI
I-D a normative reference, which a) you didn't do in the -01 draft
and b) isn't needed as you wanted to avoid 2119 terms.

> because it makes no sense for mail.  On the web, different hostnames
> lead to different web sites, and clients expect the name in the TLS cert
> to match the hostname in the request.  In mail, we've never expected the
> name of the MTA to match the domain of the recpient, and it is quite
> normal for a million different domains to point their MXes at the same
> host with the same name, e.g. aspmx.l.google.com.
> 
> systems have done all along, use the same MX names for everyone. 
> There's no problem for ESNI to solve and certainly no reason to go to
> the effort to put all the ESNI glop in the DNS.

I don't accept the above paras demonstrate sound logic, but we can
debate it when you get to IETF LC.

Cheers,
S.

---

From: [email-masked]
Date: Sat, 26 Jan 2019 11:00:51 -0800 (PST)

> published, if you want to add an ESNI clause, you can do so by expert

I agree this is the most important issue, and is more than sufficient to
preclude mentioning it, but even if ESNI was to progress tomorrow and mail
systems were to implement it, I think there's a compelling case not to log its
use in trace fields.

> to put all the ESNI glop in the DNS.

I suggested this approach in an earlier response. But the counterargument was
that you can't assume any particular certificate naming model for SMTP in
general. I think that's a stretch, but once again even if it were true and ESNI
were to deploy to address some case we're missing in mail, I don't
think we can assume that any future use of ESNI would necessarily
correlate with whether or not to put SNI information in trace fields.

				Ned

---

From: "Chris Newman" <[email-masked]>
Date: Mon, 28 Jan 2019 18:30:13 -0800

On 24 Jan 2019, at 11:56, John R Levine wrote:
> suggestion, changes the registry criteria to Expert Review so you 
> don't need to publish an RFC merely to register a new clause.

I have some different comments about this. Sometimes thinking through 
the consequences of a seemingly simple suggestion makes it less 
simple... Sorry 'bout that.

1. I don't believe a stable reference should be required. In many cases, 
a single paragraph of text that can live in the IANA registry is 
sufficient to precisely document the semantics of a Received clause. The 
expert reviewer can validate if the provided text is sufficient. If 
references are provided, it's desirable for them to be stable, but I 
don't see why it should be a strict requirement -- we don't have such a 
requirement for vendor/private media types and having those types 
registered provides benefits to the community even without a stable 
reference.

2. The "additional registered clauses" is presently a sub-registry of 
the "Mail Transmission Types" registry within the "mail parameters" 
registry category. I suggest we rename this to "additional registered 
Received clauses" and make it a top-level registry in the "mail 
parameters" category -- this should make it easier to find on the 
iana.org web page.

3. Rather than having to go read section 8 of RFC 5321 to know how to 
register one of these, I suggest we copy the text from that section 
relevant to this registry so it's all in one specification.

4. The expert reviewer should verify that the syntax of the clause value 
is well-defined and complies with the "received-token" syntax in RFC 
5322.

5. Noting an appropriate mailing list where public review of a proposal 
is appropriate can be helpful for expert review registration procedures.

6. I believe a consequence of making the registry expert review rather 
than IESG action is that we should add an item to the registration 
template of "privacy/security considerations". I believe the discussions 
the media types reviewer has with the authors of media type 
specifications have a generally positive effect on the resulting 
technology and are much less of a burden than a full standards process. 
I recommend using text from the media types registration procedures (RFC 
6838 section 4.6) as a starting point.	

7. Unfortunately, the perspective the IETF (and the industry) has 
towards privacy/security considerations has evolved since the 
considerations in RFC 2821 / 5321 were written. As a result, I think RFC 
5321 section 7.6 is no longer adequate by itself. I think this document 
is a good place to provide the additional security considerations for 
Received headers that weren't covered in that section.

Here's a first attempt:

===
Additional Security Considerations for trace Headers

The security considerations in section 7.6 of RFC 5321 are updated to 
include this additional information:

Trace information in email headers is normally disclosed when stored 
email is disclosed. Stored email has additional attack vectors that are 
not present for in-transit email. As a result, information in trace 
header fields that would not otherwise be available to the recipient of 
the email, such as the domain and IP address of hosts involved in the 
transfer, may have privacy implications. On the flip side, compromised 
client accounts, abuse, and phishing (as defined in RFC 5901) are 
serious security threats for email. As a result, server software is 
encouraged to provide configuration settings such that privacy-sensitive 
service providers can hide more information and attack-sensitive service 
providers can record more information in trace headers.

The source host and IP address of the initial submission client can be 
particularly sensitive from a privacy perspective. A submission server 
[RFC 6409] SHOULD offer an operational mode such that the mandatory 
"from" clause contains "omitted.invalid" as the domain name, the IP 
address is omitted from the "from" clause, and the ID clause contains an 
identifier that can be used to retrieve that information from server 
logs for the server's configured log retention period when necessary to 
mitigate abuse attacks, compromised client credentials, or similar 
attacks. The identifier used for this purpose should be generated using 
a mechanism, such as a secure hash function, that does not disclose 
additional information.
===

other suggestions/word-smithing are welcome.

I'm opposed to having any discussion of ESNI in this document prior to 
the publication of an ESNI RFC. One option to reduce the controversy 
would be to simply remove the SNI-related clauses from this RFC and make 
them the first exercise of the new registration process.

		- Chris

---

From: "John R Levine" <[email-masked]>
Date: 28 Jan 2019 22:59:37 -0500

> I have some different comments about this. Sometimes thinking through the 
> consequences of a seemingly simple suggestion makes it less simple... Sorry 
> 'bout that.
>
> 1. I don't believe a stable reference should be required. ...

See section 3.1 of the draft, and if it's not right, please send text.  It 
currently says (among other things):

    The Designated Expert is expected to check that a proposed
    Additional-registered-clause has a specification that is stable and
    detailed enough to implement the clause and interoperate.

> 2. The "additional registered clauses" is presently a sub-registry of the 
> "Mail Transmission Types" registry within the "mail parameters" registry 
> category. I suggest we rename this to "additional registered Received 
> clauses" and make it a top-level registry in the "mail parameters" category 
> -- this should make it easier to find on the iana.org web page.
>
> register one of these, I suggest we copy the text from that section relevant 
> to this registry so it's all in one specification.
>
> 4. The expert reviewer should verify that the syntax of the clause value is 
> well-defined and complies with the "received-token" syntax in RFC 5322.
>
OK with me if it's OK with everyone else.

> 5. Noting an appropriate mailing list where public review of a proposal is 
> appropriate can be helpful for expert review registration procedures.

Wouldn't that go in the registry page?

Regards,