This is one way to frame the problem. Another is that TLS is (1)
typically only authenticated on the server side and (2) not
cryptographically bound to the IP or port, the combination resulting in
potential cross-protocol attacks. We as a community (inclusive of all
protocols) are trying to mit
YS: some of the attacks do not depend on the client executing JavaScript, but
rather on the use of cookies (bearer tokens) which can be
intercepted/logged/uploaded on the server side. I don't know of bearer tokens
being used in SMTP, but it doesn't look like an HTTP-only notion.
Mail sessions
On Thu, 23 Jun 2022, Peter Saint-Andre wrote:
- section 3.2: I wondered why no mention of MTA-STS or
DANE? Could/should we say that MTA implementations
SHOULD include support for such strictness?
Hi John, thanks for sharing these insights. I'll reach out to a few Comcast
colleagues reg
By contrast, unsigned TLSA records offer essentially zero security.
If they're not signed, sure.
That's not what concerns me. What concerns me is whether all of those mail
domains would permit such updates. This draft doesn't define an API for
posting or updating such information, but we'
But it has to be signed by a CA. If the CA is not happy for you to assert
SRV-ID, it should not include SRV-ID in an issued certificate.
Now I'm really confused. Are you saying the SRV-ID is optional? If so,
what's the point of it? In nearly all cases, there's no way for a CA to
tell what S
Given that there are mail services with tens of thousands of domains
on the same set of servers, and probably at least one mail service
with 100,000 domains, this really doesn't scale.
Yes, I can add a note about this. Also recommending use of SNI (case 1) might
be a good idea.
If there's no SR
If there's no SRV-ID, you don't need SNI since all 100,000 domains point at
the same server name.
Yes, but then they can't be verified automatically by MUAs, so each of them
would need to be approved manually by users.
Aren't we back to RFC 6186? If the MUA developers are going to open up
the
Cool, thanks for sharing that, John.
I should note that even we are considering fetching these policies from
outside the MTA, so a script like this running in its own cron job against
the last hour's unique domains could be a totally viable option. I offer
this for those who were reluctant to ope
People have beens mailing around vast numbers of DMARC reports, most
of which have an application/gzip body. If there have been attacks
using DEFLATE bugs, nobody's gotten around to reporting them.
I'm not much worried about attacks on DEFLATE and SMTP traffic. But as I
understand from the dra
"The PUT method requests that the enclosed entity be stored under the
supplied Request-URI. If the Request-URI refers to an already existing
resource, the enclosed entity SHOULD be considered as a modified version of
the one residing on the origin server. "
Seems like it would require the reporte
h the same in that case, unless we
require cert validation (which strikes me as pointless if we allow
plaintext SMTP).
Random CNAMEs and SNI play poorly together. Might as well just use the
TXT record to point people at the real name of the server.
R's,
John
On Thu, May 5, 2016 at 1:01 P
Random CNAMEs and SNI play poorly together. Might as well just use the
TXT record to point people at the real name of the server.
Heh. But in this case we don't really need HTTPS (or any validation), since
the SMTP reports can be sent without validation (or so we have all said, I
think).
I su
Ask you the package maintainer of your favourite distro to update in time.
Distro? Largish mail systems tend to use commercial software, which
updates when it updates. You mght want to talk to the people who maintain
Port25 and Communigate and MDaemon and MS Exchange and see what their
sche
I figure GMail and Yahoo run their own implementation, whereas large ESPs I've
seen do indeed run open-source products on commodity hardware.
FYI: My background includes large-scale WebOps, mail service providers and HPC
engineering. I think I still have a Port25 shirt somewhere, these folks wh
Um, port25 has nice tee shirts but it isn't open source.
I never said it was? I'm aware it's a closed-source product. And it's
quite good - I've been using it extensively in the past. Though their
devs. were very cooperative and reversing *would* have been easy given
we got debug symbols for
True, but admins usually at least know where their stuff is (hosted), don't
they?
You would hope so, but in sufficiently large organizations, sometimes not.
It's off in the cloud, somewhere.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the envir
I think you're right that this would work for many (most? all?) CAs that do
email-based domain ownership validation.
I was surprised to find he's right -- if you ask for a cert for
foobar.example.com, typical CAs will let you validate via any of the WHOIS
contacts for example.com or else postm
So who should change what to fix it is not clear to me--we can expect
CAs to be more cautious or we can change STS in some manner to address
this. But parent domain walking strikes me as a rather unpleasant fix,
still.
Agreed. You can do what DMARC does, use the PSL or approved replacement
t
are in the etherpad at
http://etherpad.tools.ietf.org:9000/p/notes-ietf-96-uta
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
___
Uta mailing list
Uta@ietf.org
htt
On Tue, 8 Jan 2019, Vittorio Bertola wrote:
I don't understand why people are trying to reinvent the wheel when we
just defined a fairly round one a few months ago.
DANE and MTA-STS provide an evolutionary and backwards compatible path for the
transition to fully encrypted and authenticated em
I have about 80 domains pointed at my mail server. I control the DNS for
all of them but I can't see any reasonable way to make MTA-STS work.
I can set up the TXT records easily enough, but it looks like I need an
HTTPS server with 80 names and 80 certficates, or one certificate with 80
alt n
On Fri, 11 Jan 2019, Ned Freed wrote:
From what I can tell there is no limit that would prevent you from maintaining
as many domains as you want, even in the presence of a 2% valiation failure
rate - a rate which, if I had it, I would consider unacceptable and would
consider fixing it a top prior
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,
How about BY xxx/sni-host ?
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 (
On Mon, 14 Jan 2019, Daniel Kahn Gillmor wrote:
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.
Per the subsequent note, I'm sticking it in the BY header which allows a
second domain name in the pare
On Mon, 14 Jan 2019, Daniel Kahn Gillmor wrote:
On Mon 2019-01-14 16:43:15 -0500, John Levine wrote:
To show that you read it, please include the first word in the text
on page 50 of RFC 5321 in your reply.
I'm sorry to spoil it for everyone that the word is "The" :P
Sigh. Nope.
TCP-info
Are you suggesting that we add a new Received header field clause for
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
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, jo...@taugh
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?
On Thu, 24 Jan 2019, John C Klensin wrote:
--On Thursday, January 24, 2019 20:26 + "Salz, Rich"
wrote:
changes the registry criteria to Expert Review s
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 avo
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.)
Having added SNI to my MTA last week, I can say the MTA can definitely
tell
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.
Indeed, but unless th
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
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.
Yes, the ESNI attribute should be present/not-present and not the actual value.
How about
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:
https://datatracker.ietf.org/doc/draft-levine-additional-registered-clauses/
Regards,
John Levin
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.
Seems reasonable. In the usual case that you can tell wh
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, a
On 24 Jan 2019, at 11:56, John R Levine wrote:
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 sect
On Sun, 26 Apr 2020, Valery Smyslov wrote:
The general feeling in the room was in favor of the adoption, however
the authors were asked to rename it to *-rfc7525-bis.
The authors have renamed the draft and asked the chairs for its adoption.
Hi from e-mail land. We took a look and noticed that
38 matches
Mail list logo
