On 27 Oct 2017, at 11:34, Eric Rescorla wrote:
On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman
wrote:
On 26 Oct 2017, at 19:56, Keith Moore wrote:
On 10/26/2017 07:18 PM, Chris Newman wrote:
Line 304
preference to services supporting STARTTLS (if offered).
(See
also Section
Yeah, this doesn't seem like an actually secure set of practices, which is
why we don't do it for HTTPS even when there are CNAMEs.
-Ekr
On Fri, Oct 27, 2017 at 12:20 PM, Viktor Dukhovni
wrote:
>
>
> > On Oct 27, 2017, at 2:34 PM, Eric Rescorla wrote:
> >
> > So to be clear, what you are sayi
> On Oct 27, 2017, at 2:34 PM, Eric Rescorla wrote:
>
> So to be clear, what you are saying is that when I enter "mail.example.com"
> but it's hosted on "mailhosting.com", and that indirection is done via SRV,
> that the certificate contains "mail.example.com" but the SNI contains
> "mailhos
On Fri, Oct 27, 2017 at 11:03 AM, Chris Newman
wrote:
> On 26 Oct 2017, at 19:56, Keith Moore wrote:
>
>> On 10/26/2017 07:18 PM, Chris Newman wrote:
>>
>> Line 304
>preference to services supporting STARTTLS (if offered). (See
>also Section 4.5.)
> I note that 6186 i
> On Oct 27, 2017, at 2:03 PM, Chris Newman wrote:
>
> I just re-read the related text a bit more carefully. Although RFC 7817
> adequately covers what subjectAltName identities mail servers need to support
> in certificates, it doesn't cover what goes in SNI (although it mentions
> SNI). Di
On 26 Oct 2017, at 19:56, Keith Moore wrote:
On 10/26/2017 07:18 PM, Chris Newman wrote:
Line 304
preference to services supporting STARTTLS (if
offered). (See
also Section 4.5.)
I note that 6186 is kind of unclear on what should go in SNI. It
obviously
needs to be what you ar
On Thu, Oct 26, 2017 at 09:35:34PM -0400, Viktor Dukhovni wrote:
> > On Oct 26, 2017, at 9:21 PM, Jim Fenton wrote:
> >
> > The question I have is: Why are we matching the certificate against the
> > policy rather than against the hostname, and is that done in any other
> > context? Does that offe
Perhaps it would be useful if Chris could walk through the example he gave
in more detail.
My point is that if the client is configured to connect to "pop.example.com"
that has to be in the
certificate, regardless of how many SRV records there are.
-Ekr
On Fri, Oct 27, 2017 at 7:16 AM, Keith Moo
> On Oct 27, 2017, at 7:48 AM, Eric Rescorla wrote:
>
> The entire principle here is that (absent DNSSEC) TLS operates on what was
> fed into the client.
Could you elaborate a bit? I feel like I'm missing some context.
Thanks,
Keith
___
Uta mai
On Thu, Oct 26, 2017 at 7:56 PM, Keith Moore
wrote:
> On 10/26/2017 07:18 PM, Chris Newman wrote:
>
> Line 304
>preference to services supporting STARTTLS (if offered). (See
>also Section 4.5.)
> I note that 6186 is kind of unclear on what should go in SNI. It obviously
> needs t
> On Oct 27, 2017, at 5:02 AM, Hanno Böck wrote:
>
>> Which is different from
>> requiring that clients or servers reject weaker options, but given
>> such a server requirement, it would not be too unreasonable for STS
>> clients to in fact require at least TLS 1.2 and its MIT ciphersuites
>> f
On Wed, 25 Oct 2017 18:57:05 -0400
Viktor Dukhovni wrote:
> Which is different from
> requiring that clients or servers reject weaker options, but given
> such a server requirement, it would not be too unreasonable for STS
> clients to in fact require at least TLS 1.2 and its MIT ciphersuites
> f
12 matches
Mail list logo
