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

From: [email-masked]
Date: Fri, 01 May 2020 09:27:32 -0700 (PDT)

> 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.

Whether or not to ban SSL v2 and v3 is a tough call, but not for the reasons
given in RFC 7525. Yes, these are weak mechanisms, but in the absence of other
considerations weak is better than no security at all.

However, because of the way the negotations work supporting all of these stuff
simultaneously has proven to be difficult to get right. The fact that these old
versions can cause interop failures with later versions is arguably sufficient
cause for a MUST NOT. 

> 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.

Shorter version: Once again the IETF is letting the best be the enemy of the
good.

> 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".

Agreed.

> 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.

Agreed as well.

> 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.

AFAICT the draft hasn't been updated beyond what RFC 7525 says, so I'm
going to wait and see what those updates say before I decide if I can
support the change.

				Ned

---

From: Keith Moore <[email-masked]>
Date: Fri, 1 May 2020 16:10:43 -0400

> versions can cause interop failures with later versions is arguably 

If we can enumerate those specific cases, and explain why they're MUST 
NOTs, that seems like it would be a Good Thing.

> Shorter version: Once again the IETF is letting the best be the enemy 

I have often observed tendencies in thinking about security that seem to 
result in poor choices.

One is to assume that every application acts like the web, for example: 
A human interacting with a UI on the client side, who is in the loop, 
and who can react to security negotiation failures and make informed 
decisions.

Another is to treat "secure" as a binary value, without even considering 
that different users quite reasonably have different threat models.

(Anytime someone whom I don't have calibrated claims something is 
"secure", a red flag goes up.   At that point I generally ask them to 
tell me what threats they have identified and what they've done to 
address them.   Then I'll have a better idea of what they mean.  A few 
people can answer such questions, but most go into infinite page fault, 
or worse, just start trying to pile on more BS.   And then I know to 
treat the system as insecure.)

> going to wait and see what those updates say before I decide if I can

Yeah, I'm not entirely clear on the right way to go about this: is it to 
adopt the document with the understanding that significant changes are 
expected, or is it better to start with a new draft?

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 1 May 2020 15:02:38 -0600

On 4/30/20 8:59 PM, Keith Moore wrote:
> IMO RFC7525 

That ship sailed in 2015.

> and this new draft both suffer from dubious assumptions and

I don't think we ever said anything to the contrary. BCP does stand for
*best* current practice, after all. There are many reasons why a piece
of software or hardware can't do what's currently best, but that doesn't
make it evil or in "violation".

> that their customers upgrade, or the luxury of abandoning customers. etc.

For sure.

> usage scenarios. 

Does a BCP necessarily apply to all applications and all usage
scenarios? That strikes me as an impossible goal. Am I missing something?

> Again, there's an important difference between "don't

That's a subtlety which might be lost on the intended audience for this
document.

> for protocols that still have a cleartext mode. 

The title of RFC 7525 is "Recommendations for Secure Use of TLS and
DTLS" - not "Recommendations for Secure Use of Internet Protocols". This
document assumes that you're using TLS/DTLS and provides guidelines for
how to do so most (or more) securely while striking an appropriate
balance between aspiration and reality.

>  Even SSL 1.0 is

Yes, "as long as". There's the rub.

> support adoption of this draft only to the extent that it can be

Are you suggesting that it's better to stick with RFC 7525 and not
update it? Or even that the IETF should not have published a BCP on this
topic in the first place? You're welcome to submit an I-D proposing that
the IETF change RFC 7525 to Historic.

Peter

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 May 2020 14:35:21 -0700

On Mon, Apr 27, 2020 at 2:04 AM tom petch <[email-masked]> wrote:

> 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

What is that 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 don't know about SMTP, but TLS 1.3 has *already* achieved widespread use
on the Internet.

28% of sites support it [https://www.ssllabs.com/ssl-pulse/]
Upward of 40% of TLS connections on Firefox Beta are TLS 1.3 [
https://telemetry.mozilla.org/new-pipeline/dist.html#!cumulative=0&end_date=2020-04-22&include_spill=0&keys=__none__!__none__!__none__&max_channel_version=beta%252F76&measure=SSL_HANDSHAKE_VERSION&min_channel_version=beta%252F73&processType=*&product=Firefox&sanitize=1&sort_by_value=0&sort_keys=submissions&start_date=2020-04-07&table=0&trim=1&use_submission_date=1
]

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'
>

Nor do we expect to in the near future. There is a difference between (1)
you should use version X and (2) you should not support version Y < X. The
question is what is best practice?

-Ekr

>
> ----- 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,
>
> 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.
>
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 May 2020 14:45:35 -0700

On Tue, Apr 28, 2020 at 1:41 AM tom petch <[email-masked]> wrote:

> 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.

It's worth noting that to the extent that this is a requirement, it is
already violated by any installation which is compliant with RFC 7525. The
auditing techniques in question depend un using static RSA cipher suites,
but 7525 https://tools.ietf.org/rfcmarkup?doc=7525#section-4.1 *already*
prohibits those at the SHOULD level and requires forward that forward
secure cipher suites be implemented and preferred at the MUST level:

   o  Implementations SHOULD NOT negotiate cipher suites based on RSA
      key transport, a.k.a. "static RSA".

      Rationale: These cipher suites, which have assigned values
      starting with the string "TLS_RSA_WITH_*", have several drawbacks,
      especially the fact that they do not support forward secrecy.

   o  Implementations MUST support and prefer to negotiate cipher suites
      offering forward secrecy, such as those in the Ephemeral Diffie-
      Hellman and Elliptic Curve Ephemeral Diffie-Hellman ("DHE" and
      "ECDHE") families.

      Rationale: Forward secrecy (sometimes called "perfect forward
      secrecy") prevents the recovery of information that was encrypted
      with older session keys, thus limiting the amount of time during
      which attacks can be successful.  See Section 6.3 for a detailed
      discussion.

> 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.

Yes, I'm aware of at least one of those efforts (eTLS), however so far it
seems to have only minimal adoption. At least in the Web environment, I am
unaware of any browser or server which is interested in implementing it.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Fri, 1 May 2020 17:47:18 -0400

> That ship sailed in 2015.

IETF isn't bound by /stare decisis/.

> *best* current practice, after all.

If BCP really means Best /Current/ Practice, and we have a better 
understanding (perhaps informed by experience with existing documents) 
of what best practice is today, than we did in 2015, we should be able 
to say so.

> There are many reasons why a piece

I am interested in what text best informs protocol designers and 
implementors' decisions.   Particularly for a document with such broad 
scope, I suspect the words "evil" and "violation" have narrow applicability.

> scenarios? That strikes me as an impossible goal. Am I missing something?
What is our goal anyway?  Is it to provide good advice to protocol 
designers and implementors, or is it to expect them to read between the 
lines and "just know" when to bend or break those rules? Serious question.
> That's a subtlety which might be lost on the intended audience for this

Stated that way, I don't think it is a very subtle distinction.

More generally, what I've realized after several discussions about use 
of TLS in specific protocols is that different protocols necessarily use 
TLS in subtly different ways, with different assumptions about threat 
models.   Different protocols also have different backward compatibility 
issues, different means of error recovery and reporting.   For email, 
for example, I found that message relaying and UA-MSP interactions 
required very different advice even though both relaying and message 
submission use very similar protocols.   I tried to write text that 
covered both and it just didn't work.

Granted it's easy to drown people with details, but it's also easy to 
provide advice that is so generic that it's poor advice for very many 
use cases.

> balance between aspiration and reality.

Yes, but when the document says "don't use TLS x.y"  and that is applied 
to a protocol for which the likely fallback is cleartext, maybe it's not 
describing best current practice.

> Yes, "as long as". There's the rub.
Yes.   what's the best way to capture that so that implementors are well 
advised?
> update it?
No, I think that some change is needed.   The question in my mind is 
whether to start with this draft or with a clean slate.   I haven't 
formed an opinion about that yet.

Keith

---

From: Jeremy Harris <[email-masked]>
Date: Fri, 1 May 2020 23:20:24 +0100

> I don't know about SMTP, but TLS 1.3 has *already* achieved widespread use

At a small UK ESP, counting only connections that transfer messages:

Inbound:  85% of conns use any form of TLS
           4% of conns use TLS1.3

Outbound: 96% of conns use any form of TLS
          20% of conns use TLS1.3
-- 
Cheers,
  Jeremy

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 May 2020 15:48:39 -0700

> that their customers upgrade, or the luxury of abandoning customers. etc.

Somewhat tangentially from the topic at hand: if you are running a piece of
hardware that cannot upgrade its TLS stack at all, you quite likely have a
number of serious unpatched vulnerabilities, and should reconsider whether
it is safe to have that hardware attached to the Internet. Of course, you
might be running some ESR software where you can only take security
releases, in which case this does not apply.

> not from a support burden perspective) as long as it's not trusted to be

While perhaps technically true, for the reasons above I believe this to be
irrelevant: TLS 1.2 is nearly 12 years old. At this point, any
implementation which does not support it should be presumed to be insecure
regardless of our opinion on the specific protocols it supports.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 May 2020 15:51:35 -0700

On Fri, May 1, 2020 at 10:47 AM <[email-masked]> wrote:

> given in RFC 7525.

Fortunately this decision is not before us. The IETF banned SSLv2 back in
2011 and SSLv3 in 2016.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Fri, 1 May 2020 19:43:39 -0400

On 5/1/20 6:48 PM, Eric Rescorla wrote:

> On Thu, Apr 30, 2020 at 7:59 PM Keith Moore 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> Somewhat tangentially from the topic at hand: if you are running a 
> piece of hardware that cannot upgrade its TLS stack at all, you quite 
> likely have a number of serious unpatched vulnerabilities, and should 
> reconsider whether it is safe to have that hardware attached to the 
> Internet. Of course, you might be running some ESR software where you 
> can only take security releases, in which case this does not apply.

Quite often the issue is not the hardware, but the lack of support.  In 
my experience, many appliances with IP interfaces have no long-term 
support to fix security issues, because (for various reasons) there's no 
revenue stream to support it, and there was never any plan to provide 
long-term support.   But the problem is even deeper than that - 
customers expect to pay for the product up front and little if anything 
for ongoing support. Even if the vendor wanted to sell the long term 
support contract there's little chance that the customer would pay for 
it.  (I'm thinking industrial markets here, but consumer hardware often 
has similar issues.)

(And sometimes the compilers, linkers, etc. needed to build a new 
version of the device firmware are not easily found, and sometimes those 
tools don't run on newer operating systems, so upgrading these platforms 
can be much more complicated than just updating the source code and 
recompiling.)

> While perhaps technically true, for the reasons above I believe this 
> to be irrelevant: TLS 1.2 is nearly 12 years old. At this point, any 
> implementation which does not support it should be presumed to be 
> insecure regardless of our opinion on the specific protocols it supports.

I agree that such devices are likely insecure, but there are still 
devices in service that only speak TLS 1.0 or 1.1.   Are we going to 
insist that no standards-conforming peer programs should be able to 
communicate with them?   (I fully agree that new standards-conforming 
peer programs should not label such connections as "secure")

Keith

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 May 2020 16:49:01 -0700

On Fri, May 1, 2020 at 4:43 PM Keith Moore <[email-masked]>
wrote:

> Somewhat tangentially from the topic at hand: if you are running a piece
> of hardware that cannot upgrade its TLS stack at all, you quite likely have
> a number of serious unpatched vulnerabilities, and should reconsider
> whether it is safe to have that hardware attached to the Internet. Of
> course, you might be running some ESR software where you can only take
> security releases, in which case this does not apply.
>
> Quite often the issue is not the hardware, but the lack of support.  In my
> experience, many appliances with IP interfaces have no long-term support to
> fix security issues, because (for various reasons) there's no revenue
> stream to support it, and there was never any plan to provide long-term
> support.   But the problem is even deeper than that - customers expect to
> pay for the product up front and little if anything for ongoing support.
> Even if the vendor wanted to sell the long term support contract there's
> little chance that the customer would pay for it.  (I'm thinking industrial
> markets here, but consumer hardware often has similar issues.)
>
> (And sometimes the compilers, linkers, etc. needed to build a new version
> of the device firmware are not easily found, and sometimes those tools
> don't run on newer operating systems, so upgrading these platforms can be
> much more complicated than just updating the source code and recompiling.)
>
Sure. I'm certainly aware of these issues. I'm merely observing that those
people probably have bigger problems than modern systems not talking to
them.

> I agree that such devices are likely insecure, but there are still devices
> in service that only speak TLS 1.0 or 1.1.   Are we going to insist that no
> standards-conforming peer programs should be able to communicate with
> them?
>
That is precisely what we do for SSLv2 and SSLv3, and is in fact what the
TLS WG currently is proposing (
https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/) so
I would advise you to keep your eye out for the IETF LC on a mailing list
near you.

-Ekr

---

From: "John Levine" <[email-masked]>
Date: 1 May 2020 20:13:28 -0400

>> I don't know about SMTP, but TLS 1.3 has *already* achieved widespread use

On my not terribly large incoming mail server over the past month:

IPv6:

1227 TLS1.0
1919 TLS1.2
6249 TLS1.3

IPv4:

7838 TLS1.0
 109 TLS1.1
52621 TLS1.2
10539 TLS1.3

A lot of the v6 traffic is from Google.

Outbound is still 1.2 because I haven't gotten around to patching
the code to deal with changes from openssl 1.0.2 and 1.1.1.

-- 
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: Peter Gutmann <[email-masked]>
Date: Sun, 3 May 2020 05:26:24 +0000

Eric Rescorla <[email-masked]> writes:

>if you are running a piece of hardware that cannot upgrade its TLS stack at
>all, you quite likely have a number of serious unpatched vulnerabilities, and
>should reconsider whether it is safe to have that hardware attached to the
>Internet.

Embedded non-upgradeable SCADA devices have some of the most secure TLS
implementations I've ever seen:

  Some of the most difficult-to-attack TLS implementations that I've seen are
  in embedded devices that don't have the memory to run a full TLS
  implementation or to parse certificates.  They understand one key agreement
  algorithm (Diffie-Hellman), one encryption algorithm (AES), and one hash/MAC
  algorithm (SHA-2), and nothing else.  They don't know how to parse
  certificates, and laugh at TLS extensions.  This means that they support
  over _three_hundred_ fewer cipher suites, fifty fewer key exchange parameter
  types, sixty fewer extensions, and 100% less certificates and certificate
  extensions and algorithms than any other implementation, and yet they still
  interoperate perfectly with all of the major browsers, to which they look
  like a standard TLS implementation.  As a convenient side-effect of this,
  whenever any new attack on TLS comes out it bounces off these
  implementations because there's nothing there to attack.  You can't exploit
  all of the infinite quirks in the protocol and its dozens of extensions, all
  of the corner cases, all of the gaps and holes and ambiguities that open up
  when different protocol features interact, because they're not present in
  the implementation.  Even though these TLS implementations are typically
  created by embedded systems developers with little to no security
  experience, they're often more secure than ones written by security experts
  with years or decades of experience.

Peter.

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 May 2020 12:14:45 -0700

On Sat, May 2, 2020 at 10:26 PM Peter Gutmann <[email-masked]>
wrote:

>   implementation or to parse certificates.
>

I don't have much experience with SCADA TLS stacks, so I can't speak to
this, but I wasn't thinking primarily of the TLS stack itself but just of
the overall software on the device. In general, most software has some
defects and some of them will be security relevant; If you are unable to
upgrade the software on your devices, then if such vulnerabilities are
discovered you are obviously in a bad position.

-Ekr

---

From: Keith Moore <[email-masked]>
Date: Sun, 3 May 2020 17:18:59 -0400

On 5/3/20 3:14 PM, Eric Rescorla wrote:

> I don't have much experience with SCADA TLS stacks, so I can't speak 
> to this, but I wasn't thinking primarily of the TLS stack itself but 
> just of the overall software on the device. In general, most software 
> has some defects and some of them will be security relevant; If you 
> are unable to upgrade the software on your devices, then if such 
> vulnerabilities are discovered you are obviously in a bad position.

It can be expensive to upgrade devices in some industrial 
applications.   As mentioned earlier, upgrades may not even be 
available.   Upgrades are sometimes also seen as disruptive to 
production, and therefore extremely risky, because they may introduce 
new bugs or change APIs.    The risk of loss of production for any 
significant period of time can seem far greater than the risk of a 
security breach, though of course both risks are real.    Upgrades over 
the net are generally not feasible (and this is seen as a Good Thing), 
because the production network is generally disconnected from any 
external network most if not all of the time.   If there is a supported 
means to upgrade the firmware in the field, it may require physical 
access to the hardware.   (Of course there are still security threats: 
from insiders who have access to the network and/or the hardware, from 
the occasional laptop that migrates between the production network and 
other networks, from media that migrates, etc.)   The hardware may well 
be replaced before its firmware is upgraded -- but new hardware may 
still run old firmware.

So a vendor of hardware that's intended for such environments may not be 
able to rely on firmware upgrades to fix bugs.   For the smart ones 
(they're not all smart, of course) this translates into a greater 
emphasis on minimizing complexity, product stability, and getting things 
right the first time.

Keith

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 4 May 2020 01:27:35 +0000

Keith Moore <[email-masked]> writes:

>It can be expensive to upgrade devices in some industrial applications.

For the specific TLS implementation I was referring to in that post, upgrades
have to be scheduled years in advance for each site, and for the next upgrade
round, in 2030, will probably mean replacing the hardware to allow the cost of
a site visit to be amortised.  You do it once and you do it right.

For other implementations it's a bit less problematic, but upgrades still
require a site visit, shutting down major production processes, and spending
possibly several hours updating and re-commissioning each piece of equipment.

>For the smart ones (they're not all smart, of course) this translates into a
>greater emphasis on minimizing complexity, product stability, and getting
>things right the first time.

That's the case in many of the systems I've reviewed, they're designed to have
a downtime of never so you need to do it right.  This is also why they ignore
certs, or at least memcpy() a fixed blob into the right place in the
handshake, they're a means of bundling up a key, not a built-in DoS on the
device.

Peter.

---

From: "tom petch" <[email-masked]>
Date: Mon, 4 May 2020 11:59:14 +0100

<inline>
----- Original Message -----
From: Eric Rescorla [email-masked]
Sent: 01/05/2020 22:45:35

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. 

It's worth noting that to the extent that this is a requirement, it is already violated by any installation which is compliant with RFC 7525. The auditing techniques in question depend un using static RSA cipher suites, but 7525 https://tools.ietf.org/rfcmarkup?doc=7525#section-4.1 *already* prohibits those at the SHOULD level and requires forward that forward secure cipher suites be implemented and preferred at the MUST level:

<tp>
Yes and it is a SHOULD not a MUST.  If audit cannot take place, then it is easier for bad actors to use the technology be they pursuant of fraud, terrorism or whatever.  I think that concerns about the bad behaviour that the Internet facilitates is growing and we may get pushback on the IETF at large.  I see TLS 1.3 as emphasising privacy at a time when the world at large is waking up to the abuses that that enables.

As others have said, beyond adding a 'bis' this I-D seems devoid of anything new and so, to me, seems too risky to adopt.  It is a blank slate.

---

Tom Petch

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. 

Yes, I'm aware of at least one of those efforts (eTLS), however so far it seems to have only minimal adoption. At least in the Web environment, I am unaware of any browser or server which is interested in implementing it.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 May 2020 06:30:53 -0700

> already violated by any installation which is compliant with RFC
> 7525. The auditing techniques in question depend un using static RSA
> cipher suites, but 7525
> https://tools.ietf.org/rfcmarkup?doc=7525#section-4.1 *already*
> Yes and it is a SHOULD not a MUST.

Well, there is actually both a SHOULD and a MUST. Therefore any two
7525-compliant endpoints will negotiate a PFS algorithm (because of
the MUST). Any 7525-compliant endpoint SHOULD NOT negotiate a non-PFS
algorithm even with a (non-7525-compliant) peer which only supports
that, though, as you say, that's only at SHOULD.

As far as I can tell, any proposed TLS 1.3 requirement would have
no impact on this (at least for existing protocols w/o TLS bindings)
in that it would most likely require TLS 1.3 support/preference as
MUST, but as you could still do TLS 1.2, you would have the same
outcome matrix wrt PFS as you have now,

Now, it's possible that a 7525-bis could forbid static RSA at the MUST
level (and I think there's a reasonable argument for this) but that's
a distinct question from updating it to include TLS 1.3.

> I see TLS 1.3 as emphasising privacy
> at a time when the world at large is waking up to the abuses that that
> enables.

I don't think it's useful to engage on the broader political question
-- although I don't really agree with this -- but this feature is not
primarily about privacy, but rather about security. There is wide
consensus that modern protocols should have PFS and there was even
back when 7525 was written (hence the text I quoted above). TLS 1.3 is
just following the consensus in that respect.

> As others have said, beyond adding a 'bis' this I-D seems devoid of
> anything new and so, to me, seems too risky to adopt.  It is a blank
> slate.

This seems like a misguided process objection. It's not uncommon in WGs
to first agree to do a bis with a list of proposed changes, and then
start with an unchanged version of the original document, adding one
change at a time. The WG's agreement to adopt the document doesn't
imply consensus for any particular change or the final document, and
there will be plenty of opportunity to object to any specific text.

-Ekr

---

From: "Valery Smyslov" <[email-masked]>
Date: Sat, 9 May 2020 18:50:26 +0300

Hi,

the chairs encourage WG members to more actively participate in the call.
At the meeting a lot of participants expressed a favor of adoption,
we ask these participants to reconfirm their position on the list (if they
didn't do it yet).

Regards,
Leif & Valery.

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 9 May 2020 09:27:29 -0700

I am in favor of adoption

---

From: "John Levine" <[email-masked]>
Date: 9 May 2020 15:17:46 -0400

>we ask these participants to reconfirm their position on the list (if they

Yes, adopt it so we can update 7525 and fix its mistakes.

---

From: Jim Fenton <[email-masked]>
Date: Sun, 10 May 2020 20:24:00 -0700

I support adoption; it's time to revisit this BCP as circumstances have
changed.

-Jim

---

From: Keith Moore <[email-masked]>
Date: Tue, 12 May 2020 12:45:45 -0400

> we ask these participants to reconfirm their position on the list (if they

Since we wouldn't want the chairs to tip the scales, I hope those who 
expressed disfavor of adoption will reconfirm their positions also.

Keith

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 12 May 2020 10:48:46 -0600

> expressed disfavor of adoption will reconfirm their positions also.

IIRC, no one expressed disfavor during the meeting. Naturally, anyone
who has concerns should express them on the list.

Peter

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 14 May 2020 11:18:16 +0300

Hi,

the call for adoption is over. Thanks to all who participated in it.
We received some replies unconditionally supported the adoption
and a few that expressed concerns about the current draft content.
We think that these concerns are not blockers for adoption, since
folks willing to change the draft to reflect their needs will have
more opportunity to do it if the draft is a WG document.

So, we think there is rough consensus in the WG for adoption this draft.
The draft is adopted. Authors, please resubmit it as WG document.

Regards,
Leif & Valery.

> The general feeling in the room was in favor of the adoption, however the
> authors were asked to rename it to *-rfc7525-bis.
> 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.
before
> this date.
support
> this adoption, please indicate whether you are ready to review this draft
if it
> becomes a WG document.