> On Apr 19, 2018, at 4:24 PM, Salz, Rich wrote:
>
> Viktor found my comment offensive, which was not my intent. I was trying to
> be light-hearted in commenting on how Viktor dismissed all the issues David
> raised.
>
> If, in doing so, I went beyond our code of conduct and offended, I am
Viktor found my comment offensive, which was not my intent. I was trying to be
light-hearted in commenting on how Viktor dismissed all the issues David raised.
If, in doing so, I went beyond our code of conduct and offended, I am truly
truly sorry.
___
Sorry if I offended you.
On 4/19/18, 3:23 PM, "Viktor Dukhovni" wrote:
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote:
>
> I am not fond of Viktor's reply, which comes across as "pshaw silly
ninny" or something like that.
You'll need to retract that.
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote:
>
> David has pointed out valid use-cases. I think most use-cases will "just
> work." We should document the known sharp edges.
I am pointing valid use-cases that David has not taken into account, and
conformance ratchets have cost/benefit t
> On Apr 19, 2018, at 2:54 PM, Salz, Rich wrote:
>
> I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or
> something like that.
You'll need to retract that.
--
Viktor.
___
openssl-project mailing list
openssl-pro
> On Apr 19, 2018, at 3:15 PM, Kurt Roeckx wrote:
>
> I think there might be some disagreement on how to go forward with
> having proper TLS in SMTP. I think Google might want to go with
> how it works for https, and so have certificates issued by a CA
> for hostname you try to connect to. I th
On Thu, Apr 19, 2018 at 09:15:19PM +0200, Kurt Roeckx wrote:
>
> It would also be nice that if the client sends an SNI and you have
> a certificate for it that it wouldn't select an anonymous cipher.
> But then postfix is probably the only one that does anonymous
> ciphers, and if it's not sending
On Thu, Apr 19, 2018 at 02:02:53PM -0400, Viktor Dukhovni wrote:
>
>
> > On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni
> > wrote:
> >
> > There is no "the name that is being verified". The Postfix SMTP client
> > accepts multiple (configurable as a set) names for the peer endpoint. This
> >
I am not fond of Viktor's reply, which comes across as "pshaw silly ninny" or
something like that.
David has pointed out valid use-cases. I think most use-cases will "just
work." We should document the known sharp edges.
___
openssl-project mailin
> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote:
>
> Consider a caller using a PKCS#1-only ENGINE-backed private key. PKCS#1 does
> not work in TLS 1.3, only PSS.
That's a local matter, and easy to resolve locally.
> Consider a caller which calls SSL_renegotiate.
Ditto. And sufficientl
> On Apr 19, 2018, at 1:49 PM, Viktor Dukhovni
> wrote:
>
> There is no "the name that is being verified". The Postfix SMTP client
> accepts multiple (configurable as a set) names for the peer endpoint. This
> may be the next-hop domain or the MX hostname, or a sub-domain wildcard, or
> s
> On Apr 19, 2018, at 1:31 PM, David Benjamin wrote:
>
> Consequently, opportunistic SMTP clients (or those using mandatory TLS, but
> without
> DANE where the SNI value is still a guessing game we did not play) won't get
> TLS 1.3, until they start to make up some sort of SNI name.
>
> I'm
On 19/04/18 18:31, David Benjamin wrote:
> I might suggest conditioning it on the compile-time version of OpenSSL
> headers. This is a common transition strategy for systems working
> through ABI constraints. (In some systems, this is implemented as some
> target SDK version.)
This is exactly wh
> On Apr 18, 2018, at 6:23 PM, David Benjamin wrote:
>
> Rather than break existing clients, with TLS 1.3 we are trying a more
> incremental approach: if a client is new enough to support TLS 1.3 then
> either it should be sending SNI, or we'll give it a dummy certificate.
So it sure seems l
Google incurs a significant, ongoing cost to support clients that don't
send SNI. Such clients, at least in the HTTP space, are easy to miss in
casual testing (because browsers do send SNI), and require that we ensure
that a given name is covered by the default certificates on any IP address
that c
> On Apr 18, 2018, at 1:14 PM, Kurt Roeckx wrote:
>
> I'm not sure you actually get downgraded? I get TLS 1.2 in all
> cases. I think they still speak a different draft version. If it's
> boringssl, I think they do 22 and 23 in the last release and 26
> (like we) in their current master version
On Wed, Apr 18, 2018 at 11:05:05AM -0400, Viktor Dukhovni wrote:
>
> What I can blame them for is being counter-productively pedantic. Forget the
> RFC language, does what they're doing make sense and improve security or is
> it just a pointless downgrade justified by RFC text lawyering?
I'm no
> On Apr 18, 2018, at 10:43 AM, Andy Polyakov wrote:
>
> It can either be a probe just to see if it's reasonable to demand it, or
> establish a precedent that they can refer to saying "it was always like
> that, *your* application is broken, not ours." Also note that formally
> speaking you can
>That's what Rich suggested, and it makes sense, but what does not make any
> sense to me is what Google is doing. Snatching defeat from the jaws of
> victory by needlessly forcing clients to downgrade to TLS 1.2. Is there a
> justification for this?
It's Google's internet, we just use
> ... what does not make any sense to me is what Google is doing. Snatching
> defeat from the jaws of victory by needlessly forcing clients to downgrade to
> TLS 1.2. Is there a justification for this?
It can either be a probe just to see if it's reasonable to demand it, or
establish a precede
> On Apr 18, 2018, at 10:12 AM, Andy Polyakov wrote:
>
> With this in mind, wouldn't it be more
> appropriate to simply not offer 1.3 capability if application didn't
> provide input for SNI?
That's what Rich suggested, and it makes sense, but what does not make any
sense to me is what Google
> When I link posttls-finger with the OpenSSL 1.1.1 library, I see:
Just in case for reference, one can reproduce all this with 1.1.1
s_client. Below case is -starttls smtp -noservername. "Fun" part is that
OU for the self-signed certificate reads "No SNI provided; please fix
your client." Another
Applications that have hitherto used TLS <= 1.2 have often not needed to use
SNI. The extension, though useful for virtual-hosting on the Web, was optional.
TLS 1.3 has raised the status of SNI from optional to "mandatory to implement".
What this means that is that implementations must support
23 matches
Mail list logo
