Subject: Re: [TLS] WGLC for "Deprecating TLSv1.0 and TLSv1.1"

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 May 2019 11:11:53 -0400

Thank you for your feedback in this review.  Responses inline as to how I
propose it is addressed:

On Sat, Apr 13, 2019 at 12:16 AM Martin Thomson <[email-masked]> wrote:

> Section 1.1 doesn't say *how* those listed documents are updated.  Might
> pay to include a few works on how.
>

Thank you, that was helpful feedback.  I changed the introduction text as
follows:
OLD:
This document updates these RFCs that normatively reference TLSv1.0 or
TLSv1.1 or DTLS1.0 and have not been obsoleted.
NEW:
 This document updates the following RFCs that normatively reference
TLSv1.0 or TLSv1.1 or DTLS1.0. The update is to obsolete usage of these
older versions. Fallback to these versions are prohibited through this
update.

Section 2 can be cut down a lot.  The quote from another document is longer
> than the rest of the text.  In many ways, saying that the IETF is moving
> last is not a great thing to memorialize in RFC, as much as it is useful in
> an Internet-Draft or in argumentation in support of publication of the doc.
>

A bunch has been cut out already, but I propose also cutting out the
following text to address your specific point (well taken):
1st paragraph and last 2.

REMOVE:
      Industry has actively followed guidance provided by NIST and the PCI
      Council to deprecate TLSv1.0 and TLSv1.1 by June 30, 2018. TLSv1.2
      should remain a minimum baseline for TLS support at this time.

      The Canadian government treasury board have also mandated that these
      old versions of TLS not be used.

      Various companies and web sites have announced plans to deprecate
      these old versions of TLS.

The title of Section 3 could be a bit clearer.
Proposed:
SHA-1 Usage Problematic in TLSv1.0 and TLSv1.1

If you have a more terse suggestion, please post.  I agree this should be
more clear.

>
> It might pay to explain what RFC 7525 is in Section 6.  Why does that
> document warrant special attention over the 70-odd other ones.
>

Good point, how about the following text:

PROPOSED:
RFC7525 is BCP195, "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security (DTLS)", is the mpost
recent best practice document for implementing TLS and was based off of
TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not yet been
deprecated. As such, this document is called out specifically to update
text implementing the deprecation recommendations of this document.

> Otherwise, publish this.

Thank you!

I'll continue through the rest of the messages, but may have a delay when
tending to other responsibilities.
I am putting the proposals into a new version to upload to the git
repository.

Best regards,
Kathleen

>
>
> On Sat, Apr 13, 2019, at 09:28, Christopher Wood wrote:
> > This is the working group last call for the "Deprecating TLSv1.0 and
> > TLSv1.1” draft available at:
> >
> >
> https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/
> >
> > Please review the document and send your comments to the list by April
> 26, 2019.
> >
> > Thanks,
> > Chris, Joe, and Sean
> >
> > _______________________________________________
> > TLS mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 May 2019 12:37:34 -0400

Maarten,

On Wed, Apr 24, 2019 at 3:43 AM Maarten Aertsen (NCSC-NL) <maarten.aertsen=
[email-masked]> wrote:

> Hi,
>
> On 13-4-2019 01:28, Christopher Wood wrote:
> I'd like to see this published.
>
> @Kathleen, Stephen: in case there's any value in an additional ref for
> section 2, we published updated TLS-guidelines yesterday, with clear
> advice to phase out TLSv1, TLSv1.1.
>
>
> https://www.ncsc.nl/english/current-topics/news/future-proof-tls-configuration-using-the-updated-tls-guidelines-from-ncsc.html

Thank you for your review and this additional information, it's great to
see more traction on this.  Since we've greatly reduced section 2, cutting
out this type of data, we'll leave it out.  It's in the mail archive now
though.  If there are disagreements on this text having been cut, please
speak up!

Best regards,
Kathleen

> kind regards, Maarten

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 May 2019 12:58:13 -0400

Hi Gary,

Thanks for your review and support.  I'll respond inline and if Stephen
disagrees, he will chime in :-)

On Wed, Apr 24, 2019 at 9:51 AM Gary Gapinski <gary=
[email-masked]> wrote:

> On 4/12/19 7:28 PM, Christopher Wood wrote:
>
> This is the working group last call for the "Deprecating TLSv1.0 and TLSv1.1” draft available at:
>
> Please review the document and send your comments to the list by April 26, 2019.
>
> I think the document should be published.
>
> I agree with Martin Thomson's observation that the SP 800-52r2 quotes in
> Section 2 are a bit prolix considering the relatively small content that
> would remain if excised, and that NIST document has been in draft for a
> prolonged time (reducing its authority). The quotes imply but do not demand
> disuse of TLS 1.0 and TLS 1.1, and could inadvertently be interpreted to
> mean that use of TLS 1.2 rather than TLS 1.3 is sinful.
>

I had interpreted Martin's comment's a little differently and cut out other
text.  Hmm, for the NIST quotes, I see this as providing the supporting
reasons and their recommendations not being the same as the recommendations
in this draft.  I think by the updated text Marten suggested on "updates",
this point is addressed, but please let us know if you feel otherwise.

> An additional (congenial) informative reference could be BSI TR-02102-2
> found at
>
>
> https://www.bsi.bund.de/EN/Publications/TechnicalGuidelines/tr02102/index_htm.html
>
> which in §3.2 states "TLS 1.0 and TLS 1.1 are *not recommended*".
>

Thank you for the reference, it's probably bets to have a couple of sources
here.  I included the following text with the pdf reference included in the
working copy:

The German Federal Office for Information Security, recommends against use
of TLS versions less than 1.2 in the publication <xref
target="TR-02102-2"
>Cryptographic Mechanisms: Recommendations and Key Lengths</xref>

Best regards,
Kathleen

> Regards,
> Gary

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 May 2019 13:02:38 -0400

Victor,

Thank you very much for your work and pushing the points on uses of TLS
outside of web as this is an important point.

On Thu, Apr 25, 2019 at 9:30 PM Viktor Dukhovni <[email-masked]>
wrote:

> > On Apr 12, 2019, at 7:28 PM, Christopher Wood <[email-masked]>
> wrote:
> >
> My concern is whether the time is yet nigh for TLS 1.0 to be disabled
> in opportunistic TLS in SMTP, or whether TLS 1.0 remains sufficiently
> common to cause deprecation to do more harm than good via unnecessary
> downgrades to cleartext.
>
> I don't have survey numbers for SMTP TLS protocol versions across MTAs
> generally to shed light on this, perhaps someone does.  What I do have
> is numbers for those MTAs (not a representative sample) that have DANE
> TLSA records (so presumably a greater focus on security).
>
> The observed version frequencies are approximately:
>
>         TLS 1.0:  1%
>         TLS 1.1:  0%
>         TLS 1.2: 87%
>         TLS 1.3: 12%
>
> essentially regardless of whether I deduplicate by name, IP or name and IP.
> The respective sample sizes are 5435, 6938 and 7959.
>
> So if a DANE-enabled sender were to disable TLS 1.0 today, approximately
> 1% of the destination MX hosts would be broken and need remediation.  These
> handle just of 189 mostly small SOHO domains out of the ~1.1 million total
> DANE SMTP domains, but four handle enough email to show up on the Gmail
> SMTP transparency report:
>
>   tu-darmstadt.de
>   t-2.net
>   t-2.com
>   t-2.si
>
> So on the whole, the draft should proceed, but some caution may be
> appropriate
> outside the browser space, before operators start switching off TLS 1.0
> support.
>
> I don't see an operational considerations section.  Nor much discussion of
> "less mainstream" (than Web browser) TLS application protocols.  Would a
> few
> words of caution be appropriate, or is it expected that by the time the RFC
> starts to change operator behaviour the "market share" of TLS 1.0 will be
> substantially lower than I see today even with SMTP, XMPP, NTTP and the
> like.
>
> [ I would speculate that TLS 1.0's share is noticeably higher among MTAs
>   generally than among the bleeding-edge MTAs that have published DANE TLSA
>   RRs. ]
>

My take on deprecation drafts is that once published, they take time
(years) before there is compliance.  Even with that, we may never achieve
full compliance and older version use continues. We do know that OpenSSL
will continue to support the version that came out last fall for 5 years
from that point in time.  Publication of the draft does not mean support
goes away at that point in time, but provides another push.  If there's a
strong feeling that text should be added, we could, but my preference would
be to leave it to the normal process for deprecation.

Thank you,
Kathleen

>         Viktor.

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 May 2019 13:04:29 -0400

On Fri, Apr 26, 2019 at 5:29 PM Viktor Dukhovni <[email-masked]>
wrote:

> > On Apr 26, 2019, at 11:24 AM, Salz, Rich <[email-masked]> wrote:
> >
> > If they haven’t already moved off TLS 1 then maybe this document will
> give the right people a push to do so.
> >
> > Nobody is going to arrest an MTA for non compliance.
>
> Of course.
>
> And as I said, I'd like to see the document move forward, I just
> wanted to see whether there was any appetite for adding some
> operator guidance.  It's not an issue of internet policing,
> rather it is a question of whether there should advice for
> operators who are considering disabling the legacy protocols.
>
> The sound-bite version is: first raise the ceiling, *then* the floor.
>
> The advice would therefore be for everyone to first make sure that
> their systems support at least TLS 1.2, and not just the now deprecated
> versions.  And then check whether the same holds true for their application
> ecosystem and if so disable the protocols at that time.
>
> In unauthenticated opportunistic TLS where cleartext is used when TLS
> handshakes fail, removing support for TLS 1.0 can reduce security in the
> short term (some messages needlessly going in cleartext).  Yes, this may
> be what it takes to finally get the long tail procrastinators to upgrade.
>
> The operational question then boils down to timing: when is your
> application
> ecosystem ready to drop the training wheels.
>
> Anyway, it does not look like there's much interest in adding operational
> considerations, which users will then perhaps learn about elsewhere if
> need be.  That's fine...
>

Thanks for your follow up assessment on this from the WG.  It seems we are
in agreement.

I appreciate your review, consideration, and attention to deployment
statistics for this move.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 2 May 2019 13:06:09 -0400

Hello Martin,

On Tue, Apr 30, 2019 at 7:50 PM Martin Rex <[email-masked]> wrote:

> Martin Thomson <[email-masked]> wrote:
> > On Sat, Apr 27, 2019, at 07:29, Viktor Dukhovni wrote:
> > Yep.  We've done the ceiling bit twice now.
> > Once in 2008 when we published TLS 1.2 and then in 2018
> > with the publication of TLS 1.3.  I'd say we're overdue for the floor
> bit.
>
> Just that this rationale is a blatant lie.
>
> It is formally provable that from the three protocol versions:
>
>  TLSv1.0, TLSv1.1, TLSv1.2
>
> the weakest one is TLSv1.2, because of the royally stupid downgrade
> in the strength of digitally signed.
>
>
> Disabling TLSv1.0 will only result in lots of interop failures
> and pain, but no improvement in security.
>
>
I believe this is the last outstanding comment, pending a reference. Thank
you for your review and contribution.

Best regards,
Kathleen

> -Martin

-- 

Best regards,
Kathleen

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 May 2019 19:51:57 -0400

Thanks Kathleen, these look like good changes.   

Nits in the proposed BCP195 section: Lose the "p" in mpost and s/off of/on/

On Fri, May 3, 2019, at 01:12, Kathleen Moriarty wrote:
> Thank you for your feedback in this review. Responses inline as to how 
> I propose it is addressed:
> 
> > Section 1.1 doesn't say *how* those listed documents are updated. Might pay to include a few works on how.
> 
> Thank you, that was helpful feedback. I changed the introduction text 
> as follows:
> OLD:
> >  Section 2 can be cut down a lot. The quote from another document is longer than the rest of the text. In many ways, saying that the IETF is moving last is not a great thing to memorialize in RFC, as much as it is useful in an Internet-Draft or in argumentation in support of publication of the doc.
> 
> If you have a more terse suggestion, please post. I agree this should 
> be more clear.
> > 
> >  It might pay to explain what RFC 7525 is in Section 6. Why does that document warrant special attention over the 70-odd other ones.
> 
> Security (TLS) and Datagram Transport Layer Security (DTLS)", is the 
> mpost recent best practice document for implementing TLS and was based 
> off of TLSv1.2. At the time of publication, TLSv1.0 and TLSv1.1 had not 
> yet been deprecated. As such, this document is called out specifically 
> to update text implementing the deprecation recommendations of this 
> document. 
> 
> > 
> >  Otherwise, publish this.
> 
> Thank you!
> 
> I'll continue through the rest of the messages, but may have a delay 
> when tending to other responsibilities.

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 May 2019 14:50:46 +0200

On Wednesday, 1 May 2019 01:49:52 CEST Martin Rex wrote:
> > with the publication of TLS 1.3.  I'd say we're overdue for the floor bit.
> 

We've been over this Martin, the theoretical research shows that for Merkle-
Damgård functions, combining them doesn't increase their security 
significantly.

And the practical research:
https://eprint.iacr.org/2016/131.pdf
https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf
only confirms that.

So, please, use a bit less inflammatory language when you have no factual 
arguments behind your assertions.
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 May 2019 10:02:57 -0400

> Nits in the proposed BCP195 section: Lose the "p" in mpost and s/off of/on/

Thank you, Martin!

> > >  Section 2 can be cut down a lot. The quote from another document is
> longer than the rest of the text. In many ways, saying that the IETF is
> moving last is not a great thing to memorialize in RFC, as much as it is
> useful in an Internet-Draft or in argumentation in support of publication
> of the doc.
> >

-- 

Best regards,
Kathleen

---

From: [email-masked] (Martin Rex)
Date: Fri, 3 May 2019 16:56:54 +0200 (CEST)

> Damgård functions, combining them doesn't increase their security 

You are completely misunderstanding the results.

The security is greatly increased!

Nobody is afraid of the exhaustive search preimage attacks.

What folks with a little crypto clue are afraid of is
significantly-faster-than-exhaustive-search real-time preimage attacks.
And this is where

  TLSv1.0 + TLSv1.1 (rsa,SHA1+MD5)

is *significantly* stronger than

  TLSv1.2 (rsa,MD5) *cough* -- which a depressingly high number of clueless
          implementers actually implemented, see SLOTH
  TLSv1.2 (rsa,SHA1)

That is also trivially formally provable.

Assume that a real-time preimage attack for *one* of the functions is
discovered, and compare the resulting efforts.

-Martin

---

From: Hubert Kario <[email-masked]>
Date: Fri, 03 May 2019 17:23:28 +0200

On Friday, 3 May 2019 16:56:54 CEST Martin Rex wrote:
> > We've been over this Martin, the theoretical research shows that for
> > Merkle- Damgård functions, combining them doesn't increase their security
> > significantly.
> 

I'm eagerly waiting on your published paper on the topic.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 3 May 2019 16:53:44 +0000

>https://www.iacr.org/archive/asiacrypt2009/59120136/59120136.pdf

That would be the practical research that says:

  Due to these constraints, the practical impact of our second preimage attack
  is limited and its main significance is theoretical.

This is obviously some strange use of the word "practical" that I wasn't
previously aware of.

The other one is a bit too vague to comment on:

  would lead to an attack on the combiner MD5 || SHA-1 with complexity less
  than 2^59 (assuming the type 1 collision attack on SHA-1 is fast enough).

"assuming" and "fast enough" could mean anything ("this leads to an attack on
AES-GCM with complexity less than 2^59 assuming the key recovery attack on
AES-128 is fast enough").  However earlier on the paper says:

  Let’s further assume that a breakthrough in cryptanalysis of SHA-1 brings
  down the complexity of a collision search attack to 2^52. We know that the
  best collision search attacks on MD5 are as fast as 2^15

So what's being shown is that the strength is 2^59 assuming some unspecified
but pretty spectacular new attack on SHA-1 suddenly turns up, rather than e.g.
2^(52+15) = 2^67.

Even with the appearance of this imaginary new attack, the security of
MD5||SHA1 is still better than either MD5 or SHA-1 by itself, which is what
TLS 1.2 specifies.  So I think Martin's point is proven.

Peter.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 3 May 2019 12:20:22 -0500

On Fri, May 03, 2019 at 04:53:44PM +0000, Peter Gutmann wrote:
> but pretty spectacular new attack on SHA-1 suddenly turns up, rather than e..g.
> 2^(52+15) = 2^67.
> 

I'll make the obligatory note that SHA-2 is fine, and if you decide that
neither MD5 nor SHA1 are in great shape and decide to not use them at
all (whether along or in combination), you are also doing fine.
It's not like publishing another RFC is going to magically change the
behavior of the already deployed systems that people are currently using
these things with, after all, and if someone does change their system,
are really going to recommend they go to TLS 1.0 with MD5||SHA1 rather
than TLS 1.2 with SHA2?

-Ben

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 3 May 2019 17:30:38 +0000

Benjamin Kaduk <[email-masked]> writes:

>I'll make the obligatory note that SHA-2 is fine

Sure, and that was the really strange thing with TLS 1.2, why not just say
SHA-2 or better only, rather than adding mechanisms that were much, much
weaker than its predecessors?  So the simple fix is just to use SHA-2 only for
TLS 1.2.

>if someone does change their system, are really going to recommend they go to
>TLS 1.0 with MD5||SHA1 rather than TLS 1.2 with SHA2?

That would be one argument for an RFC, MUST SHA-2 only or MUST NOT MD5 and
SHA-1 in 1.2.  Which is pretty much what TLS-LTS says.  Or at least it takes
the SHA-2-suites-mandatory path which implies no MD5 or SHA-1, I guess I
should also add an explicit MUST NOT MD5 and SHA-1.

Having said that, given an RFC saying MUST NOT 1.0 and 1.1 which is what the
original discussion was about, why not also add MUST NOT MD5 and SHA1 in TLS
1.2 to the text?

Peter.

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 May 2019 13:36:39 -0400

> On May 3, 2019, at 1:30 PM, Peter Gutmann <[email-masked]> wrote:
> 

And perhaps MUST EtM, ... which starts to look a lot like "must TLS-LTS"... :-)
If we really are raising the floor, just the protocol version is ultimately only
part of the story.  The whole story is TLS 1.2 minus a lot of options plus a few
requirements.

-- 
	Viktor.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 3 May 2019 12:56:50 -0700

> original discussion was about, why not also add MUST NOT MD5 and SHA1 in

This seems like a reasonable proposal.

-Ekr

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 May 2019 16:09:16 -0400

Sent from my mobile device

> On May 3, 2019, at 3:56 PM, Eric Rescorla <[email-masked]> wrote:
> 
> 
> 
>> On Fri, May 3, 2019 at 10:31 AM Peter Gutmann <[email-masked]> wrote:

If added, should this just be in the updates section for RFC7525?

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 3 May 2019 16:39:36 -0400

> If added, should this just be in the updates section for RFC7525?

If done here, the text below would change to MUST and we'd likely need
another WGLC, correct?

   When using RSA, servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is RECOMMENDED (see [CAB-Baseline
<https://tools.ietf.org/html/rfc7525#ref-CAB-Baseline>] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined in
   TLS 1.2.

The MUST NOT for SHA-1 is not clearly stated in RFC7525 as far as I can see.

Proposed:

   When using RSA, servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is the minimum requirement, SHA-1
MUST not be used (see [CAB-Baseline
<https://tools.ietf.org/html/rfc7525#ref-CAB-Baseline>] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined in
   TLS 1.2.

MD5 is not discussed in the current version of RFC7525.

Best regards,

Kathleen

-- 

Best regards,
Kathleen

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 4 May 2019 02:46:22 +0000

>MD5 is not discussed in the current version of RFC7525.

I would add it, if this is guidance for general use then it should cover all
the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY MUST NOT.

(Technically SHA-1 is still safe for ephemeral signing, i.e. locations where
an attacker can't spend arbitrary amounts of time working on precomputed data,
which is most of TLS because of the nonces in the handshake and the fact that
connections will quickly time out if nothing arrives, but since TLS 1.2 has
SHA-2 built in already there's probably little point in separating out where
SHA-1 is safe vs. where it isn't).

Peter.

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 4 May 2019 09:00:17 -0400

On Fri, May 3, 2019 at 10:46 PM Peter Gutmann <[email-masked]>
wrote:

> Kathleen Moriarty <[email-masked]> writes:
>

Sure, I agree, but needed to look through prior documents first.  Since it
wasn't in RFC7525 as a recommendation and the minimum baseline was above
MD5, I suspect that is why it is not mentioned.   If there is support (and
no disagreements) the text above could be added and include SHA-1 and MD5
MUST NOT be used.  The minimum baseline is already set above it though in
the statement.

WG decision is appreciated on this point and proposed text for RFC 7525.

Proposed:

   When using RSA, servers SHOULD authenticate using certificates with
   at least a 2048-bit modulus for the public key.  In addition, the use
   of the SHA-256 hash algorithm is the minimum requirement, SHA-1 and
MD5 MUST not be used (see [CAB-Baseline
<https://tools.ietf.org/html/rfc7525#ref-CAB-Baseline>] for
   more details).  Clients SHOULD indicate to servers that they request
   SHA-256, by using the "Signature Algorithms" extension defined in
   TLS 1.2.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 06 May 2019 00:18:00 -0400

On Sat, May 4, 2019, at 23:01, Kathleen Moriarty wrote:
> Proposed:   When using RSA, servers SHOULD authenticate using 
> certificates with

Whether the chairs want this here or in a new thread, I fully endorse this.  I don't think that I can safely turn SHA-1 off today, but it's definitely on the list.  We don't even have code for MD5 in the stack any more, except for the weird paired hash thing in TLS <1.2.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 06 May 2019 13:18:55 +0200

> The security is greatly increased!

like I said, that were the follow up papers

the original is still Joux:
https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf

>           implementers actually implemented, see SLOTH

SLOTH? You mean the same one in which Bhargavan and Leurent write:

Concatenation: To  strengthen  protocols  against  collisions  in  any  one  
hash  function,  it  may  be  tempting  to use  a  combination  of  two  
independent  hash  functions. For example, TLS versions up to 1.1 use a 
concatenation of  MD5  and  SHA-1.  While  the  output  length  of  this 
construction  is  288  bits,  it  does  not  offer  the  security of a 288-bit 
hash function. In particular, Joux described a  multi-collision  attack  that  
breaks  the  concatenation of  two  hash  functions  with  roughly  the  same  
effort  as breaking the strongest one of the two [18].
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Hubert Kario <[email-masked]>
Date: Mon, 06 May 2019 13:21:44 +0200

On Friday, 3 May 2019 19:30:38 CEST Peter Gutmann wrote:
> weaker than its predecessors?  So the simple fix is just to use SHA-2 only
> for TLS 1.2.

I don't know as I wasn't there when that was discussed, but one reason could 
be the same as the problems we are facing now with RSA-PSS in TLS 1.3: 
smartcards and HSMs that are limited to old algorithms.
Also, don't forget that signature_algorithms, at least in theory[1], was 
supposed to also influence server certificate selection, and SHA-1 was used in 
vast majority of certificates in PKI.

> >if someone does change their system, are really going to recommend they go
> >to TLS 1.0 with MD5||SHA1 rather than TLS 1.2 with SHA2?
> 
> original discussion was about, why not also add MUST NOT MD5 and SHA1 in
> TLS 1.2 to the text?

I've already suggested it with the draft authors, the conclusion was that it 
probably should be a separate RFC.

 1 - while in practice one popular implementation actually used it as a 
     "required" list – it would abort connections when the sigalg of the 
     certificate it had wasn't included in the ClientHello
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Töma Gavrichenkov <[email-masked]>
Date: Mon, 6 May 2019 14:39:52 +0300

On Fri, May 3, 2019 at 8:31 PM Peter Gutmann <[email-masked]> wrote:
> why not also add MUST NOT MD5 and SHA1 in TLS 1.2 to the text?

Because the document has now such a direct and ambitious title that
~most of the target audience won't even read the text beyond the
title, hence this message won't be delivered.

This is exactly the trick (but with exactly the opposite sign) PCI SSC
performed three years ago when they published the document called
"Migrating from SSL and Early TLS, version 1.1" and the general public
widely believed that the document deprecated TLS 1.1 while what it
literally meant under "Early TLS" was ultimately TLS 1.0. Only the
*document version* was 1.1, but it was enough for quite a lot of
people who sometimes didn't even read the document at all but rather
sticked to short summaries by Arstechnica, The Register and the likes
(who, in turn, quite frequently don't read documents carefully
themselves).

Might play well though if the title is changed.

--
Töma

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 6 May 2019 09:39:17 -0500

>    SHA-256, by using the "Signature Algorithms" extension defined in

We'd probably want to wordsmith it a bit more, as there's not exactly a
strict ordering on hash function strength, and "minimum requirement"
could be taken to mean "MUST use SHA-256", which is presumably not the
intent.

-Ben

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 6 May 2019 10:42:30 -0400

On Mon, May 6, 2019 at 10:39 AM Benjamin Kaduk <[email-masked]> wrote:

> > On Fri, May 3, 2019 at 10:46 PM Peter Gutmann <[email-masked]
> >
> > wrote:
> >
> > > I would add it, if this is guidance for general use then it should
> cover
> > > all
> > > the bases, if SHA-1 is a MUST NOT then MD5 is a REALLY REALLY REALLY
> MUST
> > > NOT.
> > >
> > > an attacker can't spend arbitrary amounts of time working on
> precomputed
> > > data,
> > > which is most of TLS because of the nonces in the handshake and the
> fact
> > > that

If this goes in, suggestions are welcome as we're trying to wrap this up.
If it's a separate document, then I think we're done with the last call
comments.

Thanks,
Kathleen

-- 

Best regards,
Kathleen

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 6 May 2019 17:44:48 +0000

HSMs are more likely than not to support SHA-2. Smartcards rarely perform hash themselves, relying on the software that uses them.

Alas. Only in some (albeit large) enclaves.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 6 May 2019 13:50:42 -0400

On Mon, May 6, 2019 at 1:45 PM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> HSMs are more likely than not to support SHA-2. Smartcards rarely perform
> hash themselves, relying on the software that uses them.
>
>

Is this better suited for another (short) draft?

Best,
Kathleen

-- 

Best regards,
Kathleen

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 May 2019 14:36:25 -0400

> On May 6, 2019, at 7:18 AM, Hubert Kario <[email-masked]> wrote:
> 
> ncatenation: To  strengthen  protocols  against  collisions  in  any  one  

With the proviso that the attack on the second hash function is *generic*
(i.e. 2^{n/2} brute-force).  Thus the attack on SHA-1 + MD5, has a cost
of 64 * cost of SHA-1 collision + O(2^64) MD5 operations (with the associated
memory costs of finding the collision).

Yes, it is far from as strong as a real 288-bit hash, and one would not
choose the construction in a new standard, but in *practice* it is likely
stronger than SHA-1, even if it is far from the strength one might naïvely
hope for.

The hypothetical Joux multi-collision attack on SHA1-MD5 would have to attack
the protocol in a way that can make use of collisions rather than the much
harder to find pre-images.  Are you aware of any attacks that reduce the
pre-image resistance of SHA-1+MD5 to that of SHA-1?

There's quite a gap between (rightly) concluding that concatenated hash
functions are not a good crypto building block, to concluding that a
particular construction is no stronger in practice in a particular
protocol.

Which is not to say that I have a concrete stength estimate for SHA-1+MD5 
vs. SHA-1 in TLS. Rather, the practical implication of the multi-collisions
attacks is more subtle than the basic theoretical conclusion that invalidates
their naïve strength estimate.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 May 2019 14:41:41 -0400

> Is this better suited for another (short) draft?

SHA-1 certificates are history now.  If we're raising the floor,
it should IMHO be safe to deprecate the MD5 and SHA-1 signature
algorithms from TLS 1.2.

Does anyone have evidence of medium to long-term requirements for
continued SHA-1 sigalg support?

-- 
	Viktor.

---

From: David Benjamin <[email-masked]>
Date: Mon, 6 May 2019 14:02:18 -0500

> continued SHA-1 sigalg support?

I've been following this one for some time now. Sadly, we still see quite a
lot of SHA-1 sigalg usage with RSA, even more than we see TLS 1.0 and 1.1.
(We already removed SHA-1 with ECDSA a couple years ago.) Some of it is
because older Schannel will preferentially sign SHA-1 when offered, which
is not a problem for removal but confounds metrics. Some of it is a bug in
older OpenSSLs where, on connections with SNI, it loses track of the peer
signature algorithm preferences and then assumes SHA-1 by default. Some of
it is load balancers which implemented TLS 1.2 but failed to actually
implement sigalg negotiation, and thus only sign SHA-1.

This is a consequence of text in RFC 5246 which says, when the extension is
missing, the server should take SHA-1 as default. With the benefit of
hindsight, I think that was a mistake. It meant bugs like OpenSSL's get
papered over with SHA-1, and any implementors that chose to only sign one
algorithm would pick SHA-1.
https://tools.ietf.org/html/rfc5246#section-7.4.1.4.1

(This is not to say there shouldn't be text in this document or another
that discourages those, or requires servers be able to sign some SHA-2
hash. But I don't expect those to be removable on the web until after TLS
1.0 and 1.1.)

David

---

From: [email-masked] (Martin Rex)
Date: Tue, 7 May 2019 01:57:30 +0200 (CEST)

> https://www.iacr.org/archive/crypto2004/31520306/multicollisions.pdf

Thanks to Peter Gutmann for the summary:

    https://mailarchive.ietf.org/arch/msg/tls/g0MDCdZcHsvZefv4V8fssXMeEHs

which you may have missed.

> SLOTH?

SLOTH is a brainfart in the TLSv1.2 spec which is blatently obvious.

If (md5,rsa) was actually shipped in a TLSv1.2 implementation, it indicates
a dysfunctional (or crypto-clueless) QA for the project.

The erroneous implementation of (md5,rsa) was silently removed from openssl
*without* CVE, after I privately complained about this brainfart having
been added to openssl.

I ranted about the TLSv1.2 digitally_signed brainfart in rfc5246 on
the IETF TLS WG mailing list here (01-Oct-2013):

    https://mailarchive.ietf.org/arch/msg/tls/l_R94xX7myvL9x8I_7L7NiDjV9w

assuming that crypto clue and common sense should work.

Looking at what was still affected by the problem end of 2014,
it seems that you *MUST* hit TLS implementors with a CVE

    https://www.mitls.org/pages/attacks/SLOTH#disclosure

and can not rely on crypto-clue and common sense.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 7 May 2019 10:34:46 +0000

David Benjamin <[email-masked]> writes:

>It meant bugs like OpenSSL's get papered over with SHA-1

That affects a whole lot more than just OpenSSL, a bit like ECDSA means P256
so hash means SHA-1.  Try switching to SHA-2 (in non-TLS usage) and you'll
find all the implementations that simply default to SHA-1, or, worse, skip any
algorithm indication that may be present and just assume the other side will
do SHA-1. Which so far has worked well enough that no-one's noticed that other
options don't.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 07 May 2019 13:12:21 +0200

> which you may have missed.

yes, Joux paper also shows that attacking MD5||SHA1 is harder than attacking  
SHA1 alone

but that doesn't matter, what matters is _how much harder it is_ and Joux 
paper says that it's less than a work factor of two, something also knows as a 
"rounding error" for cryptographic attacks

---

From: [email-masked] (Martin Rex)
Date: Wed, 8 May 2019 02:31:57 +0200 (CEST)

Hubert Kario <[email-masked]> wrote:
> paper says that it's less than a work factor of two, something also knows
> as a "rounding error" for cryptographic attacks

collision attacks and real-time 2nd preimage attacks on randomly keyed
hashes are substantially different things.

simple math seems hard.

TLSv1.0 + TLSv1.1 both use   (rsa, MD5||SHA1)

TLSv1.2 (rfc5246) permitted (rsa, MD5) and allows (rsa,SHA1)

if we assumed that there *existed* (it currently doesn't, mind you)

a successful preimage attack on MD5  with effort  2^20
a successful preimage attack on SHA1 with effort  2^56

then if Joux would apply not just to multicollisons, but also 2nd preimage,

then the efforts would be:

  TLSv1.2 (rsa,MD5)  2^20
  TLSv1.2 (rsa,SHA1) 2^56

  TLSv1.0 (rsa, MD5||SHA1) >= 2^57 (slightly more than the stronger of the two)

Comparing  TLSv1.0 (rsa,MD5||SHA1) 2^57  with TLSv1.2 (rsa,MD5) 2^20

A factor 2^37 is significantly more than "marginally stronger".

If you are aware of successfull 2nd preimage attacks on
either MD5 or SHA1, please provide references.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 9 May 2019 06:08:50 +0000

Benjamin Kaduk <[email-masked]> writes:

>strict ordering on hash function strength, and "minimum requirement" could be
>taken to mean "MUST use SHA-256", which is presumably not the intent.

You could just say "use SHA-2", which covers the whole family.  Now in
practice "SHA-2" means "SHA-256" so it'll be the same as saying SHA-256
directly, but the more generic SHA-2 leaves it open to interpretation for the
three people who use something other than SHA-256.

Peter.

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 09 May 2019 02:41:15 -0400

> three people who use something other than SHA-256.

Though I don't think we'll see it happen any time soon, I don't think we want to completely close the door on new hash functions.  SHA-3 might be dead, but that doesn't mean we won't eventually be motivated to move to another one.

>From memory, we see a non-trivial amount of SHA-384, though that might just be in its pairing with AES-256-GCM.  It's routinely paired with P-384, which we do get a little bit of.  We even have P-521 in quantities large enough that we can't turn it off, which is likely paired with SHA-512.

---

From: Hubert Kario <[email-masked]>
Date: Thu, 09 May 2019 11:25:17 +0200

On Wednesday, 8 May 2019 02:31:57 CEST Martin Rex wrote:
> > yes, Joux paper also shows that attacking MD5||SHA1 is harder than
> > attacking SHA1 alone
> > 

side note on that, with ECDSA, all three versions use (ecdsa, sha1) so 
everything we are discussing applies to RSA and RSA only

> A factor 2^37 is significantly more than "marginally stronger".

MD5 was deprecated and removed by basically every library and can't be used in 
TLS 1.2, I specifically meant SHA1

> either MD5 or SHA1, please provide references.

"attacks only get better with time"

---

From: [email-masked] (Martin Rex)
Date: Fri, 10 May 2019 00:24:49 +0200 (CEST)

> everything we are discussing applies to RSA and RSA only

(EC)DSA is fatally flawed (design flaw), no-one should be using it.
EdDSA once it becomes available, might be OK.

I guess that all existing TLS implementations with ECDSA support might
be leaking (enough info to compute) the ECDSA private key to a mere passive
observer of a few thousand full TLS_ECHDE_ECDSA_ handshakes.

> 
> MD5 was deprecated and removed by basically every library
> and can't be used in TLS 1.2, I specifically meant SHA1

MD5 deprecated ?  Nope, glaring emtpy:
              https://www.rfc-editor.org/errata_search.php?rfc=5246

MD5 removed ? Mostly, but several implementors had to be prodded with
              with CVE-2015-7575 (SLOTH) to remove it.

The real issue at hand is:

  Prohibiting TLSv1.0 and TLSv1.1 is going to result in lots of
  interop problems, while at the same time providing *ZERO*
  security benefit.

  The installed base of software which is limited to TLSv1.0
  for outgoing TLS-protected communication is huge.

  What *WOULD* provide *HUGE* benefit, would be to remove the
  dangerous "protocol version downgrade dance" from careless applications,
  that is the actual problem known as POODLE, because this subverts the
  cryptographic procection of the TLS handshake protocol.

  We've known this downgrade dance to be a problem since the discussion
  of what became rfc5746.  Prohibiting automatic protoocol version
  downgrade dances is going to ensure that two communication peers
  that support TLSv1.2 will not negotiate a lower TLS protocol version.

  If applications doing downgrade dances had at least a basic amount
  of risk management, and would refuse to perform an unlimited amount
  of downgrades automatically and secretly, then everyone would be
  much better of.

  I've seen web browsers doing this entirely without risk management,
  and wasn't there some Java class which also did this?

And PLEASE stop unconditionally bashing SHA-1

I am constantly seeing crypto-clueless folks, including some national
governmental agencies, that are giving out their own TLS recommendations,
which are typically sterile of scientific rationale, and it's pretty
obvious those folks either haven't read US NIST SP 800-57 part 1 rev.4
or not understood it.  In particular Table 3 on top of page 54, about
the signficant difference between sha1WithRsaEncryption and HMAC-SHA1
e.g. when used for integrity protection by a TLS cipher suites such
as the TLSv1.2 MTI cipher suite TLS_RSA_WITH_AES_128_CBC_SHA.

Security      Digital Signatures and       HMAC, Key Derivation Functions
Strength      hash-only applications       Random Number Generation

no <=80 no no no no  SHA-1  no no no no no no no no no no no no no no

  112      SHA-224,SHA-512/224,SHA3-224

  128      SHA-256,SHA-512/256,SHA3-256           SHA-1

  192          SHA-384,SHA3-384              SHA-224,SHA-512/224

 >=256         SHA-512,SHA3-512            SHA-256,SHA-512/256,SHA-384
                                                SHA-512, SHA3-512

In particular, if you compare HMAC-SHA1 to the shorter&weaker GMAC integrity
protection afforded by AES-GCM cipher suites (rfc5288,rfc5289)
or the even shorter&weaker integrity protection afforded
by AES-CCM cipher suites (rfc6655).

Lots of folks erroneously believe that
   TLS_RSA_WITH_AES_128_GCM_SHA256
and more so
   TLS_RSA_WITH_AES_256_GCM_SHA384

would provider stronger integrity protection than

   TLS_RSA_WITH_AES_128_CBC_SHA

while in reality, it is just the opposite.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 10 May 2019 06:04:23 +0000

Martin Rex <[email-masked]> writes:

>What *WOULD* provide *HUGE* benefit, would be to remove the dangerous
>"protocol version downgrade dance" from careless applications, that is the
>actual problem known as POODLE, because this subverts the cryptographic
>procection of the TLS handshake protocol.

Is there anything apart from web browsers that engage in this silliness?  I've
never seen it, it's always just "connect with the one true protocol version
and suite" and that's it.

Now admittedly that might be TLS 1.0 with RSA key exchange being selected as
the one true protocol suite (in 2019!), but at least they don't do a downgrade
dance.

>And PLEASE stop unconditionally bashing SHA-1

+1.  It goes well beyond TLS, I've had some totally inane arguments with
people who just seem to want to repeat "SHA-1 bad! SHA-1 bad! SHA-1 bad!"
without being able to explain why it's bad when questioned, i.e. there's no
actual attack possible.  It's a problem when used with long-term signatures
like certs.  It's typically not a problem when used with anything else.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 13 May 2019 13:30:24 +0200

>               with CVE-2015-7575 (SLOTH) to remove it.

I meant in practice

>   interop problems, while at the same time providing *ZERO*

that's your opinion, not an established fact

>   that support TLSv1.2 will not negotiate a lower TLS protocol version.

which exact piece of popular software actually still does that? It ain't curl, 
it ain't Chrome, it ain't Firefox. It also isn't something done automatically 
by any TLS implementation that's even remotely popular: OpenSSL, NSS, GnuTLS, 
schannel, Secure Transport, go...

> And PLEASE stop unconditionally bashing SHA-1

that's a strawman, I was talking about SHA-1 signatures

---

From: [email-masked] (Martin Rex)
Date: Tue, 14 May 2019 16:52:49 +0200 (CEST)

Hubert Kario <[email-masked]> wrote:
> Martin Rex wrote:

You got this backwards.

There is a bold assertion that disabling TLSv1.0 and TLSv1.1 (alone)
would provide security benefits, but a complete lack of proof.
On digitally_signed, is proven that TLSv1.2 as defined by rfc5246
is the weakest of them all.

> which exact piece of popular software actually still does that?
> It ain't curl, it ain't Chrome, it ain't Firefox.

It definitely was implemented in Chrome and Firefox, which is how this
poor document got onto standards track:
   
   https://tools.ietf.org/html/rfc7507

 TLS Fallback Signaling Cipher Suite Value (SCSV)
    for Preventing Protocol Downgrade Attacks

>
> It also isn't something done automatically 
> by any TLS implementation that's even remotely popular:
> OpenSSL, NSS, GnuTLS, schannel, Secure Transport, go...

It is impossible to do this transparently, because the a connection
is ususable after a fatal TLS hanshake failure (or unexpected socket closure).

Any application-level cleartext negotiation will have to be repeated
as well, and the TLS implementation typically does not know about it.
(such as HTTP CONNECT or STARTTLS)

The POODLE paper
   https://www.openssl.org/~bodo/ssl-poodle.pdf

asserts that many clients doing downgrade dances exist, and at the
time of publication, this includes Mozilla Firefox, Google Chrome and
Microsoft Internet Explorer.

-Martin

---

From: David Benjamin <[email-masked]>
Date: Tue, 14 May 2019 12:32:23 -0400

> Microsoft Internet Explorer.

Chrome has not done a downgrade dance for over three years now (Chrome 50,
released in April 2016), even for TLS 1.3. Indeed much of the fuss around
TLS 1.3 was so clients could avoid repeating this mess.

David

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 14 May 2019 13:32:46 -0400

> TLS 1.3 was so clients could avoid repeating this mess.

Martin,

There's also value in people having fewer choices as security problems are
often the result of misconfigurations.  A lower number of protocols to
support, chose from, and configure correctly is helpful to the larger
number of implementers.  Additionally, there is at least one library that
planned to remove support for 1.0 and 1.1.  This means that is product
teams need to continue support, they have to run an older version of the
library, plus newer ones for 1.3.  This gets messy and increases the chance
of error.  The chance of misconfiguration is not insignificant (by product
teams or implementers of those products).

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Hubert Kario <[email-masked]>
Date: Tue, 14 May 2019 20:11:28 +0200

> would provide security benefits, but a complete lack of proof.

there are attacks, like BEAST, that TLS 1.0 is vulnerable to that TLS 1.1 and 
TLS 1.2 are not - that's a fact
there are ciphersuites that are invulnerable to Lucky13 and similar style of 
attacks that can not be used with TLS 1.0 or TLS 1.1 - that's a fact

that doesn't sound to me like "ZERO security benefit", and similar issues were 
the reason why we generally don't use SSL2 and SSL3 any more and why RFC 7568 
was published

> is the weakest of them all.

yes, provided that:
 - MD5 is actually in use
 - or Joux does not hold and MD5+SHA1 is _meaningfully_ stronger[1] than SHA-1 
   alone *and* SHA-1 is actually in use

those are big if's

 1 - where meaningfully = at least by a work factor of 2^10
 
> poor document got onto standards track:

key words: "still" and "was"
 
> Microsoft Internet Explorer.

either we consider clients that haven't been updated for half a decade now to 
be of importance, then disabling support for old protocol versions has 
meaningful security benefit, or we ignore them as they include insignificant 
percentage of users and are vulnerable to much easier attacks anyway

so, which way is it?

---

From: [email-masked] (Martin Rex)
Date: Tue, 14 May 2019 22:52:58 +0200 (CEST)

Hubert Kario <[email-masked]> wrote:
> 
> there are attacks, like BEAST, that TLS 1.0 is vulnerable to that
> TLS 1.1 and TLS 1.2 are not - that's a fact there are ciphersuites
> that are invulnerable to Lucky13 and similar style of attacks that
> can not be used with TLS 1.0 or TLS 1.1 - that's a fact

BEAST is an attack against Web Browsers (and the abuse known as SSL-VPNs),
it is *NO* attack against TLS -- whose design properties are described
in appendix F of rfc5246, and there is a trivial workaround for those
few apps that were affected.  Continued mentioning of BEAST really
only means one thing: severe crypto-cluelessness.

  http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html

There are two things that BEAST showed:
   Running arbitrary attacker-supplied active content is a bad idea!
   Performing protocol version downgrade dances is a bad idea.

Lucky thirteen applies equally to all three:  TLSv1.0, TLSv1.1 and TLSv1.2,
but was a real-world issue only for borked implementations of DTLS (those
implementations that were providing a no-limits guessing oracle.

> 
> that doesn't sound to me like "ZERO security benefit",

You seem to be confusing the difference between
  (1) ensuring that TLSv1.2 support is enabled
with
  (2) disabling TLSv1.0 + TLSv1.1 support.

If you do (1), then (2) does not add security benefits.

>  - or Joux does not hold and MD5+SHA1 is _meaningfully_ stronger[1]
>     than SHA-1 alone *and* SHA-1 is actually in use

MD5 || SHA-1  is **ALWAYS** meaninfully stronger than SHA-1 alone, *NO* if!

> percentage of users and are vulnerable to much easier attacks anyway

MSIE seems to still be doing downgrade dances _today_, btw.

-Martin

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 20 May 2019 09:28:44 +0000

Martin Rex <[email-masked]> writes:

>BEAST is an attack against Web Browsers (and the abuse known as SSL-VPNs), it
>is *NO* attack against TLS 

That actually applies to an awful lot of recent attacks on TLS - they're
attacks that rely on web software that's actively cooperating with the
attacker, not attacks on TLS per se.  Similar issues affect numerous attacks
on CMS (branded as S/MIME in email) and OpenPGP, they require mail software
that actively cooperates with the attacker.

For any new attack on a protocol like TLS, you really need a three-stage
summary of what's vulnerable:

1. Web-based use of TLS: Pretty much everything.
2. Non-web-based use of TLS: Very little.
3. Non-web-based with a few basic mitigations (EMS, EtM): Nothing, or close to it.

Peter.