On Thursday 14 July 2016 09:17:06 Martin Thomson wrote:
> On 14 July 2016 at 03:01, Eric Rescorla wrote:
> >
> > Obviously, you could add a check that said that if an EC cipher suite was
> > advertised, then you had to look for key shares even if you picked one, but
> > it's not a check you otherw
On 14 July 2016 at 03:01, Eric Rescorla wrote:
>
> Obviously, you could add a check that said that if an EC cipher suite was
> advertised, then you had to look for key shares even if you picked one, but
> it's not a check you otherwise need.
Though you would miss an EC cipher suite that you didn'
On Wednesday, July 13, 2016 01:01:13 pm Eric Rescorla wrote:
> It's natural to pick the cipher suite first and then look for the key_share
> extension, so if, for instance, you pick a PSK-only cipher suite, then you
> wouldn't look for the key_share.
Agreed. That's why I'm ok with the current "no
Reinforcing what David says here:
It's natural to pick the cipher suite first and then look for the key_share
extension, so if, for instance, you pick a PSK-only cipher suite, then you
wouldn't look for the key_share.
Obviously, you could add a check that said that if an EC cipher suite was
advert
On Wednesday 13 July 2016 15:58:24 David Benjamin wrote:
> On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario wrote:
>
> > On Wednesday 13 July 2016 14:43:58 David Benjamin wrote:
> > > To be clear, I am not at all opposed to useful errors or strict policing
> > of
> > > what the peer sends. That's al
On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario wrote:
> On Wednesday 13 July 2016 14:43:58 David Benjamin wrote:
> > To be clear, I am not at all opposed to useful errors or strict policing
> of
> > what the peer sends. That's all great. Indeed the linked test below makes
> > use of more specific
On Wednesday 13 July 2016 14:43:58 David Benjamin wrote:
> To be clear, I am not at all opposed to useful errors or strict policing of
> what the peer sends. That's all great. Indeed the linked test below makes
> use of more specific error codes than TLS provides. But I would like such
> things to:
To be clear, I am not at all opposed to useful errors or strict policing of
what the peer sends. That's all great. Indeed the linked test below makes
use of more specific error codes than TLS provides. But I would like such
things to:
1. Be useful, either for debugging or because it rejects an inv
On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett wrote:
> To be clear though, completely mandatory extensions, at least as we're
> doing them here, are a new thing. TLS 1.2 relied on separate messages for
> stuff, but we're front-loading everything into the ClientHello to get
> reliable 1RTT (with th
On Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> I don't believe an implementation which fails to send supported_groups,
> etc., in 1.3 would ever leave a developer's workstation. It would not
> interoperate with anything.
it would interoperate with itself, and for some deployments that'
On Wednesday, July 13, 2016 01:23:53 am David Benjamin wrote:
> I'm also curious what cases were you envisioning missing_extension to be
> useful. I spend a lot of my time triaging TLS-related bugs in Chrome, so
> I'm certainly not blind to TLS handshake errors being difficult to
> diagnose, especi
On 13 July 2016 at 13:22, Dave Garrett wrote:
> I am aware that discussion ended up on accepting sloppy error reporting as
> acceptable. Changing the disputed missing_extension alerts to SHOULDs would
> be an acceptable compromise if that decision is still actually going through.
"sloppy" is a
On Tuesday, July 12, 2016 10:51:22 pm Eric Rescorla wrote:
> I generally agree with David here.
>
> -Ekr
>
> P.S. Back in Seattle, we had rough consensus to change the alert requirements
> [0] so that
> you didn't have to send alerts, but if you sent an alert, you had to send
> alert X. That's
On Tuesday, July 12, 2016 09:58:46 pm David Benjamin wrote:
> I would like to remove the missing_extension MUSTs on the server side. Full
> justification in the PR.
> https://github.com/tlswg/tls13-spec/pull/544
>
> On the client, it is perfectly feasible to mandate a particular alert
> value. The
I generally agree with David here.
-Ekr
P.S. Back in Seattle, we had rough consensus to change the alert
requirements [0] so that
you didn't have to send alerts, but if you sent an alert, you had to send
alert X. That's been
on the TODO list for a while but expect a PR soon.
[0] https://github.
Hey folks,
I would like to remove the missing_extension MUSTs on the server side. Full
justification in the PR.
https://github.com/tlswg/tls13-spec/pull/544
On the client, it is perfectly feasible to mandate a particular alert
value. The check is very straight-forward. On the server, however, thi
16 matches
Mail list logo
