Mirja Kühlewind has entered the following ballot position for
draft-ietf-uta-email-deep-09: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://
On Thu, Oct 19, 2017 at 10:03 AM, Daniel Margolis
wrote:
> Yes, I also don't see the point of vanity hosts, but I guess some people
> want this for some reason.
>
> Ivan's language seems fine to me, for the most part, but I still wonder if
> it wouldn't make STS implementation harder for MTA deve
On Wed, Oct 18, 2017 at 8:39 PM, Viktor Dukhovni
wrote:
>
>
> > On Oct 18, 2017, at 3:29 PM, Daniel Margolis
> wrote:
> >
> > Viktor, wearing your MTA-developer hat, any objections to requiring the
> MTA to always send SNI? I don't know what common MTAs do about sending SNI.
>
> At present, Post
There's another angle to take into account: SNI is mandatory to implement
in TLS 1.3:
https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.2
For better or worse, SNI is part of TLS, and has been for more than a
decade. IMO, all new standards should assume SNI by default and
On 23/10/17 17:11, Ivan Ristic wrote:
> On Thu, Oct 19, 2017 at 10:03 AM, Daniel Margolis
> wrote:
>> Ivan's language seems fine to me, for the most part, but I still wonder if
>> it wouldn't make STS implementation harder for MTA developers than the
>> alternative (which is to just say you can't
> On Oct 23, 2017, at 12:24 PM, Ivan Ristic wrote:
>
> There's another angle to take into account: SNI is mandatory to implement in
> TLS 1.3:
>
>
> https://tlswg.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.2
>
> For better or worse, SNI is part of TLS, and has been for
On 10/18/2017 12:39 PM, Viktor Dukhovni wrote:
> At present, Postfix always sends SNI when doing DANE and never otherwise.
> The STS logic could be the same. Mind you, SNI does introduce a privacy
> leak, since SNI is sent in the clear. So one could take the view that
> the need for this is slim
> On Oct 23, 2017, at 1:00 PM, Christian Huitema wrote:
>
> As Viktor says, the easy way for STS is to avoid the "multiplexed
> server" scenario. In fact, that's a pretty natural use of MX records.
> The MX record for "some-personal-server.com" would point to
> "mta.example.net", the SNI would
On 10/23/2017 10:21 AM, Viktor Dukhovni wrote:
>> On Oct 23, 2017, at 1:00 PM, Christian Huitema wrote:
>>
>> As Viktor says, the easy way for STS is to avoid the "multiplexed
>> server" scenario. In fact, that's a pretty natural use of MX records.
>> The MX record for "some-personal-server.com"
> On Oct 23, 2017, at 1:39 PM, Christian Huitema wrote:
>
>> So while there is just one default certificate serving each of the
>> millions of hosted domains, the SNI would leak the exact name of
>> each domain.
>
> Maybe add a discussion of this specific privacy issue in the draft? It
> looks
On Mon, Oct 23, 2017 at 7:37 PM, Viktor Dukhovni
wrote:
>
> In other words, where's the data that makes it possible to
> understand whether SNI is actually useful, or mostly just
> an auto-pilot design to look like virtual-hosting with HTTPS
> where the requirements are very different.
>
Correct
At present, STS doesn't impose any restrictions on the quality of TLS
connection. Historically, new RFCs and protocols have been the only
opportunity to enforce better security. For comparison, HTTP/2 introduced a
requirement to use TLS 1.2 and suites with forward security and
authenticated encrypt
Which all sounds like RFC 7525, the TLS BCP, that was published by this
very working group.
Thanks,
Yaron
On 23/10/17 14:09, Ivan Ristic wrote:
At present, STS doesn't impose any restrictions on the quality of TLS
connection. Historically, new RFCs and protocols have been the only
opp
* …however the HTTP/2 approach seems sound overall.
HTTP/2 RFC violates protocol layering by imposing restrictions on TLS
parameters when the HTTP/2 ALPN ID is negotiated. When an HTTP/2 server is
running on top of a general-purpose TLS stack, the TLS stack has to either
implement HTTP/2-spe
> On Oct 23, 2017, at 4:56 PM, Ivan Ristic wrote:
>
> Correct me if I am wrong, but at present no one checks if presented SMTP
> certificates are valid. In fact, a major reason we need MTA-STS is to make a
> clean start. You're not going to get the real-world data you're looking for
> becaus
What you're describing is a usability problem. For example, HTTP/2
specifies a mandatory-to-implement suite
(TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256);
if the software implementing HTTP/2 followed the RFC, everything would just
work. For example, they could refuse to run with invalid configuration,
fo
* For example, HTTP/2 specifies a mandatory-to-implement suite
(TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256); if the software implementing HTTP/2
followed the RFC, everything would just work. For example, they could refuse to
run with invalid configuration, forcing the issue.
Whether connections s
On Mon, Oct 23, 2017 at 10:45 PM, Viktor Dukhovni
wrote:
>
>
> > On Oct 23, 2017, at 4:56 PM, Ivan Ristic wrote:
> >
> > Correct me if I am wrong, but at present no one checks if presented SMTP
> certificates are valid. In fact, a major reason we need MTA-STS is to make
> a clean start. You're n
> On Oct 23, 2017, at 6:39 PM, Ivan Ristic wrote:
>
>> If we conclude that there's no need for virtual-hosting of TLS
>> (multiple chains at the same transport endpoint) with MTA-to-MTA
>> SMTP, then there's demonstrably no need for SNI, no matter how
>> much goodness it brings to the Web.
>
>
--
COMMENT:
--
The document reads like a BCP to me. Was it discussed in the group to go for
BCP? If yes, why was it decided to go not for BCP? If no, I would str
Adam Roach has entered the following ballot position for
draft-ietf-uta-email-deep-09: Yes
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https://www.i
--
COMMENT:
--
Balloting "Yes" because I think this is a very welcome and important update to
its antecedent documents -- but I think there are a few simple chan
On 2017-10-24 04:38, Keith Moore wrote:
>> --
>> COMMENT:
>> --
>>
>> The document reads like a BCP to me. Was it discussed in the group to
>> go for
>> BCP? If
23 matches
Mail list logo
