On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla wrote:
> On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin
> wrote:
>
>> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote:
>>
>>> 2% is actually pretty good, but I agree that we're going to need
>>> fallback.
>>>
>>> I'd be fine with moving the 8 byte
The IMO most reasonable way forward would be to side-step the
TLS version negotiation through ClientHello.client_version
entirely, because of the well-known interop problems.
Simply use the presence of *ANY* TLSv1.2+ TLS cipher suite in the
offered list of TLS cipher suites as an indication that a
Hi,
>
>
>
> I agree with Hubert. The big question is how you get the bug report to
> the server operator.
Automated mail to webmaster@domain_of_requested_hostname?
Maybe a few thousand new mails in the operator's inbox of sorts "we have
encountered a situation where your version intolerance brok
On 02/06/16 18:16, David Benjamin wrote:
On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni mailto:ietf-d...@dukhovni.org>> wrote:
> On Jun 2, 2016, at 10:49 AM, David Benjamin
mailto:david...@chromium.org>> wrote:
>
> I'm not sure I follow. The specification certainly spells
> On Jun 2, 2016, at 11:16 AM, David Benjamin wrote:
>
> I've mused on something like that (I was the main driver behind painstakingly
> removing the existing version fallback in Chrome), but I don't think
> non-determinism is a good idea. Site owners need to be able to reproduce the
> failur
On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario wrote:
> > > Speaking of version number, does the text say that a server _MUST_
> > > accept any version higher than the one that is specified in the RFC,
> > > but reply with 0x03,0x04 in case it doesn't support any future
> > > version of the protoco
On Thursday 02 June 2016 14:49:52 David Benjamin wrote:
> On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario wrote:
> > On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> > > In case folks hoped we could bump the ClientHello version without
> > > those dreaded browser fallbacks, I have bad news.
On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni
wrote:
>
> > On Jun 2, 2016, at 10:49 AM, David Benjamin
> wrote:
> >
> > I'm not sure I follow. The specification certainly spells out how
> version negotiation is supposed to work. That hasn't stopped servers from
> getting it wrong. Fundamentall
> On Jun 2, 2016, at 10:49 AM, David Benjamin wrote:
>
> I'm not sure I follow. The specification certainly spells out how version
> negotiation is supposed to work. That hasn't stopped servers from getting it
> wrong. Fundamentally this is the sort of thing where bugs don't get noticed
> unt
On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario wrote:
> On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> > In case folks hoped we could bump the ClientHello version without
> > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance
> > very much exists. (Maybe we should just
On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> In case folks hoped we could bump the ClientHello version without
> those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance
> very much exists. (Maybe we should just give up on
> ClientHello.version and use an extension? Exten
On 2 June 2016 at 08:56, Eric Rescorla wrote:
>> (Although, do we actually get the stronger protection if the client
>> accepts plain RSA key exchange? I've never been very clear on that.
>> Realistically, clients will be accepting plain RSA for a long while.)
>
>
> Yes, that's correct. I don't be
On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin
wrote:
> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote:
>
>> 2% is actually pretty good, but I agree that we're going to need fallback.
>>
>> I'd be fine with moving the 8 bytes to the end, but I wonder if it would
>> be better to
>> instead ha
On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote:
> 2% is actually pretty good, but I agree that we're going to need fallback.
>
> I'd be fine with moving the 8 bytes to the end, but I wonder if it would
> be better to
> instead have the *client* indicate its max version and the server check.
>
2% is actually pretty good, but I agree that we're going to need fallback.
I'd be fine with moving the 8 bytes to the end, but I wonder if it would be
better to
instead have the *client* indicate its max version and the server check.
That would
have the advantage that it would leave more of the se
In case folks hoped we could bump the ClientHello version without those
dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much
exists. (Maybe we should just give up on ClientHello.version and use an
extension? Extensions have rusted less.)
I picked a large list of top sites and
16 matches
Mail list logo
