On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote:
> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>> Martin's comment reminded me of the following that I've been meaning to
>> post...
>>
>> In a recent discussion among some crypto folks, the topic of what TLS 1.3
>> could be cam
On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote:
> On Tue, Jan 12, 2016 at 9:02 AM, Dave Garrett wrote:
>> On Tuesday, January 12, 2016 09:03:53 am Peter Gutmann wrote:
>>> Martin's comment reminded me of the following that I've been meaning to
>>> post...
On Tue, Mar 13, 2018 at 3:16 PM, Russ Housley wrote:
> Second, using
> TLS1.2 does not technically address the issue. If the client were to
> exclusively offer DHE-based ciphersuites, then the visibility techniques
> that have been used in the past are thwarted.
I expect this configuration to be
It doesn't seem to be clearly spelled out: is the "charging GW" a
system that can read data passing between the client and server but
cannot modify it? If so, do I have it right that you are trying to
design an extension that allows the client to send a message that can
be observed but not tampere
On Thu, Mar 31, 2016 at 6:19 PM, Sean Turner wrote:
>
> 0) As described above: Get it approved by the IESG, hold it in RFC editor’s
> queue, and publish it as historic at the same time TLS 1.3 is published.
I'm not a fan of this option simply because
draft-ietf-tls-negotiated-ff-dhe has been stu
On Fri, Sep 23, 2016 at 2:10 PM, BITS Security
wrote:
> we need a better option than TLS 1.2 that will, perhaps sooner than we might
> expect, be deprecated.
I'm somewhat confused here. The concern over RSA for key exchange
versus DH for key exchange would only seem to apply when the network
t
On Wed, Oct 25, 2017 at 3:40 PM, Stephen Farrell
wrote:
>
>
> On 25/10/17 23:37, Richard Barnes wrote:
>> Sorry, what? The current draft proposes an extension, literally the
>> opposite of a standard, supported feature. It's explicitly optional.
>
> Optional is not the opposite of standard.
>
>
