Stephen,
> I'd love to add more detail like that and/or more sections for other
protocols if folks have data to offer with references.
I believe that I can reach out to various people I know. Please comment
if my methodology is acceptable and if you think this will be helpful.
I am thinking
Hubert Kario writes:
>defeating two hashes, when both use use the Merkle-Damgård construction, is
>not much harder than breaking just one of them (increase of work factor less
>than 2)
"In theory there is no difference between theory and practice. In practice
there is".
I'm aware of this
m...@sap.com (Martin Rex) wrote:
> Andrei Popov wrote:
>>
>> On the recent Windows versions, TLS 1.0 is negotiated more than 10%
>> of the time on the client side (this includes non-browser connections
>> from all sorts of apps, some hard-coding TLS versions),
>> and TLS 1.1 accounts for ~0.3% of
Hiya,
On 10/07/18 19:04, Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote:
>
>> I didn't have time before the I-D cutoff but have since
>> added a section on mail to the repo pre-01 version. (See
>> [1] section 3.2.) I'd love to add more detail like that
RFC 5289 has been reclassified as Proposed Standard.
RFC 5289
Title: TLS Elliptic Curve Cipher Suites
with SHA-256/384 and AES Galois Counter
Mode (GCM)
Author: E. Rescorla
Status: Standards Track
On Tuesday, 10 July 2018 18:01:50 CEST Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote:
> > The github version of the document points out that the security of TLS 1.2
> > downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.
>
> Is this accurate? TLS
On 2018-07-10 at 00:17 -0400, Viktor Dukhovni wrote:
> More generally, as noted in RFC7435, you get more security by raising
> the ceiling than by raising the floor.
+1, including to the points about SMTP fallback to cleartext, etc.
> For example, I recently learned that current GnuTLS
>
On Tuesday, 10 July 2018 18:38:22 CEST Peter Gutmann wrote:
> David Benjamin writes:
> >EMS does not fix the ServerKeyExchange signature payload. It's still just
> >the randoms and not the full transcript.
>
> Maybe we're talking about different things here, EMS hashes the full
> transcript, for
On Tue, Jul 10, 2018 at 09:21:04AM +0100, Stephen Farrell wrote:
> I didn't have time before the I-D cutoff but have since
> added a section on mail to the repo pre-01 version. (See
> [1] section 3.2.) I'd love to add more detail like that
> and/or more sections for other protocols if folks have
David Benjamin writes:
>EMS does not fix the ServerKeyExchange signature payload. It's still just the
>randoms and not the full transcript.
Maybe we're talking about different things here, EMS hashes the full
transcript, for 1.0 and 1.1 with the dual SHA-1 and MD5 hash, for 1.2 with
whatever's
All,
The agenda has been posted:
https://datatracker.ietf.org/meeting/102/materials/agenda-102-tls-02
Note that we have two sessions:
tls Session 1 (2:00 requested)
Monday, 16 July 2018, Afternoon Session I 1330-1530
Room Name: Place du Canada size: 300
On Tue, Jul 10, 2018 at 11:46 AM Peter Gutmann
wrote:
> Hubert Kario writes:
>
> >but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1...
>
> but with EMS or LTS in effect, with a lot more than that.
>
EMS does not fix the ServerKeyExchange signature payload. It's still
On Tue, Jul 10, 2018 at 03:38:42PM +0200, Hubert Kario wrote:
> The github version of the document points out that the security of TLS 1.2
> downgrade protection to TLS 1.1 or TLS 1.0 depends on SHA-1.
Is this accurate? TLS 1.0 uses a combined SHA-1 + MD5 PRF. Are
there known attacks that
Hubert Kario writes:
>but randoms in TLS 1.0 and TLS 1.1 are signed (effectively) with SHA-1...
but with EMS or LTS in effect, with a lot more than that.
Peter.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Tuesday, 10 July 2018 16:03:24 CEST Eric Rescorla wrote:
> On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote:
> > On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> > > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > > > Is there any reason why we wouldn't
The IESG has received a request from the Transport Layer Security WG (tls) to
consider the following document: - 'Example Handshake Traces for TLS 1.3'
as Informational RFC
The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send
Viktor Dukhovni writes:
>also the private CAs using SHA-1 will need to switch to SHA-2 to regain
>interoperability, despite no actual risk from SHA-1.
Another problem with moving to SHA-2 is that when you have a lot of gear that
only does SHA-1, you need to run parallel PKIs possibly in
Foillowing up: of course this doesn't protect you from 1.2 -> 1.0 downgrade
unless you backport the mechanism to your 1.2 implementation, which I
expect many people will not do, despite the specs.
-Ekr
On Tue, Jul 10, 2018 at 7:03 AM, Eric Rescorla wrote:
>
>
> On Tue, Jul 10, 2018 at 6:38
nalini elkins writes:
>It would be nice to see some of this reflected in the draft rather than only
>statistics on browsers. The real usage of these protocols is far more
>complex.
+1. It often seems that the only possible use for TLS that gets considered in
these things is web browsers and
On Tue, Jul 10, 2018 at 6:38 AM, Hubert Kario wrote:
> On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> > On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > > Is there any reason why we wouldn't also consider deprecating cipher
> > > suites we don't like? For
On Tuesday, 10 July 2018 06:17:56 CEST Viktor Dukhovni wrote:
> On Tue, Jul 10, 2018 at 08:56:14AM +1000, Martin Thomson wrote:
> > Is there any reason why we wouldn't also consider deprecating cipher
> > suites we don't like? For instance, RFC 5246 mandates the
> > implementation of
Björn Haase writes:
>BTW, This is actually why we in the ICS business need TLS1.3 with its fast
>options on tiny devices such as X25519 and Ed25519. That's by integer factors
>faster on devices such as the M0 or the MSP430 than all of the fastest legacy
>options, such as P256!
How are you going
On Tuesday, 10 July 2018 08:47:15 CEST Björn Haase wrote:
> > Peter Gutmann wrote:
> >In addition, the security doesn't have to be theoretically perfect, just
> >good enough. An isolated network is frequently deemed secure enough,
> Mostly in my analysis the assumption of the "isolation" of the
Hi Nalini,
On 10/07/18 04:50, nalini elkins wrote:
> It would be nice to see some of this reflected in the draft rather than
> only statistics on browsers. The real usage of these protocols is far
> more complex.
I didn't have time before the I-D cutoff but have since
added a section on mail
24 matches
Mail list logo
