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
Hi,
Le 2016-06-04 16:51, Eric Rescorla a écrit :
I wanted to call out to cryptographers/analysts that this formalizes
the existing practice (going back to RFC 5077) of having multiple
ticket values tied to the same basic secret (though less so with 1.3
because tickets issued on connection N+1 do
On Friday 03 June 2016 16:16:13 Dave Garrett wrote:
> The idea of using an empty extension as an indicator really isn't
> fundamentally different from what I'm suggesting here. We'd just have
> an arbitrary set of new version indicators mixed in with extensions
> instead of inside a new generalized
TLS-LTS, https://tools.ietf.org/html/draft-gutmann-tls-lts-03, has more or
less stabilised, incorporating all the feedback I've had for it (there's only
one open question still remaining), so I'd like to request that it now be
adopted as a WG item.
I'd also like to request an early/temporary assig
Hi,
On 06/06/2016 11:53 +0200, Antoine Delignat-lavaud wrote:
> Le 2016-06-04 16:51, Eric Rescorla a écrit :
>> I wanted to call out to cryptographers/analysts that this formalizes
>> the existing practice (going back to RFC 5077) of having multiple
>> ticket values tied to the same basic secret (
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
I've posted a new document to the datatracker that adds some TLS alert
codes that can be sent to indicate that a particular TLS request has been
blocked by the network. This attempts to address the problem of notifying
the user of what went wrong when a site is blocked, without creating a
channel
On Monday, June 06, 2016 06:48:20 am Hubert Kario wrote:
> What makes you think that a new version negotiation that works more or
> less in the same way will _not_ be implemented incorrectly?
The list-based extension doesn't work in quite the same way. The current
mechanism compares two values a
>> That being said, I would prefer the solution to be a compliance test suite
>> that checks if servers do handle correctly future versions, future
>> extensions and future ciphersuites correctly.
>
> I agree with Hubert. The big question is how you get the bug report to the
> server operator.
>
>
Dave Garrett writes:
>Also, as with any new system, we now have the ability to loudly stress to TLS
>1.3+ implementers to not screw it up and test for future-proofing this time
>around.
I think that's the main contribution of a new mechanism, it doesn't really
matter whether it's communicated a
10 matches
Mail list logo
