On Thu, Oct 06, 2016 at 01:59:33PM +1100, Martin Thomson wrote:
> On 6 October 2016 at 06:40, Ilari Liusvaara wrote:
> > The only issue that comes to mind is where extensions that are specific
> > to the certificate chain instead to the certificate go.
>
> Let's keep it simple. I would put these
On 6 October 2016 at 06:40, Ilari Liusvaara wrote:
> The only issue that comes to mind is where extensions that are specific
> to the certificate chain instead to the certificate go.
Let's keep it simple. I would put these on the EE cert. That is the
entry that has the most chance of being look
The following errata report has been verified for RFC6066,
"Transport Layer Security (TLS) Extensions: Extension Definitions".
--
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6066&eid=4817
On Wed, Oct 05, 2016 at 03:06:25PM -0400, Sean Turner wrote:
> I’m not seeing objections to this PR so please let us know by Friday
> (7 October) whether you see any issues with what’s been proposed.
>
> > On Sep 22, 2016, at 20:42, Nick Sullivan
> > wrote:
> >
> > PR: https://github.com/tlsw
Florian--Anecdotally, I have heard Microsoft and F5 did code upgrades a few
years back that moved Diffie Hellman to the top cipher suite priorities which
broke security and fraud monitoring, APM reporting, and sniffer troubleshooting
for a financial services client and at least one other organiz
I’m not seeing objections to this PR so please let us know by Friday (7
October) whether you see any issues with what’s been proposed.
spt
> On Sep 22, 2016, at 20:42, Nick Sullivan wrote:
>
> PR: https://github.com/tlswg/tls13-spec/pull/654
>
> Hello,
>
> I'd like to propose a small to the
* BITS Security:
> Deprecation of the RSA key exchange in TLS 1.3 will cause significant
> problems for financial institutions, almost all of whom are running
> TLS internally and have significant, security-critical investments in
> out-of-band TLS decryption.
>
> Like many enterprises, financia
* Hubert Kario:
> those secret keys are on the client machines and they will stay on client
> machines
>
> making it hard to extract master key from process memory is just security
> through obscurity, not something that will stop a determined attacker
I think extracting the master key is proba
Also, it would be difficult to remove existing functionality, and get the
callers to update. E.g. deprecation of TLS_UNIQUE is not going easy for
apps/protocols.
Cheers,
Andrei
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, October 4, 2016 8:49 PM
To: Martin
Looks like this one can safely be accepted.
spt
> On Oct 03, 2016, at 13:47, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC6066,
> "Transport Layer Security (TLS) Extensions: Extension Definitions".
>
> --
> You may re
Hi Andi,
Thanks for your interest in the draft.
Yes. We will be definitely reviving the draft.
Just held up with some work. We should be able to upload the modified draft
in a week or two.
Regards,
Jay
On Wednesday 5 October 2016, Raja ashok wrote:
> Hi Andreas,
>
>
>
> Last week received so
Hi Andreas,
I am not sure that people ignore the redundant length fields on purpose.
I think that the strange syntax that TLS uses invites these types of
mistakes and I had run into those myself as well.
Ciao
Hannes
On 10/05/2016 02:03 PM, Andreas Walz wrote:
> Hi Olivier,
>
> your findings ar
Hi Andreas,
Last week received some comments from Ilari and David. We are working on the
next version of this draft. We will upload it soon.
Regards,
Ashok
Raja Ashok VK
华为技术有限公司 Huawei Technologies Co., Ltd.
[Company_logo]
Phone:
Fax:
Mobile:
Email:
Huawei Tech
Hi Olivier,
your findings are interesting as they pretty much match with what we
have found when studying TLS implementations for embedded systems. In
many implementations there is a tendency to ignore redundant length
fields (or at least to not enforce consistency). There has been some
discussion
14 matches
Mail list logo
