Subject: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

From: "Valery Smyslov" <[email-masked]>
Date: Sun, 26 Apr 2020 12:35:30 +0300

Hi,

during the last  virtual interim meeting the draft 
draft-sheffer-uta-bcp195bis-00 was presented and the authors asked for its
adoption.
The general feeling in the room was in favor of the adoption, however
the authors were asked to rename it to *-rfc7525-bis.
The authors have renamed the draft and asked the chairs for its adoption. 
Since our responsible AD thinks agrees that this work is within the charter
of the WG, the chairs are issuing a formal call for adoption
to confirm the results we had at the meeting.

This message starts a two weeks call for adoption of the
draft-sheffer-uta-rfc7525bis-00 draft.
The call will end up 10 May 2020. Please send your opinions to the list
before this date.

Please if possible include any reasons supporting your opinion. If you
support this adoption, 
please indicate whether you are ready to review this draft if it becomes a
WG document.

Regards,
Leif & Valery.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 26 Apr 2020 16:16:19 +0100

I had a look at the draft and the text is just that of
the current BCP195 for now.

I support adoption - now that TLS1.3 is done it seems a
good time to start on this. I'll review and comment as
it goes.

S.

On 26/04/2020 10:35, Valery Smyslov wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: "John R. Levine" <[email-masked]>
Date: 26 Apr 2020 22:37:43 -0400

> The authors have renamed the draft and asked the chairs for its adoption.

Hi from e-mail land.  We took a look and noticed that 7525 offers poor 
advice about STARTTLS so I encourage you to adopt the draft so we can fix 
it.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "tom petch" <[email-masked]>
Date: Mon, 27 Apr 2020 10:03:46 +0100

What is the point of rfc7525bis?  Why do we need it?

It seems to me that RFC7525 is a good set of recommendations and little has changed, in practical terms, since it was produced, although cryptanalysts can find weaknesses therein

---
New Outlook Express and Windows Live Mail replacement - get it here:
https://www.oeclassic.com/

.

The one change I am aware of is that the TLS WG has produced TLS 1.3 - I follow the TLS WG mailing list - but so what?  TLS 1.3 failed to meet one key requirement and I am unclear whether or not TLS 1.3 will gain widespread use in the Internet, with HTTP, SMTP and such like.  I see TLS 1.2 as being adequate for most purposes for some time to come so my concern is that rfc5575bis will simply be an endorsement of the work of the TLS WG - 1.3 is great, ditch everything else - leading to further fragmentation of the protocols.

So, I am against adoption until it is clear that the I-D will endorse TLS 1.2 as adequate for most purposes.  After all, the TLS WG has yet to propose an I-D 'TLS 1.2 - Die, Die, Die'

Tom Petch 

----- Original Message -----
From: Valery Smyslov <[email-masked]>
To: <[email-masked]>
Cc: 'Yaron Sheffer' <[email-masked]>, <[email-masked]>, 'Ralph Holz' <[email-masked]>, 'Peter Saint-Andre' <[email-masked]>
Sent: 26/04/2020 10:35:30
Subject: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00
________________________________________________________________________________

Hi,

Regards,
Leif & Valery.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Apr 2020 10:07:02 +0100

> It seems to me that RFC7525 is a good set of recommendations and little has changed, in practical terms, since it was produced, although cryptanalysts can find weaknesses therein
It doesn't address TLS 1.3 and recommendations for it are going to be 
different.(draft-sheffer-uta-rfc7525bis-00 probably doesn't include TLS 
1.3 text, but the plan is that it will.)
> ..

---

From: Ralph Holz <[email-masked]>
Date: Mon, 27 Apr 2020 21:25:43 +1000

Hi,

I am not sure which key requirement you are referring to, or why TLS 1.3
should not see widespread use. In fact, TLS 1.3 is getting much more
traction already than TLS 1.2 ever had in a comparable amount of time:
https://arxiv.org/abs/1907.12762. I am not sure why you speak of a
fragmentation of protocols here - if anything, we are seeing consolidation.

It seems weird to leave a BCP in a state that is not referring to the BP,
which is definitely TLS 1.3 - due to the many additions made. TLS 1.3 also
brings changes that are important for applications - 0-RTT, for example,
has no replay protection, and should only be used with idempotent requests.
While that is spelled out in the RFC, it's not where our audience would
look (or we would not need BCPs).

It's also worthwhile to deprecate < TLS 1.2, and discuss under which
circumstances TLS 1.3 is preferable to TLS 1.2 (that's more a business
question). Add to that a discussion of PSK. Plus a few new extensions, some
defined in separate RFCs (eSNI for example).

I am, of course, both an author on the old (and new) BCP, and also an
author of the study I cite - but I think there's enough to warrant the -bis.

Ralph

On Mon, 27 Apr 2020 at 19:03, tom petch <[email-masked]> wrote:

> It seems to me that RFC7525 is a good set of recommendations and little
> has changed, in practical terms, since it was produced, although
> cryptanalysts can find weaknesses therein
>
> ---
> The one change I am aware of is that the TLS WG has produced TLS 1.3 - I
> follow the TLS WG mailing list - but so what?  TLS 1.3 failed to meet one
> key requirement and I am unclear whether or not TLS 1.3 will gain
> widespread use in the Internet, with HTTP, SMTP and such like.  I see TLS
> 1.2 as being adequate for most purposes for some time to come so my concern
> is that rfc5575bis will simply be an endorsement of the work of the TLS WG
> - 1.3 is great, ditch everything else - leading to further fragmentation of
> the protocols.
>
> So, I am against adoption until it is clear that the I-D will endorse TLS
> 1.2 as adequate for most purposes.  After all, the TLS WG has yet to
> propose an I-D 'TLS 1.2 - Die, Die, Die'
>
> Tom Petch
>
>
> Cc: 'Yaron Sheffer' <[email-masked]>, <[email-masked]>,
> 'Ralph Holz' <[email-masked]>, 'Peter Saint-Andre' <
> [email-masked]>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Apr 2020 14:43:26 +0100

Hi,

> please indicate whether you are ready to review this draft if it becomes a

I support adoption of this work. I think both TLS 1.2 and TLS 1.3 
recommendations should be stated at this time, but this is ultimately 
for the WG to decide.

Best Regards,

Alexey

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 27 Apr 2020 09:32:19 -0600

> What is the point of rfc7525bis?  Why do we need it?

We explained much of the reasoning in the meeting last week:

https://datatracker.ietf.org/doc/slides-interim-2020-uta-01-sessa-tls-bcp-the-next-generation/

The topics we (the co-authors) plan to address in a bis document include:

Add TLS 1.3

Definitively deprecate earlier TLS versions (cf.
draft-ietf-tls-oldversions-deprecate)

Update treatment of fallback in view of SCSV (RFC 7507)

Indicate issues that are relevant only to TLS 1.2 vs. those that remain
in TLS 1.3

Specific TLS 1.3 gotcha: 0-RTT – what should we say here?

Mention Certificate Transparency

Mention Encrypted SNI

Recommend 1.3-only (no 1.2) for new “greenfield” protocols and embedding
in a different context (e.g., as in QUIC)

Provide guidance on handling of multiplexed protocols (RFC 8740)

Provide guidance on handling TLS 1.2 renegotiation / tickets to ensure
forward secrecy

DTLS versions (recommend DTLS 1.3 if draft-ietf-tls-dtls13 is approved
in time?)

Remove (or move to appendix) issues that are mostly fixed (e.g.,
compression, renegotiation)

Reword some of the background but leave the motivation (i.e. attacks)
for TLS 1.2

Additional topics were also raised during the meeting last week, such as
recommending larger key sizes.

Peter

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Apr 2020 18:42:49 +0100

Hi,

On 27/04/2020 12:25, Ralph Holz wrote:
> Hi,
>
> I am not sure which key requirement you are referring to, or why TLS 
> 1.3 should not see widespread use. In fact, TLS 1.3 is getting much 
> more traction already than TLS 1.2 ever had in a comparable amount of 
> time: https://arxiv.org/abs/1907.12762. I am not sure why you speak of 
> a fragmentation of protocols here - if anything, we are seeing 
> consolidation.

I don't have any number for SMTP or IMAP, but judging from my own 
experience: our implementations upgraded to OpenSSL 1.1.1 and we got TLS 
1.3 enabled for free. I suspect many other people in the same boat.

Best Regards,

Alexey

> It seems weird to leave a BCP in a state that is not referring to the 
> BP, which is definitely TLS 1.3 - due to the many additions made. TLS 
> 1.3 also brings changes that are important for applications - 0-RTT, 
> for example, has no replay protection, and should only be used with 
> idempotent requests. While that is spelled out in the RFC, it's not 
> where our audience would look (or we would not need BCPs).
>
> question). Add to that a discussion of PSK. Plus a few new extensions, 
> some defined in separate RFCs (eSNI for example).
>
> On Mon, 27 Apr 2020 at 19:03, tom petch <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     It seems to me that RFC7525 is a good set of recommendations and
>     little has changed, in practical terms, since it was produced,
>     although cryptanalysts can find weaknesses therein
>
>     ---
>     The one change I am aware of is that the TLS WG has produced TLS
>     1.3 - I follow the TLS WG mailing list - but so what?  TLS 1.3
>     failed to meet one key requirement and I am unclear whether or not
>     TLS 1.3 will gain widespread use in the Internet, with HTTP, SMTP
>     and such like.  I see TLS 1.2 as being adequate for most purposes
>     for some time to come so my concern is that rfc5575bis will simply
>     be an endorsement of the work of the TLS WG - 1.3 is great, ditch
>     everything else - leading to further fragmentation of the protocols.
>
>     So, I am against adoption until it is clear that the I-D will
>     endorse TLS 1..2 as adequate for most purposes.  After all, the
>     TLS WG has yet to propose an I-D 'TLS 1.2 - Die, Die, Die'
>
>     Tom Petch
>
>
>     From: Valery Smyslov <[email-masked] <mailto:[email-masked]>>
>     To: <[email-masked] <mailto:[email-masked]>>
>     Cc: 'Yaron Sheffer' <[email-masked]
>     <mailto:[email-masked]>>, <[email-masked]
>     <mailto:[email-masked]>>, 'Ralph Holz' <[email-masked]
>     <mailto:[email-masked]>>, 'Peter Saint-Andre'
>     <[email-masked] <mailto:[email-masked]>>
>     [email-masked] <mailto:[email-masked]>

---

From: "John Levine" <[email-masked]>
Date: 27 Apr 2020 18:42:20 -0000

In article <[email-masked]>,
>1.3 enabled for free. I suspect many other people in the same boat.

That's my impression, too.  The mail software I know uses a generic
SSL configuration that only says not to use pre-1.0 SSL, so if you
rebuild it with a new library, you get new stuff automatically.

-- 
Regards,

---

From: "tom petch" <[email-masked]>
Date: Tue, 28 Apr 2020 10:40:36 +0100

Inline <tp>

----- Original Message -----
From: Ralph Holz [email-masked]
Sent: 27/04/2020 12:25:43

I am not sure which key requirement you are referring to, or why TLS 1.3 should not see widespread use. In fact, TLS 1.3 is getting much more traction already than TLS 1.2 ever had in a comparable amount of time: https://arxiv.org/abs/1907.12762. I am not sure why you speak of a fragmentation of protocols here - if anything, we are seeing consolidation.

It seems weird to leave a BCP in a state that is not referring to the BP, which is definitely TLS 1.3 - due to the many additions made. TLS 1.3 also brings changes that are important for applications - 0-RTT, for example, has no replay protection, and should only be used with idempotent requests. While that is spelled out in the RFC, it's not where our audience would look (or we would not need BCPs).

It's also worthwhile to deprecate < TLS 1.2, and discuss under which circumstances TLS 1.3 is preferable to TLS 1.2 (that's more a business question). Add to that a discussion of PSK. Plus a few new extensions, some defined in separate RFCs (eSNI for example).

I am, of course, both an author on the old (and new) BCP, and also an author of the study I cite - but I think there's enough to warrant the -bis.

<tp>

I expect that you are familiar with 
draft-camwinget-tls-ns-impact
which looks at operational security with TLS 1.2 and identifies what is difficult or impossible to do with TLS 1.3. One might infer from this I-D that TLS 1.3 offers less security than TLS 1.2:-)
One requirement that was raised in the later stages of the work on TLS 1.3 related to audit, and was raised, I think, by representatives of the finance industry; the WG rejected the requirement.  Since then, I have seen suggestions on the TLS and other lists, and in the press, about the development of alternative protocols to meet the requirements that TLS 1.3 does not.  Hence my reference to fragmentation.  (I think the I-D covers that under offline analysis).  Although the I-D focusses on Operational Security, I think that much of what it says is applicable more generally.
The I-D that we are being asked to adopt lacks any detail about what the bis might change i.e. we are being asked to approve a blank slate which might end up saying how great TLS 1.3 is and how we should move to it as soon as possible; to which the I-D I mention offers an alternative viewpoint.

---

Tom Petch

Ralph

Tom Petch 

----- Original Message -----
From: Valery Smyslov <[email-masked]>
To: <[email-masked]>
Cc: 'Yaron Sheffer' <[email-masked]>, <[email-masked]>, 'Ralph Holz' <[email-masked]>, 'Peter Saint-Andre' <[email-masked]>
Sent: 26/04/2020 10:35:30
Subject: [Uta] Adoption call for draft-sheffer-uta-rfc7525bis-00

Hi,

Regards,
Leif & Valery.

---

From: Ralph Holz <[email-masked]>
Date: Tue, 28 Apr 2020 18:58:08 +1000

Hi,

> which looks at operational security with TLS 1.2 and identifies what is
> difficult or impossible to do with TLS 1.3. One might infer from this I-D
> that TLS 1.3 offers less security than TLS 1.2:-)

One requirement that was raised in the later stages of the work on TLS 1.3
> related to audit, and was raised, I think, by representatives of the
> finance industry; the WG rejected the requirement.  Since then, I have seen
> suggestions on the TLS and other

I am familiar with the discussion and the 3-4 issues stated in that I-D,
yes. An alternative to TLS 1.3 has indeed been proposed by the finance
industry that partially solves it:
https://www.etsi.org/deliver/etsi_ts/103500_103599/10352303/01.01.01_60/ts_10352303v010101p.pdf
<https://trello.com/c/HctoUsA5/11-etls-final-standard-https-wwwetsiorg-deliver-etsits-103500103599-10352303-01010160-ts10352303v010101ppdf>

> lists, and in the press, about the development of alternative protocols to
> meet the requirements that TLS 1.3 does not.  Hence my reference to
> fragmentation.  (I think the I-D covers that under offline analysis).
> Although the I-D focusses on Operational Security, I think that much of
> what it says is applicable more generally.
>

Any fragmentation remains speculative, so far. I would in fact not be
surprised if eTLS remains completely unused outside mobile phone banking
apps and inter-bank communication. I definitely do not expect it in user
traffic as the browser makers have been clear they won't support anything
that does static RSA and/or static DH.

If anything at all, though, that would be an argument in favour of a BCP -
note that this BCP is not TLS 1.3-specific. It still covers TLS 1.2. (And
even there, there is a need for crypto updates!)

> The I-D that we are being asked to adopt lacks any detail about what the
> bis might change i.e. we are being asked to approve a blank slate which
> might end up saying how great TLS 1.3 is and how we should move to it as
> soon as possible; to which the I-D I mention offers an alternative
> viewpoint.
>

I would not preempt discussions in such a way. Last time, they were
extremely productive, with folks making sure that all sorts of interop
issues were addressed.

Ralph

---

From: Sean Turner <[email-masked]>
Date: Wed, 29 Apr 2020 20:57:32 -0400

I support adoption and will review the draft.

> On Apr 27, 2020, at 11:32, Peter Saint-Andre <[email-masked]> wrote:
> 

At a minimum, I think we need this draft to address the point above.

spt

---

From: Keith Moore <[email-masked]>
Date: Thu, 30 Apr 2020 22:59:06 -0400

IMO RFC7525 and this new draft both suffer from dubious assumptions and 
make poor recommendations because of those assumptions.  In particular, 
there are many cases for which using an old version of TLS is suboptimal 
and it shouldn't be considered as secure, but it may still be better 
than deprecating old versions of TLS that might be the only ones 
supported by the peer.

People do not always have the luxury of upgrading their clients and 
servers to versions that support the recent TLS.    Some legacy hardware 
has firmware that cannot be upgraded because no upgrades are 
available.   Service providers do not always have the leverage to insist 
that their customers upgrade, or the luxury of abandoning customers. etc.

I therefore find it difficult to make good advice of the form "don't use 
TLS version x.y" that is appropriate across all applications and all 
usage scenarios.   Again, there's an important difference between "don't 
use TLS x.y" and "don't consider TLS x.y secure".

I also think it's odd that there are recommendations like this that say 
"don't support TLS x.y" but say nothing about not supporting cleartext 
for protocols that still have a cleartext mode.   Even SSL 1.0 is 
probably better than cleartext (at least from a security perspective, if 
not from a support burden perspective) as long as it's not trusted to be 
secure.

So in summary, either I don't support adoption of this draft, or I 
support adoption of this draft only to the extent that it can be 
significantly changed.

Keith