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
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
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
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: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
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
(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
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
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 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 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 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 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 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 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 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 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
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 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
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 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 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 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
23 matches
Mail list logo
