> 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
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
>> 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.
Hiya,
On 25/01/2019 22:11, Viktor Dukhovni wrote:
> Like John, I am very skeptical about the applicability of ESNI to
> SMTP.
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
> 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
> On Jan 25, 2019, at 4:38 PM, Stephen Farrell
> wrote:
>
> 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
Hi,
Op 25/01/2019 om 16:00 schreef The IESG:
Abstract
The SMTP STARTTLS option, used in negotiating transport-level
encryption of SMTP connections, is not as useful from a security
standpoint as it might be because of its opportunistic nature;
message delivery is, by default,
Hiya,
On 25/01/2019 18:08, John R Levine wrote:
> 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:
Sorry to have made you (more:-) grumpy,
> sni domain.name
> esni yes
Works for me.
(Stephen's right about ESNI and its use of DNS BTW)
___
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
On 25/01/2019 17:15, John R Levine wrote:
>
> How about this?
>
> sni domain.name
> 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.
0x5AB2FAF17B172BEA.asc
>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.
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
On 25/01/2019 16:36, John R Levine wrote:
>
>> 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.
>
>
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
>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.
___
Uta
Hiya,
On 25/01/2019 15:00, John R Levine wrote:
>
> 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
The IESG has received a request from the Using TLS in Applications WG (uta)
to consider the following document: - 'SMTP Require TLS Option'
as Proposed Standard
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive
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
On 25/01/2019 02:37, John R Levine wrote:
>> 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
Hi all,
On 24 Jan 2019, at 23:41, Salz, Rich wrote:
>> 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
20 matches
Mail list logo
