On Tue, Sep 20, 2016 at 3:39 AM, Hubert Kario wrote:
> On Monday, 19 September 2016 18:12:22 CEST Eric Rescorla wrote:
> > Resolutions below.
>
> Thanks! I'll go over the post-merge text again later.
>
> > On Thu, Sep 8, 2016 at 11:08 AM, Hubert Kario wrote:
> > > On Monday, 5 September 2016 11:
On Monday, 19 September 2016 18:12:22 CEST Eric Rescorla wrote:
> Resolutions below.
Thanks! I'll go over the post-merge text again later.
> On Thu, Sep 8, 2016 at 11:08 AM, Hubert Kario wrote:
> > On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> > Finished section doesn't descr
Merged
On Mon, Sep 19, 2016 at 12:50 PM, Sean Turner wrote:
> Thanks for the discussion. We’re going to ask ekr to merge this one
> (obviously dealing with the additional input provided during the
> discussion).
>
> J&S
>
> > On Sep 06, 2016, at 17:33, Sean Turner wrote:
> >
> > All,
> >
> > T
Resolutions below.
On Thu, Sep 8, 2016 at 11:08 AM, Hubert Kario wrote:
> On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> > PR: https://github.com/tlswg/tls13-spec/pull/625
>
> Finally found some time to take a look at it.
>
> So in general I like the change to "abort the handsh
Please post a PR for this and see what the WG thinks.
On Fri, Sep 9, 2016 at 7:35 AM, Hannes Tschofenig wrote:
> Hi Ekr,
>
> I read through the text and I think it is an improvement.
>
> I only had one question that is only slightly related to your edits
> because it came up in the interop testi
Thanks for the discussion. We’re going to ask ekr to merge this one (obviously
dealing with the additional input provided during the discussion).
J&S
> On Sep 06, 2016, at 17:33, Sean Turner wrote:
>
> All,
>
> The chairs would like to get some eyes on this PR by this Friday (Sept 9th)
> so
On Friday, 9 September 2016 18:13:04 CEST Benjamin Kaduk wrote:
> I'm happy to make all alerts fatal.
>
> I also like the state in the pull requests where some cases require that
> if an alert is sent, it is a specific alert, while leaving flexibility
> in other cases (and preventing us from havin
On Sat, Sep 10, 2016 at 08:43:33PM +1000, Martin Thomson wrote:
>
> I wouldn't say that this is a great argument, but it's one that could
> be made. Generally, I've given up on TLS error codes being useful, or
> even making them useful; we've been stung in the past by being overly
> specific abou
On 10 September 2016 at 00:35, Hannes Tschofenig
wrote:
> I personally would find it more useful to have an alert saying
> "missing_server_name_extension" instead of just returning
> "missing_extension" for a number of different extensions since this gives
> the client no chance to fix the problem
I'm happy to make all alerts fatal.
I also like the state in the pull requests where some cases require that
if an alert is sent, it is a specific alert, while leaving flexibility
in other cases (and preventing us from having to exhaustively enumerate
all possible causes for alerts).
It would als
Hi Ekr,
I read through the text and I think it is an improvement.
I only had one question that is only slightly related to your edits
because it came up in the interop testing with the Mint implementation.
"
Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_na
On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/625
Finally found some time to take a look at it.
So in general I like the change to "abort the handshake with a alert",
the "send a fatal alert and close the connection" was a bit clu
I think an introductory section on "normal and exceptional flow of control" or
such would help. It could also define consistent terminology to be used in the
rest of the document. To take a stab at it:
Close -- means cleanly close the connection at some point after the
necessary alerts
Sorry, I left off the semi-serious joking indicator on the second paragraph.
Here is the main, real, point I want to bring up:
> > I think we should get rid of the "abort" concept. There's a clean
> > shutdown and there's everything else which is an abrupt or unclean
> > closing of the connection
Salz, Rich wrote:
>
> I've been reading this.
>
> I think we should get rid of the "abort" concept. There's a clean
> shutdown and there's everything else which is an abrupt or unclean
> closing of the connection. The "send alert" and "close connection"
> concepts are separable and I think we sh
I've been reading this.
I think we should get rid of the "abort" concept. There's a clean shutdown and
there's everything else which is an abrupt or unclean closing of the
connection. The "send alert" and "close connection" concepts are separable and
I think we should do that.
I think writin
On Wed, Sep 07, 2016 at 06:57:43PM +, Timothy Jackson wrote:
> We probably want to discuss the potential for side-channels introduced by
> alerting. I’ve seen at least one case where there were two possible
> classes of errors at a particular state in the protocol. One caused an
> alert, the ot
situation. I
suspect that will be difficult at best.
Tim
From: TLS on behalf of David Benjamin
Date: Wednesday, September 7, 2016 at 11:46 AM
To: Eric Rescorla , Andrei Popov
Cc: "tls@ietf.org"
Subject: Re: [TLS] PR#625: Change alert requirements
On Wed, Sep 7, 2016 at 2:21 PM Eri
On Wed, Sep 7, 2016 at 2:21 PM Eric Rescorla wrote:
> On Wed, Sep 7, 2016 at 11:19 AM, Andrei Popov
> wrote:
>
> > > the only popular stack I found that does not seem to send alerts is
> > > the schannel from Microsoft
>
> To clarify, schannel does generate alerts per RFC, but the HTTP stack
> (
Andrei Popov wrote:
>>> the only popular stack I found that does not seem to send alerts is
>>> the schannel from Microsoft
>
> To clarify, schannel does generate alerts per RFC, but the HTTP stack
> (which actually owns the socket) sees no value in sending them.
"Pillows don't hit people, peopl
On Wed, Sep 7, 2016 at 11:19 AM, Andrei Popov
wrote:
> > > the only popular stack I found that does not seem to send alerts is
> > > the schannel from Microsoft
>
> To clarify, schannel does generate alerts per RFC, but the HTTP stack
> (which actually owns the socket) sees no value in sending th
> > the only popular stack I found that does not seem to send alerts is
> > the schannel from Microsoft
To clarify, schannel does generate alerts per RFC, but the HTTP stack (which
actually owns the socket) sees no value in sending them.
Cheers,
Andrei
_
On Wednesday, 7 September 2016 10:19:02 CEST Eric Rescorla wrote:
> On Wed, Sep 7, 2016 at 10:05 AM, Hubert Kario wrote:
> > On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> > > PR: https://github.com/tlswg/tls13-spec/pull/625
> > >
> > > Currently the TLS spec requires implementa
On Wed, Sep 7, 2016 at 10:05 AM, Hubert Kario wrote:
> On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> > PR: https://github.com/tlswg/tls13-spec/pull/625
> >
> > Currently the TLS spec requires implementations to send alerts under
> various
> > fatal conditions. However, many sta
On Monday, 5 September 2016 11:02:57 CEST Eric Rescorla wrote:
> PR: https://github.com/tlswg/tls13-spec/pull/625
>
> Currently the TLS spec requires implementations to send alerts under various
> fatal conditions. However, many stacks actually don't send alerts
the only popular stack I found tha
On Tue, Sep 6, 2016 at 2:33 PM, Sean Turner wrote:
> All,
>
> The chairs would like to get some eyes on this PR by this Friday (Sept 9th)
> so that we can draw it to close.
So I'd like to know if there are places this PR weakens the
requirement beyond what common practice is. Why is the unexpect
All,
The chairs would like to get some eyes on this PR by this Friday (Sept 9th) so
that we can draw it to close.
Thanks,
J&S
> On Sep 05, 2016, at 14:02, Eric Rescorla wrote:
>
> PR: https://github.com/tlswg/tls13-spec/pull/625
>
> Currently the TLS spec requires implementations to send al
27 matches
Mail list logo
