On 09/16/2015 09:53 PM, Brian Smith wrote:
> Assume the client and the server implement the mandatory-to-implement
> parameters and that both the client and the server are otherwise
> conformant. In this scenerio, when would an alert other than the non-fatal
> close_notify be sent?
I have been to
On Wednesday 16 September 2015 12:53:53 Brian Smith wrote:
> Thus, the empirical evidence from Mozilla's
> widely-deployed implementation shows that (a) the requirement to send
> alerts is difficult to conform to, and (b) it is unimportant in
> practice to send alerts.
and yet Firefox depends on t
On Thursday 17 September 2015 03:27:22 Peter Gutmann wrote:
> Viktor Dukhovni writes:
> >Explicit profiles make some sense. They need not be defined by the
> >TLS WG per-se, it might be enough for the TLS specification to
> >reference an IANA profile registry, with the TLS-WG defining a
> >"base"
On 9/16/15, 4:19 , "TLS on behalf of Peter Gutmann" wrote:
>Jeffrey Walton writes:
>>Somewhat off-topic, why does TLS not produce a few profiles. One can be
>>"Opportunistic TLS Profile" with a compatible security posture and
>>include
>>ADH. Another can be a "Standard TLS Profile" and include t
On Wed, Sep 16, 2015 at 06:40:47PM -0700, Bill Frantz wrote:
> I agree with both Nico and Viktor. For me the big win of RPK over
> anon_(EC)DH is it allows TOFU. If TOFU isn't needed, short public
> keys should ease many of Viktor's cons. I also like the idea of
> simpler implementations.
Eh, cert
Hubert Kario wrote:
> On Wednesday 16 September 2015 12:53:53 Brian Smith wrote:
> > Thus, the empirical evidence from Mozilla's
> > widely-deployed implementation shows that (a) the requirement to send
> > alerts is difficult to conform to, and (b) it is unimportant in
> > practice to send alert
On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote:
> Further, the alerting mechanism has encouraged the unsafe practice of
> "version fallback." It is clear from looking at the bug databases of
> Firefox and Chrome that their attempts to make security decisions based on
> what alerts they
On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams
wrote:
> On Wed, Sep 16, 2015 at 12:53:53PM -0700, Brian Smith wrote:
> > Further, the alerting mechanism has encouraged the unsafe practice of
> > "version fallback." It is clear from looking at the bug databases of
> > Firefox and Chrome that their
On Thu, Sep 17, 2015 at 02:46:39PM -0700, Brian Smith wrote:
> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams
> wrote:
> > Do we think that silent connection closings wouldn't also lead to
> > version fallback?
>
> Let's ask the browser vendors:
>
> Browser vendors, if web servers were to stop s
On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> On Thursday, September 17, 2015 03:27:10 pm Brian Smith wrote:
> > (We should focus on conformant implementations because non-conformant
> > implementations can do whatever they want, by definition).
>
> The flaw in your logic here is
On Thursday, September 17, 2015 05:46:39 pm Brian Smith wrote:
> Let's ask the browser vendors:
>
> Browser vendors, if web servers were to stop sending alerts during
> handshake failures, would you start doing version fallback when a
> connection is closed?
Well, what else would clients do inste
On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams
wrote:
> On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> > On Thursday, September 17, 2015 03:27:10 pm Brian Smith wrote:
> > > (We should focus on conformant implementations because non-conformant
> > > implementations can do whateve
On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
> Issue: https://github.com/tlswg/tls13-spec/issues/242
>
> In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
>
> "Nobody must ever be *required* to send an alert. Any requirement for
> sending an alert should be SH
On Thu, Sep 17, 2015 at 3:00 PM, Nico Williams
wrote:
> On Sat, Sep 12, 2015 at 01:49:49PM -0700, Eric Rescorla wrote:
> > Issue: https://github.com/tlswg/tls13-spec/issues/242
> >
> > In https://github.com/tlswg/tls13-spec/pull/231, Brian Smith argues:
> >
> > "Nobody must ever be *required* to
On Thu, Sep 17, 2015 at 03:00:05PM -0700, Brian Smith wrote:
> On Thu, Sep 17, 2015 at 2:55 PM, Nico Williams
> wrote:
> > On Thu, Sep 17, 2015 at 05:47:50PM -0400, Dave Garrett wrote:
> >
> > Yes, exactly. Thanks.
> >
>
> There's no evidence that the presence or absence of an alert when a
> con
On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote:
> There's no evidence that the presence or absence of an alert when a
> connection is closed makes any positive difference in the security of any
> non-secure fallback mechanism. Keep in mind that the alerts during the
> handshake are N
(Resending from the right address, again. Possibly I should have subscribed
with the other one...)
On Thu, Sep 17, 2015 at 6:23 PM David Benjamin wrote:
> On Thu, Sep 17, 2015 at 5:46 PM Brian Smith wrote:
>
>> On Thu, Sep 17, 2015 at 1:50 PM, Nico Williams
>> wrote:
>>
>>> On Wed, Sep 16, 201
Martin Thomson wrote:
> On 17 September 2015 at 14:46, Brian Smith wrote:
> > Browser vendors, if web servers were to stop sending alerts during
> handshake
> > failures, would you start doing version fallback when a connection is
> > closed?
>
> I'm not sure. We still have a small amount of ve
On Thu, Sep 17, 2015 at 3:15 PM, Dave Garrett
wrote:
> On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote:
> > There's no evidence that the presence or absence of an alert when a
> > connection is closed makes any positive difference in the security of any
> > non-secure fallback mecha
Brian Smith wrote:
>
> There's no evidence that the presence or absence of an alert when a
> connection is closed makes any positive difference in the security of any
> non-secure fallback mechanism. Keep in mind that the alerts during the
> handshake are NOT authenticated, and the TLS threat mode
On Thu, Sep 17, 2015 at 3:44 PM, Dave Garrett
wrote:
> The client initially has no way of telling apart a conformant TLS 1.3
> server, a TLS 1.2 server, a TLS 1.0 server full of bugs, or a potato.
>
Right. I am not saying anything about how to *receive* alerts. That's a
separate topic.
What I'm
On Thu, Sep 17, 2015 at 4:15 PM, Dave Garrett
wrote:
> On Thursday, September 17, 2015 06:58:19 pm Martin Rex wrote:
> > If one of the communication peers closes the network connection
> > prior to completion of the TLS handshake, then the result is a 100%
> > interoperability failure. How is a
Dear Ladies and Gentlemen of the TLS Working Group,
my name is Christos Alewa and I am writing you on behalf HOB GmbH & Co KG, a
software enterprise from Germany, which specialises in development of software
particularly for secure remote access.
Our main product HOB RD VPN has received the Comm
23 matches
Mail list logo
