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
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
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
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
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 section 3.1
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,
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
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
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
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
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
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
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,
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
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.
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
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 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
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
