Subject: [Uta] comments: draft-ietf-uta-tls-bcp-04

From: Sean Turner <[email-masked]>
Date: Thu, 2 Oct 2014 17:20:56 -0400

Is this what you were looking for:

Hi authors,

I’ve recently read the -04 version of the draft and have a couple of couple and some
questions comments.  I guess I’d categorize the comments as editorial but this draft is
about explaining things to non-sec folks I hope you’ll entertain them:

0) s1, para1:

- If I weren’t a security guy I might ask what on earth are AES-CBC and RC4 (beyond
some well-intentioned IESGer asking you to expand the acronyms).
- The 2nd sentence talks about its most common suites/modes and then it’s repeated
in the 3rd sentence - there’s probably no need to repeat in the context of TLS.
- "which together comprise most current usage” I think is saying are widely deployed.
- I’d also just use see [] instead of the extra sentence.
- Maybe just put the bridge between the 1st paragraph and the rest of the intro in
para 1.

how about:

  Transport Layer Security (TLS) and Datagram Transport Security Layer
  (DTLS) are widely used to protect data exchanged over application
  protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP.  Over the
  last few years, several serious attacks on TLS have emerged,
  including attacks on its most commonly used cipher suites and modes
  of operation, e.g., AES-CBC and RC4 have been attacked (see
  [I-D.ietf-uta-tls-attacks]).  To address these attacks, this document provides
  guidance to those who implement and deploy TLS and DTLS.

1) s1, para 2-4 and s2:

Actually now that I read farther, it seems like this draft ought to tell you who it’s for,
what it’s for, and how it’s going to do it.  It also seems like the intro and audience
section ought to be combined to cut down on some of the duplication. Might I suggest:

adding the following the end of the 1st para:

  Unless otherwise noted, these recommendations apply to both TLS and DTLS
  implementations prior to version 1.3; TLS 1.3, when standardized and deployed
  in the field, should resolve the current vulnerabilities while providing
  significantly better functionality.

and then follow on with:

  The deployment recommendations address the operators of application
  layer services that are most commonly used on the Internet, including
  but not limited to:

  o  Operators of WWW servers that wish to protect HTTP with TLS.

[spt: The bullets ought to be parallel.]

  o  Operators of email servers who wish to protect the application-
      layer protocols with TLS (e.g., IMAP, POP3, or SMTP between client
      and server).

  o  Operators of instant-messaging services who wish to protect their
      application-layer protocols with TLS (e.g.  XMPP or IRC between
      client and server).

[spt: IRCS is listed here and SIP is listed in para1 - intentional?]

  Stricter recommendations can be specified by individual protocols and
  when specified deployers adhere to them.

[spt: I don’t think you need the MUST here.  Deployers will just do implement the stricter recommendations.]

  The implementation recommendations address the options that TLS and
  DTLS implementations make or not make available to deployers.

  The recommendations address the utilization of all of the security services
  provided by TLS, which include the following three services:

   o Confidentiality: all (payload) communication is encrypted with the
      goal that no party be able to decrypt it except the
      intended peer.

   o Data integrity: any changes made to the communication are
      detectable by the peer.

  o  (optionally) Authentication: the peer is the intended entity to which
      communication is desired.  TLS support authentication of one or
      both peers (i.e., server authentication or server and client
      authentication).

  This document does not address the rare deployment scenarios where
  one of these three properties is not desired.  In fact, it is so rare that deployers
  need to verify carefully consider why they need to deviate from the
  recommendations provided in this document.  An example of an audience
  not needing confidentiality is the following: a monitored network where the
  authorities in charge of that traffic domain require full access to unencrypted
  (plaintext) traffic, and where users collaborate and send their traffic in the
  clear.

  The recommendations herein take into consideration the security of
  various mechanisms, their technical maturity and interoperability,
  and their prevalence in implementations at the time of writing.
  For example, this document calls for the deployment of algorithms
  that are widely implemented but not yet widely deployed.

  Community knowledge about the strength of various algorithms and
  feasible attacks can change quickly, and experience shows that a
  security BCP is a point-in-time statement.  Readers are advised to
  seek out any errata or updates that apply to this document.

and then just renumber the remaining sections.

2) s4.*: seems like we should be consistent about the use of requirement followed by rationale.  Not all of the sections follow the same script.

3) s4.1:

a) It seems like the base rationale is support AEAD algorithms so that leads us to TLS 1.2. It seems like we ought to just say that as opposed to leaving it to a later section.

b) r/SSLv2 is considered today as insecure [RFC6176].
     /Today, SSLv2 is considered insecure [RFC6176].

c) ssl3: The rationale for SSLv3 not supporting some extensions begs the question - which ones.

d) You could also tweak the intro a little:

  It is important both to stop using old, less secure versions of SSL/
  TLS and to start using modern, more secure versions; therefore, the following
  are the recommendations concerning TLS/SSL protocol versions:

4) s4.2: This section kind of comes out of nowhere.  Maybe make 4.1 4.1.1. for SSL/TLS Protocol Versions and then make s4.1.2. DTLS Protocol Versions and then you can use the same layout:

  The following are the recommendations with respect to DTLS:

  o  Implementations MAY negotiate DTLS version 1.1 [RFC4347].
  o  Implementations MUST negotiate DTLS version 1.1 [RFC6347].

  Rationale: DTLS is an adaptation of TLS for UDP datagrams that was
  introduced when TLS 1.1 was published.  Version 1.0 correlates to TLS 1.1
  and Version 1.2 correlates to TLS 1.2.  There is no DTLS 1.1 or “DSSL"
  equivalent.

  NOTE: DTLS and TLS are nearly identical.  The most notable exception is that
  RC4, which is a steam-based bulk encryption algorithm, cannot be supported by
  DTLS.

5) s4.3: Two things:

a) Is the section title right - if it’s SSL or TLS fallback maybe we can just call it “Fallback”.

b) I think we should stick to the requirement followed by rationale where we can:

  Clients that “fallback" to lower versions of the protocol after the server
  rejects higher versions of the protocol to MUST NOT fall back to SSLv3.

  Rationale: Some client implementations revert to lower versions of TLS or even
  to SSLv3 if the server rejected higher versions of the protocol.
  This fall back can be forced by a man in the middle (MITM) attacker.
  TLS 1.0 and SSLv3 are significantly less secure than TLS
  1.2, the version recommended by this document.  While TLS 1.0-only
  servers are still quite common, IP scans show that SSLv3-only servers
  amount to only about 3% of the current Web server population.

6) s4.4: I read the attack in uta-attacks draft and it’s a little more complicated than expressed in the 1st sentence.  I would do the following:

  To prevent SSL stripping:

       and have the bullets

follow that with the Rationale: paragraph.  It never really explains how it protects - i.e., everything is integrity protected so you’d notice if something changed.

7) s4.5: Again requirement followed by rationale:

 Implementations and deployments SHOULD disable TLS-level compression
 ([RFC5246], Sec. 6.2.2).

 Recommendation: TLS-level compression has been subject to security attacks …

8) s4.6-8: probably sounding like a broken record: requirement followed by rationale.

9) s5: I think some of the intro para is a bit strong. Some suites are weak, some are just fine they just don’t give you all the services we’re targeting:

   TLS and its implementations provide considerable flexibility in the
   selection of cipher suites.  Unfortunately, some available cipher
   suites are insecure, some do not provide the targeted security
   services, and some no longer provide enough security.  Incorrectly
   configuring a server leads to no or reduced security.  This section
   includes recommendations on the selection and negotiation of
   cipher suites.
 
10) s5.1: I think we really ought to drive it home that stuff needs to be updated, so how about we add a bit more to the intro:

  Cryptographic algorithms weaken overtime as cryptanalysis improves.  In other
  words, as time progresses, algorithms that were once considered strong but are
  now weak need to be phased out over time and replaced with more secure
  cipher suites to ensure the .  SSL/TLS has been in existence for almost 20 years
  at this point and this section provides some much needed recommendations
  concerning cipher suite section:

11) s5.1 null cipher suites: I assume you’re referring to the NULL encryption cipher suites and not the TLS_NULL_WITH_NULL_NULL.  It’s probably more precise to say:

  Implementations MUST NOT negotiate the cipher suites with NULL encryption.

and maybe we could make the rationale slight more scary:

  Rationale: The NULL cipher suites does not encrypt traffic.  It provides
  no confidentiality services. Any entity in the network with access to the
  connection can view the contents being exchanged by the client and
  server unaided.

12) s5.1 RC4 might be worth noting RC4 isn’t available to DTLS - maybe not not sure.

13) s5.1 40-bit and 112 bits: I think you can lump these two together and provide one rationale based on RFC 3766, which provides a rule of thumb for bits of security:

 Implementations MUST NOT negotiate cipher suites
 offering less than 112 bits of security including the so-called
 "export-level” encryption that provide 40 or 56 bits of security.

[spt: I let you fill in the # below.]

  Rationale: Based on [RFC3766], X bits of security is needed.  40-bit
  and 56-bit security are considered insecure today.  TLS 1.1/2 never
  negotiate 40-bit or 56-bit export ciphers.

14) s5.1 128-bit recommendation: I’d move the 2nd and 3rd sentence to the rationale.

15) s5.1 128-bit rationale: I have to admit I’m a little confused by the first sentence in the rationale.  Which cipher suites the ones between 112-128 or 128?  How about:

  Rationale: Cipher suites that offer between 112-bits and 128-bits of security
  are not considered weak at this time, it is expected that their useful lifespan
  is short enough to justify supporting stronger cipher suites at this time.
  128-bit ciphers are expected to remain secure for at least several years,
  and 256-bit ciphers "until the next fundamental technology breakthrough".
  Note that
  some legacy cipher suites (e.g. 168-bit 3DES) have an effective
  key length which is smaller than their nominal key length (112
  bits in the case of 3DES).  Such cipher suites should be evaluated
   according to their effective key length.

16) s5.2: I’d delete the paragraph after the bullets - it’s about negotiation and it’s repeated in s5.3.

17) s5.2: Is it worth noting somewhere in s5.2 that this is only really going to work if the deployer configures their client/server to order these suites somehow?

18) s5.3: If this section is targeted just at stack implementers maybe it should say so.

19) s5.4: There should be an introductory paragraph to note that there are two kinds of public keys used: one for key agreement and one for authentication.  With the definition of bare keys should the authentication requirement be generalized to include 2048-bit keys?

20) s5.5: It’s unclear to me what “the same cipher suite” is in bullet 3.  It would be clearer to just repeat it.

21) s5.6: Start with the recommendation end with the Rationale:.

22) s7.2: r/Sec. Section 5.2/Section 5.2

spt

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 03 Oct 2014 10:45:05 +0300

Hi Sean,

Thanks for the detailed review. This'll all go into the next revision of 
the draft.

Best,
	Yaron

On 10/03/2014 12:20 AM, Sean Turner wrote:
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 3 Oct 2014 13:42:57 +0000

>       layer protocols with TLS (e.g., IMAP, POP3, or SMTP between client

When you say "between client and server" do you mean "MUA to MTA"?
Because "MTA to MTA" SMTP is also between "client and server", and
so the latter phrase is potentially confusing if meant more narrowly.

The reason for the question is that TLS authentication is generally
not applicable with MTA to MTA SMTP (DANE adoption is likely around
~1000 domains at present).

>       application-layer protocols with TLS (e.g.  XMPP or IRC between

XMPP is also generally opportunistic TLS (modulo some few DANE
early adopters), unless again "client to server" means "user-agent
to server".

>   (plaintext) traffic, and where users collaborate and send their traffic in the

However optional authentication is far from rare.  Opportunistic
TLS is quite common outside of HTTP.

-- 
	Viktor.

---

From: Yaron Sheffer <[email-masked]>
Date: Sun, 05 Oct 2014 22:26:15 +0300

Viktor is raising an important issue that I'd like to open on the list: 
the BCP draft implicitly applies to opportunistic uses of TLS (meaning, 
the client connects to the server without validating the server 
certificate). In general, such uses are definitely in scope of the 
working group.

The latest version of the draft added:

This document assumes that data integrity protection is always one of 
the goals of a deployment.  In cases when integrity is not required, it 
does not make sense to employ TLS in the first place.  There are attacks 
against confidentiality-only protection that utilize the lack of 
integrity to also break confidentiality (see e.g.  [DegabrieleP07] in 
the context of IPsec).  Thus, even when using opportunistic encryption, 
it is essential to provide cryptographic data integrity protection.

However, most of the "interesting" attacks against SSLv3-TLSv1.1 are 
active MITM attacks. For such an attacker, it is trivial to hijack an 
opportunistic connection by presenting a forged certificate. IOW, you 
might as well stay with TLS 1.0 (though RC4 is still not a good idea).

So we could:

1. Say explicitly that opportunistic TLS is out of scope.
2. Or say explicitly that it is in scope, and with the same requirements 
as "regular" TLS.
3. Or come up with a different set of requirements for opportunistic TLS.

I tend towards #2, because:

- With channel bindings, you can convert an unauthenticated TLS channel 
into an authenticated one, after the fact.
- Also, because we do not want to fragment the TLS ecosystem.
- Lastly, an opportunistic deployment can eventually become 
authenticated TLS, when DANE is introduced.

Other opinions?

PS: let's try to avoid the terminology discussion on what is 
"opportunistic", please.

Thanks,
	Yaron

---

From: Sean Turner <[email-masked]>
Date: Sun, 5 Oct 2014 22:08:55 -0400

> ~1000 domains at present).

Actually, I copied that from the version -04 and didn’t think about it, but I agree it could be confusing.  The previous version didn’t include the "between client and server” text but I’d guess they meant between MUA to MTA.

> to server”.

See above.

> TLS is quite common outside of HTTP.

Ack - as the scope gets nailed down I’m hoping this will all get settled.

spt

---

From: Watson Ladd <[email-masked]>
Date: Sun, 5 Oct 2014 19:22:46 -0700

> Ack - as the scope gets nailed down I’m hoping this will all get settled.

Huh? Even if you don't want authentication, you should still pay
attention to integrity and confidentiality issues. Currently the draft
isn't organized to separate recommendations that way: maybe it should.

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 6 Oct 2014 11:29:12 +0100

> On 5 Oct 2014, at 20:26, Yaron Sheffer <[email-masked]> wrote:
> 
> So we could:
> 
> 2. Or say explicitly that it is in scope, and with the same requirements as "regular" TLS.
+1. Simplicity is our friend here.

> - With channel bindings, you can convert an unauthenticated TLS channel into an authenticated one, after the fact.
> - Lastly, an opportunistic deployment can eventually become authenticated TLS, when DANE is introduced.

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Mon, 6 Oct 2014 19:16:36 +0000

> +1. Simplicity is our friend here.
As an individual: +1 for the same reason. If needed, the BCP can be revised in the future.
As a chair: when you mention the "opportunistic encryption/security" in the document for the first time, please, add the reference to the relevant draft https://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/.

Thanks,
Orit.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 6 Oct 2014 21:01:59 +0000

On Sun, Oct 05, 2014 at 10:26:15PM +0300, Yaron Sheffer wrote:

> Viktor is raising an important issue that I'd like to open on the list: the
> BCP draft implicitly applies to opportunistic uses of TLS (meaning, the
> client connects to the server without validating the server certificate). In
> general, such uses are definitely in scope of the working group.

In particular, for the applications that employ opportunistic TLS,
often the client can't meaningfully authenticate the server, even
if it wanted to.  In many cases server certificates are self-signed,
clients don't have a "standard" list of CAs to trust, or the
reference identifier for the server is obtained insecurely via SRV
or MX lookups.

It is not that clients are merely "lazy", rather server authentication
is not an option.  This is of course the turf the opportunistic
security draft, and we should not debate its content here.  It
suffices to recognize that the opportunistic use case is typically
(and well into the future) unauthenticated.

> This document assumes that data integrity protection is always one of the
> goals of a deployment.  In cases when integrity is not required, it does not
> make sense to employ TLS in the first place.

Well here I must strongly disagree, because TLS for confidentiality
against passive attacks is one of the primary reasons for opportunistic
security.

Sure, I implemented DANE for SMTP because I recognize that protection
against active attacks is better.  And much of the controversy
around the opportunistic security draft is around my proposal to
opportunistically enable authentication.

Still for the next decade or so, most uses of opportunistic TLS
will protect only against passive attacks, and will not provide
integriry protection in the face of active attacks.

> There are attacks against
> confidentiality-only protection that utilize the lack of integrity to also
> break confidentiality (see e.g.  [DegabrieleP07] in the context of IPsec).
> Thus, even when using opportunistic encryption, it is essential to provide
> cryptographic data integrity protection.

These are out of scope.  The threat model for unauthenticated
opportunistic TLS is a passive adversary.

> However, most of the "interesting" attacks against SSLv3-TLSv1.1 are active
> MITM attacks. For such an attacker, it is trivial to hijack an opportunistic
> connection by presenting a forged certificate. IOW, you might as well stay
> with TLS 1.0 (though RC4 is still not a good idea).

Indeed for opportunistic TLS many of the best practices of the
draft which are protecting against active attacks are not applicable.

> 1. Say explicitly that opportunistic TLS is out of scope.

Or explicitly say which best practices are in scope for unauthenticated
opportunistic use cases.

> 2. Or say explicitly that it is in scope, and with the same requirements as

This is a non-starter.  You cannot impose an authentication
requirement on opportunistic TLS, that makes it unusable.

> 3. Or come up with a different set of requirements for opportunistic TLS.

My response to 1. is effectively 3.

> an authenticated one, after the fact.

This misses the point.  The clients that are doing unauthenticate
TLS, are not necessarily doing anonymous ciphersuites and the like,
nor do they have alternative ways to authenticate servers.  Rather,
they simply cannot authenticate the server by any means.  They are
vulnerable to active attacks, and in fact many of them send in the
clear to some or all servers.

> - Also, because we do not want to fragment the TLS ecosystem.

It is already "fragemented".  There is no "TLS ecosystem".  The
MTA to MTA TLS landscape is nothing like the one for HTTPS.

> TLS, when DANE is introduced.

This is at least a decade away.  My list of DANE enabled domains
for SMTP consists of ~230 domains, almost all of them in Germany.
There may in fact be 500.  None of the major players are about
to deploy DNSSEC any time soon.

> Other opinions?

There is little choice here, opinions won't change the facts on
the ground.  The use cases are not compatible, and either the
document excludes opportunistic TLS or a different set of best
practices is described for this case.

> PS: let's try to avoid the terminology discussion on what is

+1

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 07 Oct 2014 23:09:47 +0200

Yaron Sheffer wrote:
> [...]

+1

There isn't much choice anyhow. So going for 'opportunistic' TLS rather
than only allowing strict TLS (which I'd like to see deployed - but is
far from doable right now) is the only real option this WG can go for.
It's also the only option most other groups working on TLS or related
standards will accept right now, I take it.

Aaron

---

From: t.p. <[email-masked]>
Date: Wed, 8 Oct 2014 09:45:20 +0100

----- Original Message -----
From: "Orit Levin (LCA)" <[email-masked]>
To: "Alexey Melnikov" <[email-masked]>; "Yaron Sheffer"
<[email-masked]>
Cc: <[email-masked]>
Sent: Monday, October 06, 2014 8:16 PM
> > > 2. Or say explicitly that it is in scope, and with the same
requirements as
> > "regular" TLS.
> As a chair: when you mention the "opportunistic encryption/security"
in the document for the first time, please, add the reference to the
relevant draft
https://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/.

Well, no.

Opportunistic xxxxxx got a fair bit of discussion on the main IETF list
and what we have ended up with is opportunistic security.  Opportunistic
encryption has yet to be defined; it makes no appearance in the I-D you
cite.

Opportunistic TLS is defined in
http://www.ietf.org/id/draft-ietf-dane-smtp-with-dane-12.txt
but  as a deprecated concept, to be replaced by the term
'opportunistic DANE TLS'
which is regarded as a superior approach.

It is tricky trying to coordinate terminology across different WGs:-(

Tom Petch

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 8 Oct 2014 16:41:18 +0000

> It is tricky trying to coordinate terminology across different WGs:-(

Tricky, but necessary. ;-)

When applicable, all guidelines documented in the BCP are true for both "authenticated through TLS" and "opportunistic use of TLS " approaches. (The introduction of the lengthy "Applicability Statement" doesn't help to clarify that and might confuse the readers.) Therefore, let's keep a very short "applicability paragraph" capturing this fact in the Introduction and leave all further "TLS with OE/OS" discussion outside of this document.

We have the "Opportunistic TLS" topic as one of the UTA potential deliverables, so we welcome the interested parties to write a separate draft on the subject taking into consideration the progress that has been made so far in the Security Area (i.e., https://datatracker.ietf.org/doc/draft-dukhovni-opportunistic-security/)

Thanks,
Orit.

---

From: Ralph Holz <[email-masked]>
Date: Wed, 08 Oct 2014 23:15:36 +0200

Hi,

> When applicable, all guidelines documented in the BCP are true for
> both "authenticated through TLS" and "opportunistic use of TLS "
> approaches. (The introduction of the lengthy "Applicability
> Statement" doesn't help to clarify that and might confuse the
> readers.) Therefore, let's keep a very short "applicability
> paragraph" capturing this fact in the Introduction and leave all
> further "TLS with OE/OS" discussion outside of this document.

The problem is caused by two facts coming together.

1) The first is that this WG seems (AFAICT) always assumed an active
attacker, and in that case all OE/OS is moot. In fact, the BCP lacks a
threat model. BTW [0]. Correct me if I am wrong, but go ahead and state
the threat model you had in mind to see if we were indeed always in
agreement on this.

2) The second is that most of the application-layer protocols that we
thought of in UTA (so far) assumed an authenticated server in a
UA-to-server scenario. Thus, it makes sense to discuss + address
authentication, both as a security goal as well as when referencing RFC
5280 for checking host names. Etc. So authentication became an implicit
assumption in the introduction and applicability statement.

I added the wording in question to the text, but notified Yaron and
Peter at the same time that I was unsure about it as it would make it
difficult to keep OE/OS in scope. Quite expectedly, people agree.

Now we need to find a way to express:

* In general, authentication is desired: HTTP, SMTP, and IMAP in
UA-to-server. Also BTW [1].

* In some settings, e.g. MTA-to-MTA or XMPP server-to-server, OE/OS is
common. Authentication is not required there, and unlikely to come (say
some).

In general, I tend to go with what Yaron proposed: keep OE/OS in scope.
Deal with it in two ways:

* By making it clear where authentication is commonly desired, and where
it sometimes is not: i.e. examples.

* Make the consequences clear to the reader: where authentication is
omitted, the other security guarantees only hold against passive
attackers. Personally, I would even encourage using authentication in
this BCP, despite knowing of the above use cases - this is a document
for the 95%, after all. And a client can always choose to ignore a cert
sent to him.

Would that be a way to go? It would require some reshuffling of the
text, but I think that can be done.

Ralph

[0] And actually, without that one, the recommendations do not make much
sense.

[1] I know the wording is difficult. I don't even want to enter the
realm of MUA and MTA! If we are to assume someone does know what AES
stands for, are we sure we want to throw MUA at them? Believe me, none
of my graduates today still know that term. They encounter it in class
once, and that's it. BTW [2].

[2] Please let's not even talk DANE-TLSA or whatever the record of the
day is called.

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18010
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Brian Smith <[email-masked]>
Date: Wed, 8 Oct 2014 14:34:22 -0700

> 3. Or come up with a different set of requirements for opportunistic TLS.

I think you can just avoid mentioning opportunistic TLS in the BCP at all.

How could unauthenticated TLS be in scope for a TLS BCP when it has
not even been deployed yet? It isn't a current practice.

> an authenticated one, after the fact.

There's no commonly-accepted way of doing that. Regardless, it isn't a
common current practice.

> - Also, because we do not want to fragment the TLS ecosystem.

That's exactly what unauthenticated/opportunistic TLS is doing, and
that is in fact one of the biggest arguments against unauthenticated
TLS.

> TLS, when DANE is introduced.

DANE-authenticated TLS would be authenticated TLS, not
unauthenticated/opportunistic TLS. Regardless, it is also out of scope
for this BCP because it isn't a common current practice.

Cheers,
Brian

---

From: Ralph Holz <[email-masked]>
Date: Wed, 08 Oct 2014 23:37:06 +0200

Hi,

> not even been deployed yet? It isn't a current practice.

Peter mentioned XMPP server-to-server, and I think Viktor (?) mentioned
MTA-to-MTA.

Presumably, unauthenticated in this case equals "code does not check
cert". Which, not without irony, is what PHP and Python used to do,
presumably in an attempt to get the user to have code that runs.

Ralph

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Oct 2014 03:07:04 +0000

> but  as a deprecated concept, to be replaced by the term

No opportunistic TLS is NOT a deprecated concept, rather it is an
approach that is improved with opportunistic DANE TLS.

We'll continue to have opportunistic TLS (cleartext baseline,
unauthenticated TLS when possible) in SMTP for quite some time.
It is indeed at present a BCP for SMTP, since so few domains
(I have a list of ~240) have DANE TLSA RRs for SMTP.

> which is regarded as a superior approach.

It subsumes opportunistic TLS as a special case when TLSA RRs
are not published, but this is by far the majority of peer systems.

> It is tricky trying to coordinate terminology across different WGs:-(

Yes, that's a natural result of parallel work.  So it is important
to try to keep abreast of activity in other groups, and thus I am
reading not only DANE WG, but also TLS WG and UTA WG traffic.

So we have:

    - Opportunistic Security  (proposed umbrella term)

    - Opportunistic TLS (opportunistic security with TLS as
      the channel security protocol, and unauthenticated TLS as
      the ceiling).

    - Opportunistic DANE TLS (opportunistic security with TLS as
      the channel security protocol, and DANE authenticated TLS
      as the ceiling for peers that publish TLSA RRs, but otherwise
      opportunistic TLS for the remaining peers).

And it should be noted that Opportunistic DANE TLS is NOT always
authenticated!  Being opportunistic, it is authenticated only when
possible (when peers publish TLSA RRs), and not otherwise.

It is not true that opportunistic security is not yet in use, and
thus out of scope for BCP documents.  It has been in use with SMTP
for ~15 years (RFC2487 and RFC3207).  It is now a BCP, with Google
reporting 72% inbound and 59% outbound TLS by volume (growing
gradually after a sharp increase up over the last year).

    https://www.google.com/transparencyreport/saferemail/

It is however an option for *this* BCP document to say that
opportunistic TLS is out of scope, and then explicitly
exclude MTA-to-MTA SMTP, Server-to-Server XMPP, ... which
are of necessity opportunistic.

More broadly, any application protocol in which clients find servers
via MX, SRV, NAPTR, ... or other DNS indirection, cannot be protected
with Web PKI authentication, especially if it relies on STARTTLS
or similar signalling.

It seems to me that many people equate TLS with HTTPS, and assume
that the requirements for HTTPS are universally applicable to all
applications.  This is not the case.

-- 
	Viktor.

---

From: t.p. <[email-masked]>
Date: Thu, 9 Oct 2014 09:58:59 +0100

----- Original Message -----
From: "Viktor Dukhovni" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, October 09, 2014 4:07 AM
Subject: Re: [Uta] Opportunistic TLS and draft-ietf-uta-tls-bcp-04

>       opportunistic TLS for the remaining peers).

Well, that is what you have in your I-D, that is what you are proposing.
The question I raise is whether or not that definition of opportunistic
TLS is the one that UTA wants to use

Orit said
"We have the "Opportunistic TLS" topic as one of the UTA potential
deliverables, so we welcome the interested parties to write a separate
draft on the subject ..... "

Well, no.  The charter does not mention opportunistic, so again, we lack
a definition, or at least a link between whichever part of the charter
people have in mind and the term "Opportunistic TLS".  On the other
hand, the charter does mention

"Many application protocols have defined methods for using TLS to
authenticate the server (and sometimes the client), and to encrypt the
connection between the client and server. "

which suggests to me that unauthenticated plain text - and your I-D does
state that

"When a TLS-encrypted communication channel is not
      available, message transmission takes place in the clear. "

- is not our primary consideration i.e. the definition given of
Opportunistic TLS in the I-D is not appropriate for UTA.

Tom Petch

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 09 Oct 2014 15:05:07 +0200

> presumably in an attempt to get the user to have code that runs.

And still the case with most ruby deployments:
https://github.com/search?q=OpenSSL%3A%3ASSL%3A%3AVERIFY_NONE&type=Code&utf8=%E2%9C%93

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 9 Oct 2014 14:06:05 +0000

> TLS is the one that UTA wants to use

I thought we weren't going to debate those definitions just yet.
Perhaps we should keep it that way?

> and your I-D does state that
> 

The definition is grounded in current practice, SMTP, XMPP, ...
start in the clear and optionally (when possible) upgrade to TLS.
If UTA arrives at definitions not grounded in that practice, that
will limit the relevance of UTA.

The WG is of course free to choose which problems to tackle and
which to leave unaddressed.  Still hoping we don't digress in this
direction just yet.

Rather, for the current draft, the decision is it seems whether to
describe which recommendations don't apply to opportunistic TLS,
or whether to simply leave opportunistic TLS out of scope, and
therefore take care to not claim applicability to MTA-to-MTA SMTP,
Server-to-Server XMPP, etc.

-- 
	Viktor.

---

From: Leif Johansson <[email-masked]>
Date: Thu, 09 Oct 2014 21:59:59 +0200

> Server-to-Server XMPP, etc.

I agree.

I propose that unless there are *conflicts* between OE and with what
is currently in the BCP we should leave the BCP as is.

This thread clearly demonstrates that there is enough material for an
OE TLS draft and/or more protocol specific OE TLS SMTP/XMPP and folks
should go off and write it (or them).

	Cheers Leif

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Thu, 9 Oct 2014 20:40:54 +0000

> draft on the subject ..... "

On Jan 17, the charter was mapped to a list of proposed deliverable. Please, see the WG archive for the corresponding thread. One of the identified deliverables is:
4. A document discussing (and potentially defining) how to apply the opportunistic encryption approach (preliminary outlined in draft-farrelll-mpls-opportunistic-encrypt-00.txt) to TLS. (Category TBD)

> people have in mind and the term "Opportunistic TLS".  

That's probably a statement for the ADs to address... Pete, could you, please, chime in and clarify (again) what the intention of the Charter language is and how it corresponds to the "Opportunistic ..." concept?

>From the UTA Charter:
"- Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved."

Thanks,
Orit.

---

From: Pete Resnick <[email-masked]>
Date: Thu, 9 Oct 2014 16:33:41 -0500

> "- Consider, and possibly define, a standard way for an application client and server to use unauthenticated encryption through TLS when server and/or client authentication cannot be achieved."

Orit has it exactly correct: What people are now referring to as 
"opportunistic TLS" is what the charter refers to as "unauthenticated 
encryption through TLS". That was the IESG's intention when the charter 
was approved.

It is up to the WG whether this document will additionally discuss the 
issue of doing authentication in an opportunistic manner.

I think references to the Opportunistic Security draft are perfectly 
reasonable.

(And just to be clear: One of the primary reasons that the term 
"opportunistic encryption" was not chosen for the title of the O-S 
document is because the term "opportunistic encryption" was already used 
by RFC 4322 in an incompatible way. Claims that it is "yet to be 
defined" are simply mistaken.)

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Ralph Holz <[email-masked]>
Date: Fri, 10 Oct 2014 00:08:59 +0200

> encryption through TLS". That was the IESG's intention when the charter

I concur - it is how I understand the term in the context of UTA. I
don't know of any ready-to-use OS standards yet?

Ralph

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 10 Oct 2014 08:12:30 +0300

Hi Leif,

Unauthenticated TLS is clearly an important use case of TLS, in the 
world outside of HTTPS. So I think we have to say *something* about it. 
What I propose is a short section that:

- Defines what we are talking about, including references to relevant 
drafts.

- Says that the BCP applies to these use cases.

Future UTA draft(s) will define the different variants of OE in more 
depth, will give technical recommendations on how to implement them, and 
will possibly describe exception cases where the current BCP does *not* 
apply.

Does this work for you?

Thanks,
	Yaron

---

From: Leif Johansson <[email-masked]>
Date: Fri, 10 Oct 2014 09:04:35 +0200

> will possibly describe exception cases where the current BCP does *not*

It does. Specifically it doesn't _tie_ the BCP to OE.

---

From: t.p. <[email-masked]>
Date: Fri, 10 Oct 2014 17:40:46 +0100

---- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "Orit Levin (LCA)" <[email-masked]>
Cc: "t.p." <[email-masked]>; <[email-masked]>
Sent: Thursday, October 09, 2014 10:33 PM
> > On Jan 17, the charter was mapped to a list of proposed deliverable.
Please, see the WG archive for the corresponding thread. One of the
identified deliverables is:
> > 4. A document discussing (and potentially defining) how to apply the
opportunistic encryption approach (preliminary outlined in
draft-farrelll-mpls-opportunistic-encrypt-00.txt) to TLS. (Category TBD)
> > That's probably a statement for the ADs to address... Pete, could
you, please, chime in and clarify (again) what the intention of the
Charter language is and how it corresponds to the "Opportunistic ..."
concept?
> >
> >  From the UTA Charter:
> > "- Consider, and possibly define, a standard way for an application
client and server to use unauthenticated encryption through TLS when
server and/or client authentication cannot be achieved."
> I think references to the Opportunistic Security draft are perfectly

Pete

Thanks for the clarification.

Tom Petch

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 10 Oct 2014 18:16:22 +0000

On Fri, Oct 10, 2014 at 08:12:30AM +0300, Yaron Sheffer wrote:

> Unauthenticated TLS is clearly an important use case of TLS, in the world
> outside of HTTPS. So I think we have to say *something* about it. What I
> propose is a short section that:
> 

When you say "the BCP applies" do you mean all of it, including
the requirements to authenticat the peer?  Or will it be specific
parts of the BCP that apply.  I am a bit confused about the final
outcome.

Perhaps someone can publish an update that addresses this question,
and then it will be easier to see whether that settles the issue,
or anything remains to iron out.

I think we have reached the point where the nature of the problem
is clear, so perhaps we'll get there faster if there is proposed
text to address it.

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 10 Oct 2014 12:27:13 -0600

On 10/10/14, 12:16 PM, Viktor Dukhovni wrote:
> the requirements to authenticat the peer?

Clearly, text about authentication doesn't apply to unauthenticated TLS.

> Or will it be specific

The authors are working on that.

Peter

-- 
Peter Saint-Andre
https://andyet.com/