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
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
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
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
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,
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
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
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
(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
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
> >
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
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?
>
>
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
> >
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
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
> > >
15 matches
Mail list logo