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 of
On 24 Jan 2019, at 11: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
> 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
> 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
> 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
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
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
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 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
>changes the registry criteria to Expert Review so you don't need to
publish an RFC merely to register a new clause.
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
On Thu, Jan 24, 2019 at 9:56 AM 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
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,
19 matches
Mail list logo
