Subject: [Uta] Richard Barnes' Discuss on draft-ietf-uta-tls-bcp-09: (with DISCUSS and COMMENT)

From: "Richard Barnes" <[email-masked]>
Date: Wed, 18 Feb 2015 19:34:33 -0800

Richard Barnes has entered the following ballot position for
draft-ietf-uta-tls-bcp-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I really can't abide by the abdication in Section 5.2.  Getting a cert is
hard.  Running reasonably recent software and configuring it properly is
not.  The possibility that a connection will not be authenticated is no
excuse for using bad versions of TLS or using insecure ciphersuites.

I appreciate that normally deference to WG consensus is appropriate, but
this is a recommendation that could be actively harmful to the Internet
by encouraging the continued use of broken code.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

These COMMENTs are right on the edge of being  DISCUSS points, because I
think there are some pretty critical references missing.  Please consider
this a COMMENT of Unusual Strength.

Section 1. "which together are the most widely deployed ciphers"

Actually, at least in the web context, this isn't totally true. 
According to Firefox telemetry, AES-GCM has been the most widely deployed
cipher since at least 3Q14, and is currently used in the majority of TLS
handshakes that Firefox does (52%) [1].

Section 3.1.1. Implementations MUST NOT negotiate SSL version 3

A reference to draft-ietf-tls-sslv3-diediedie seems in order here.

Section 3.1.

It would be good for this section to mention that servers MUST implement
TLS version negotiation.  That is, they MUST NOT abort the handshake if
the version offered by the client is higher than the version the server
supports.  This is, after all, the root cause of fallback.  

Section 3.1.3. 

I'm surprised that there's not even a SHOULD CONSIDER [RFC6919] for SCSV
here.  Did the WG discuss having any requirement for SCSV?

Also, if you want a cite for the 3% number, it's in the proceedings of
IETF 91 [2].

Section 3.3.

You might point out HPACK [3] as an example of compression that is
sensitive to things like CRIME.

Section 3.5.

Shouldn't this refer more specifically to draft-ietf-tls-session-hash
[4]?  As it is, the recommendations in this section are kind of vacuous;
e.g., TLS without session-hash provides no way to "bind the master secret
to the full handshake".

Section 4.4. "Modular vs. Elliptic Curve"

I think that "finite field" or "modp" are more common than "modular".

[1] http://mzl.la/1AmwXsm
[2] http://www.ietf.org/proceedings/91/slides/slides-91-saag-3.pdf
[3] https://tools.ietf.org/html/draft-ietf-httpbis-header-compression
[4] https://tools.ietf.org/html/draft-ietf-tls-session-hash

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 18 Feb 2015 21:19:32 -0700

Hi Richard, thanks for the thoughtful review. Comments inline.

On 2/18/15 8:34 PM, Richard Barnes wrote:
> I really can't abide by the abdication in Section 5.2.

Abdication is an awfully strong word.

> Getting a cert is

I think the document, then, does not provide clear enough text.

I do not think we intended to actively recommend that anyone run broken 
code, use outdated versions of TLS, use insecure ciphersuites, etc. 
However, we are saying that this document was not written specifically 
to cover unauthenticated TLS usages because that was a point of strong 
contention in the WG and we were not able to reach consensus. The thread 
beginning here is illustrative:

http://www.ietf.org/mail-archive/web/uta/current/msg00625.html

If you are insisting that this document be remanded to the WG with 
instructions that it reach consensus one way or the other, then please 
let us know.

As a result of addressing a comment from another IESG member, we will be 
changing "are" to "have been" in the quoted text.

> A reference to draft-ietf-tls-sslv3-diediedie seems in order here.

Are you thinking that would be a normative reference or an informative 
reference?

> supports.  This is, after all, the root cause of fallback.

Good point.

> here.  Did the WG discuss having any requirement for SCSV?

As I recall, the (brief) discussion concluded that a normative 
dependency on draft-ietf-tls-downgrade-scsv was not yet appropriate 
because it is too new to yet be a best *current* practice.

On a more general note, the WG considered a number of recent proposals 
for TLS hardening, but concluded as well that they were too new to 
recommend quite yet. There is breaking news (pun intended) every week 
about TLS and there's no way that a document like this can reflect the 
very latest ideas and suggestions - we tried to balance practices that 
are (or might be considered) "best" against practices that are 
implemented and can be deployed today. IMHO the most we can do is get 
this BCP published and, as needed, update or replace it with improved 
recommendations on a regular basis (say, every year or two). This 
document was supposed to be published quickly after IETF 88 and is 
already late.

> Also, if you want a cite for the 3% number, it's in the proceedings of

Thanks.

> sensitive to things like CRIME.

I see no harm in an informative reference.

> e.g., TLS without session-hash provides no way to "bind the master secret

Yes, that's what [triple-handshake] cites as well, and I agree that a 
pointer to it would be helpful.

> I think that "finite field" or "modp" are more common than "modular".

I have been told that elliptic curves are also finite fields, but I am 
not a cryptographer.

Peter

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 22:27:42 -0600

On 2/18/15 10:19 PM, Peter Saint-Andre - &yet wrote:
> I do not think we intended to actively recommend that anyone run 
> broken code, use outdated versions of TLS, use insecure ciphersuites, 
> etc. However, we are saying that this document was not written 
> specifically to cover unauthenticated TLS usages because that was a 
> point of strong contention in the WG and we were not able to reach 
> consensus. The thread beginning here is illustrative:
>

The rest I'm happy for the editors/chairs/others to take up, but let me 
take on this one:

We will discuss this on the call tomorrow. Stephen and Kathleen and I 
are working on (well, really, Stephen produced a first draft a month ago 
and I dawdled on my edit, but I hope we are close to getting out the 
door) a statement to the community regarding discussions of OS 
considerations. There are a load of reasons that in an OS (and 
potentially other unauthenticated) context you would violate some of the 
recommendations in this document. As our note will say, it is incredibly 
hard (I would say near impossible) to reasonably convey what the "right" 
approach is when talking about OS. Until we are able to get better 
community consensus on this topic and how to explain it in documents, I 
think (and I believe the WG agrees) that the right thing to say is, 
"This document isn't talking about OS" and leave it at that, which is 
what the document now says.

I'll probably share the draft text we've been working on with Richard. 
Perhaps Stephen and I will simply convince him. Perhaps he will convince 
us. But let's leave this topic for the telechat tomorrow, and we'll 
circle back to the WG if there's an issue to address.

pr

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

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Feb 2015 23:57:56 -0500

On Wed, Feb 18, 2015 at 11:19 PM, Peter Saint-Andre - &yet <[email-masked]
> wrote:

> Abdication is an awfully strong word.

And deliberately so.  Maybe it's just late here, but the current text reads
to me as incredibly weak.

> code, use outdated versions of TLS, use insecure ciphersuites, etc.

Good.  I'm glad we agree on this.

Could I ask the opposite question?  Which recommendations in the document
did people think *could* be violated in an unauthenticated context?

> However, we are saying that this document was not written specifically to
> cover unauthenticated TLS usages because that was a point of strong

Thanks for the link.  That adds some helpful context.

It also seems to me to illustrate that there's not much clarity in the
group about what problem this section is trying to solve.

Part of the source of my confusion here is that from the pure perspective
of TLS, the server is *always* authenticated (and the client, if mutual
auth is used) -- you always know what key you're talking to.  Any binding
of that key to an identity is exogenous to TLS.

Everything in the document besides Section 5 gets this right.  There's no
mention of requirements on PKIX, or PGP certs, etc, except for some
indirect mentions in the Security Considerations.

So it seems to me that this section is pure harm.  It takes a document that
got the layering right, introduces semantic confusion, and thereby arrives
at a giant loophole.

Can we just delete it?

> instructions that it reach consensus one way or the other, then please let
> us know.
>

Great.  "among the most" would have been fine too :)

> Are you thinking that would be a normative reference or an informative

Informative will be fine.  It just provides more background for this
requirement, and FWIW, duplicates it:
https://tools.ietf.org/html/draft-ietf-tls-sslv3-diediedie-00#section-2

> As I recall, the (brief) discussion concluded that a normative dependency
> on draft-ietf-tls-downgrade-scsv was not yet appropriate because it is too
> new to yet be a best *current* practice.
>
> On a more general note, the WG considered a number of recent proposals for
> TLS hardening, but concluded as well that they were too new to recommend
> quite yet. There is breaking news (pun intended) every week about TLS and
> there's no way that a document like this can reflect the very latest ideas
> and suggestions - we tried to balance practices that are (or might be
> considered) "best" against practices that are implemented and can be
> deployed today. IMHO the most we can do is get this BCP published and, as
> needed, update or replace it with improved recommendations on a regular
> basis (say, every year or two). This document was supposed to be published
> quickly after IETF 88 and is already late.
>

Fair enough.  Thanks for the background.

> pointer to it would be helpful.

Yes, please make this direct.

> I have been told that elliptic curves are also finite fields, but I am not
> a cryptographer.
>

/me dusts off his math degree...

To get very technical, elliptic curves are finite *groups* (they're not
fields; they have no multiplication operation), whereas a modp group is the
multiplicative group of a finite field.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Feb 2015 00:02:02 -0500

On Wed, Feb 18, 2015 at 11:27 PM, Pete Resnick <[email-masked]>
wrote:

> We will discuss this on the call tomorrow. Stephen and Kathleen and I are
> working on (well, really, Stephen produced a first draft a month ago and I
> dawdled on my edit, but I hope we are close to getting out the door) a
> statement to the community regarding discussions of OS considerations.
> There are a load of reasons that in an OS (and potentially other
> unauthenticated) context you would violate some of the recommendations in
> this document.

I look forward to your documentation of which recommendations and which
reasons.

> As our note will say, it is incredibly hard (I would say near impossible)
> to reasonably convey what the "right" approach is when talking about OS.

I will object strenuously to anything that suggests that continuing to use
broken algorithms or protocols is any sense a "right" approach.
Fortunately, Peter's note implies that this is not what the WG intended.

> Until we are able to get better community consensus on this topic and how
> to explain it in documents, I think (and I believe the WG agrees) that the
> right thing to say is, "This document isn't talking about OS" and leave it
> at that, which is what the document now says.
>

It's wrong to just throw up our hands and give carte blanche just because
we might need to red-line a few things.  At most, we should say something
like, "OS is a work in progress; until further notice, use this as a
baseline and deviate to the minimal extent possible."

--Richard

> us. But let's leave this topic for the telechat tomorrow, and we'll circle
> back to the WG if there's an issue to address.
>
> pr
>
> --

---

From: Pete Resnick <[email-masked]>
Date: Wed, 18 Feb 2015 23:20:20 -0600

On 2/18/15 11:02 PM, Richard Barnes wrote:
>
>     We will discuss this on the call tomorrow. Stephen and Kathleen
>     and I are working on (well, really, Stephen produced a first draft
>     a month ago and I dawdled on my edit, but I hope we are close to
>     getting out the door) a statement to the community regarding
>     discussions of OS considerations. There are a load of reasons that
>     in an OS (and potentially other unauthenticated) context you would
>     violate some of the recommendations in this document. 
>
>
> I look forward to your documentation of which recommendations and 
> which reasons.

That is a topic for another chartered item that the WG is to take on:

http://www.ietf.org/mail-archive/web/uta/current/msg00649.html

I think it would be disastrous to hold up this document (which has 
plenty of good recommendations for non-OS normal uses of TLS) in order 
to explain how this document applies (and does not apply) to OS uses. 
Which is why I think this document should say, "Not addressed here."
>
>     As our note will say, it is incredibly hard (I would say near
>     impossible) to reasonably convey what the "right" approach is when
>     talking about OS. 
>
>
> I will object strenuously to anything that suggests that continuing to 
> use broken algorithms or protocols is any sense a "right" approach.  

There are OS scenarios in which the use of a known weak algorithm is 
perfectly appropriate. This document should not say anything that would 
indicate otherwise.
>
>     Until we are able to get better community consensus on this topic
>     and how to explain it in documents, I think (and I believe the WG
>     agrees) that the right thing to say is, "This document isn't
>     talking about OS" and leave it at that, which is what the document
>     now says.
>
>
> It's wrong to just throw up our hands and give carte blanche just 
> because we might need to red-line a few things.

I have no idea what you mean by "give carte blanche" here. We don't 
write conformance standards. We know and have consensus on what this 
document recommends in non-OS contexts. We don't have consensus on what 
should be recommended in OS contexts. This document should not attempt 
to pre-determine what a followup document will say.

> At most, we should say something like, "OS is a work in progress; 
> until further notice, use this as a baseline and deviate to the 
> minimal extent possible."

That is significantly worse, in my view, than saying, "We're not talking 
about OS here."

More tomorrow.

pr

---

From: Brian Smith <[email-masked]>
Date: Wed, 18 Feb 2015 22:26:00 -0800

Richard Barnes <[email-masked]> wrote:
> Pete Resnick <[email-masked]> wrote:
> It's wrong to just throw up our hands and give carte blanche just because we
> might need to red-line a few things.  At most, we should say something like,
> "OS is a work in progress; until further notice, use this as a baseline and
> deviate to the minimal extent possible."

The working group agreed that unauthenticated TLS is out of scope for
the document. Saying anything other than unauthenticated TLS is out of
scope would misrepresent the working group's consensus.As others
pointed out, if and how much of this document is appropriate for
unauthenticated TLS is very unclear and deciding that would add a lot
of delay to the publication of the document.

The working group already decided to defer much more serious and more
widely-relevant issues (like the complete lack of any recommendations
regarding ECDSA cipher suites, despite these being the most
interoperable AES-GCM cipher suites available and the best ones for
server-side performance, or the fact that the document recommends DHE
cipher suites despite clear evidence that DHE cipher suites are a
minefield) in the interests of getting the document published on a
reasonable schedule.

IMO, unauthenticated TLS is so different from secure use of TLS that
it deserves its own document once we've learned what the *best*
*current* practices for unauthenticated TLS are, which we currently do
not know.

Cheers,
Brian

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Feb 2015 01:28:00 -0500

On Thu, Feb 19, 2015 at 1:26 AM, Brian Smith <[email-masked]> wrote:

> because we

I'm curious how you think unauthenticated TLS is so dramatically
different.  I mean, WebRTC connections are all unauthenticated, and they
look exactly the same on the wire as authenticated connections -- the
endpoints just don't check the certs.

--Richard

---

From: Brian Smith <[email-masked]>
Date: Wed, 18 Feb 2015 22:36:09 -0800

Richard Barnes <[email-masked]> wrote:
> I'm curious how you think unauthenticated TLS is so dramatically different.
> I mean, WebRTC connections are all unauthenticated, and they look exactly
> the same on the wire as authenticated connections -- the endpoints just
> don't check the certs.

Sorry, allow me to edit that:

Unauthenticated TLS deserves its own document once we've learned what
the *best* *current* practices for unauthenticated TLS are, which we
currently do not know.

Obviously, since we don't know the best current practices for
unauthenticated TLS (except, possible, to avoid it), we can't
meaningfully discuss how they are different from best best current
practices for authenticated TLS, which is what the UTA working group
discussed to produce this document.

Cheers,
Brian

---

From: Leif Johansson <[email-masked]>
Date: Thu, 19 Feb 2015 09:25:26 +0100

> here.  Did the WG discuss having any requirement for SCSV?

The WG has been struggling to keep the BCP from turning into a list of
things we might wish were true instead of describing what is (or at
least seems to be) true at this time.

Are you sure this one doesn't fall into the first category?

I'll leave everything else for the authors.

	Cheers Leif

---

From: Leif Johansson <[email-masked]>
Date: Thu, 19 Feb 2015 09:25:26 +0100

Cheers Leif

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 19 Feb 2015 10:17:48 +0000

On 19/02/15 04:57, Richard Barnes wrote:
> of TLS, the server is *always* authenticated (and the client, 

Factually incorrect. Anon-DH has been present in TLS since the
beginning. If your DISCUSS is based on that misapprehension then
you need to re-consider.

S.

> if mutual

---

From: Richard Barnes <[email-masked]>
Date: Thu, 19 Feb 2015 09:35:50 -0500

On Thu, Feb 19, 2015 at 5:17 AM, Stephen Farrell <[email-masked]>
wrote:

> >>> Please refer to
> http://www.ietf.org/iesg/statement/discuss-criteria.html
> to

Well, that brings up another thing that this document should deprecate.  ;)

As RFC 5246 points out:
"""
   Note that using non-anonymous key exchange without actually verifying
   the key exchange is essentially equivalent to anonymous key exchange,
   and the same precautions apply.
"""

In other words, you still know that you're talking to the holder of the
private key corresponding to the server's public (DH) key.    It's
equivalent to a self-signed cert.  You could "authenticate" it by checking
that it's the right DH key out of band, in the same way as a self-signed
cert.

The basis of my DISCUSS is I haven't heard anyone say what they would want
to change about this document to make it suitable for an "unauthenticated"
environment.  Regardless of whether there's consensus for changes, if
nobody's asking for changes, we shouldn't preemptively open the door.

After talking with Pete some last night, I think another confusion here is
(predictably) over uses of "opportunistic"  (as indeed the title of section
5.2 implies).

1. Using TLS without checking the credentials presented by the remote side
2. Interoperating with legacy things using whatever TLS settings possible

I get the sense that a lot of the discussion here, especially from the mail
perspective, is related to the second thing, which is so clearly out of
scope for this document that it doesn't bear mentioning.  And what I'm
saying above is that this document *also* doesn't need to say anything
about the first thing, because TLS looks exactly the same on the wire
whether you check the credentials or not.

I would probably be OK if the "Opportunistic" stuff were scoped down to
say, "This document doesn't say anything about how you choose whether to
use TLS for a given session, just how you use it once you do," and the
unauthenticated stuff were removed entirely.

--Richard

> let
> dependency
> for
> not

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Feb 2015 04:27:18 +0000

>    and the same precautions apply.

    * Some servers may prefer to know which clients have chosen to
      not authenticate them, and may offer such clients reduced
      service or simply have a better audit trail of client policy.
      This is explained in:

	https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-13#section-8.2

      This is, for example, how I know that though ietf.org's email
      server has TLSA records and can be authenticated by DANE-capable
      SMTP clients, it is not yet itself a DANE-capable MTA, and
      does not authenticate my SMTP server's certificate (it uses
      anon-DH when connecting to my domain).  [ I might reach out
      to the AMSL email admins and see whether they're yet in a
      position to upgrade to Postfix 2.11.x and also enable outbound
      DANE verification. This was not yet an option at the time
      they first published TLSA RRs a year or so back. ]

    * A client that knows that it will not in fact check the server
      certificate, can inform the server of this fact by announcing
      support for anon-DH ciphersuites in addition to support for
      various types of certificates that it will ignore.

    * Such a client interoperates with servers that field no
      certificates, as well as with servers that field certificates.

    * Some clients will support only anon-DH, but will be secure
      because they use channel-binding (e.g., with GSSAPI) to secure
      the connection, and any negotiation of certificates is then
      just wasted bits on the wire and wasted processing.

> nobody's asking for changes, we shouldn't preemptively open the door.

In an opportunistic context, (TLS) encryption is used simply because
it appears to be possible.  Cleartext transmission is permitted
and used otherwise, and no more security than that is expected.
If TLS happens to be possible, hooray, maybe you get more than you
expected.  So the peers communicate by any means available, but
try to be as secure as circumstances allow.

In this context, any crypto that is not demonstrably as weak as
cleartext, and is still the best that some non-negligible fraction
of peers are capable of (e.g. some Exchange 2003 SMTP servers that
do at best TLS_RSA_WITH_RC4_128_SHA) is acceptable crypto.  If the
TLS stack refuses to support that, then communication happens in
the clear.  The identity function (cleartext) offers less
confidentiality (against humans glancing over your shoulder) than
ROT13 which is in turn offers less security (against passive
attackers) than 128-bit RC4.

> scope for this document that it doesn't bear mentioning.  

With opportunistic TLS one accepts both communication where
authentication is impractical and communication where cryptography
is uses deprecated algorithms that are still sufficiently widely
"best available".

Thus most Postfix deployments disable SSLv2 (everyone can do better),
but not RC4 (enough sites for now cannot do better).  The RC4
ciphersuites required for interoperability are also non-PFS.

> And what I'm

The document is not only about the bits that go on the wire.  It
is also about checks that clients SHOULD or MUST perform.

> unauthenticated stuff were removed entirely.

Well, when Postfix uses opportunistic TLS both client and server
prefer anon-DH ciphersuites over RSA or ECDSA ciphersuites, clients
ignore any certificates the server may return, and at present even
EXPORT (which include 40-bit RC4) cipher-suites are allowed.  TLS
is used routinely in ~70% of email MTA to MTA email transactions,
with no user to "click-OK".

Where the BCP recommends things that should be preferred, it is
largely applicable to opportunistic TLS with SMTP, one just needs
to prefer best-practice.  

Where the BCP attempts to proscribe things that are now potentially
vulnerable to attack, but which are still the best available for
enough peers, opportunistic use of TLS needs to ignore any advice
that would otherwise lead to much cheaper attacks on cleartext.

Basically, I'm fine with "raising the ceiling" as high as it seems
to make sense, but once the floor is raised too high, the BCP no
longer applies to opportunistic TLS.

	* server authentication needs to remain optional
	* non-PFS key exchange is still needed
	* RC4 and SSLv3 are still needed (perhaps another 2-3
	  years might be enough to change this).

	* SSLv2, MD5 and <= 64-bit ciphers can go, they are no
	  longer used, but banning them is largely unnecessary.
	  They've disappeared without a ban.

-- 
	Viktor.

P.S.  I am surprised by the repeated statements that "we don't know"
      what is required for opportunistic security.  It is rather
      simple, what's required is the freedom to adapt to the peer's
      capabilities, including those of peers in the long tail of the
      protocol technology adoption curve.

      Of course at some point truly obsolete protocols are left
      behind, but that happens long after they are no longer
      best-practice, rather it happens when they are essentially
      no longer practiced at all.

      Best current practices still make it into opportunistic
      security.  They are what should expect happen when the
      communicating peers are reasonably up to date.  Often
      one even gets better than best current practice, because
      both peers are "bleeding edge".

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Feb 2015 06:50:18 +0000

On Wed, Feb 18, 2015 at 09:19:32PM -0700, Peter Saint-Andre - &yet wrote:

> I have been told that elliptic curves are also finite fields, but I am not a
> cryptographer.

Elliptic Curves are not Finite Fields.  Elliptic curves can be
defined over finite fields, but the points on the curve constitute
only an Abelian (commutative) group, not a field.

In fact, the phrase "modular" would be unfortunate in this context,
because with Elliptic Curves in takes on a completely different
meaning (see Wikipedia entry on the "Modularity Theorem").

So I support a change of terminology to "modp", since with DHE only
the fields $F_p$ with $p$ a prime are used, and in fact the DH
algorithm only uses the multiplicative (mod p) group structure of
the non-zero elements of the field (which form an Abelian group
with p-1 elements).

With modp DHE and with Elliptic Curves one looks for the number of
elements in the resulting group to be a small multiple of a prime
$q$, and then an element (generator or base point) is chosen which
generates a subgroup of size $q$.

With DHE typically that multiple (or "cofactor") is 2, and primes
$p$ where $p-1$ is equal to $2q$ with $q$ also prime are called
"safe", with $q$ called a Sophie-Germain prime. If $q$ is 11 modulo
12 (or equivalently $p$ is 23 mod 24) then the generator can be
chosen to be 2.  So DHE in practice uses exactly this type of prime.

With Elliptic Curves the "cofactor" is often 4 or 8.

-- 
	Viktor.

---

From: Ralph Holz <[email-masked]>
Date: Fri, 20 Feb 2015 21:45:08 +1100

Hi Viktor,

> longer applies to opportunistic TLS.
Thanks for jumping in and providing a good summary.

In my opinion, the purposes of this BCP *and* of OS are best served if we
leave the BCP wording as it is - we address the authenticated use case
only. There are more than enough deployments that are covered by the BCP's
recommendations. For OS, I would be happy to see a different document to
focus on that use case, and do it well - as indeed the WG consensus was,
too.

Ralph

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 20 Feb 2015 07:42:52 -0700

On 2/20/15 3:45 AM, Ralph Holz wrote:
> In my opinion, the purposes of this BCP *and* of OS are best served if
> we leave the BCP wording as it is - we address the authenticated use
> case only. There are more than enough deployments that are covered by
> the BCP's recommendations. For OS, I would be happy to see a different
> document to focus on that use case, and do it well - as indeed the WG
> consensus was, too.

+1

I'm going to submit version -10 now.

Peter

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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Feb 2015 11:23:26 -0500

>> document to focus on that use case, and do it well - as indeed the WG

I am also +1 to a separate document for opportunistic.  It's just the
"unauthenticated" stuff that I object to, and the fact that the two are
confused with each other in 5.2.  We need to disentangle the two to be
clear about what we're talking about.

It's also important to keep in mind that while opportunistic usage of TLS
may imply skipping authentication, the converse is not necessarily true --
there are use cases for unauthenticated TLS that not opportunistic (i.e.,
they will not fall back to plaintext).

With those considerations in mind, I would propose the  following revisions
to sections 5.1 and 5.2 (replacing one paragraph in 5.1 and all of 5.2):

"""
5.1.

...

   With regard to authentication, TLS enables authentication of one or
   both end-points in the communication.  In the context of opportunistic
   security [RFC7435], TLS may be used without authentication. As
   discussed in Section 5.2, considerations for opportunistic security
   are not in scope for this document.

...

5.2.  Opportunistic Security

   There are several important applications in which the use of TLS itself
   is optional, i.e. the client decides dynamically ("opportunistically")
   whether to use TLS with a particular server or to connect in the clear.
   This practice, often called "opportunistic security", is described at
   length in [RFC7435].  These scenarios also often involve support for
   legacy equipment.

   In such cases, some of the recommendations in this document might
   be too strict, since adhering to them could cause fallback to plaintext,
   a worse outcome than using TLS with an outdated protocol version
   or ciphersuite.  The sense of the UTA Working Group was to complete
   work on this document about best practices for TLS in general, and to
   initiate work on a separate document about opportunistic TLS.
"""

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 20 Feb 2015 08:33:35 -0800

This LGTM.

On Fri, Feb 20, 2015 at 8:23 AM, Richard Barnes <[email-masked]> wrote:

>
>
> On Fri, Feb 20, 2015 at 9:42 AM, Peter Saint-Andre - &yet <
> [email-masked]> wrote:
>
> With those considerations in mind, I would propose the  following
> revisions to sections 5.1 and 5.2 (replacing one paragraph in 5.1 and all
> of 5.2):
>
> """
> 5.1.
>
> ...
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 20 Feb 2015 09:43:46 -0700

Modulo a few nits (inline), this seems acceptable to me.

On 2/20/15 9:23 AM, Richard Barnes wrote:
>
>
> On Fri, Feb 20, 2015 at 9:42 AM, Peter Saint-Andre - &yet
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> It's also important to keep in mind that while opportunistic usage of
> TLS may imply skipping authentication, the converse is not necessarily
> true -- there are use cases for unauthenticated TLS that not
> opportunistic (i.e., they will not fall back to plaintext).
>
> revisions to sections 5.1 and 5.2 (replacing one paragraph in 5.1 and
> all of 5.2):
>
> """
> 5.1.
>
> ...
>
>     security [RFC7435], TLS may be used without authentication.

Instead of "may", I'd prefer "can be" or "is sometimes" or "is often" 
because "may" implies permission (let some other spec say it's acceptable).

> As

Instead of "equipment", I'd prefer "deployments" because "equipment" 
makes it sound a hardware issue.

>     initiate work on a separate document about opportunistic TLS.

+1 otherwise.

Peter

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Feb 2015 12:06:13 -0500

Those fixes are fine with me.

On Fri, Feb 20, 2015 at 11:43 AM, Peter Saint-Andre - &yet <[email-masked]

> Instead of "equipment", I'd prefer "deployments" because "equipment" makes
> it sound a hardware issue.
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Feb 2015 19:12:58 +0000

FWIW, I could live with the current text or with Richard's (modulo
one thing below). Or with stuff in-between.

>    initiate work on a separate document about opportunistic TLS.

No, I don't believe we've decided that UTA will be the place where
we develop a BCP on OS. Such a document might or might not be all
about TLS, so I think the last sentence needs to not commit the UTA
WG as the venue where such work will be done, as some list discussion
would be needed on that first. (I'm fine that we commit that the
IETF will do that work somewhere, just not with it being definite
that UTA will do it.)

The reason is there are also OS uses of e.g. IPsec on which folks
are working and Adrian and I have an MPLS OS draft. It's not yet
clear whether it'd be best to have a single BCP that has broader
coverage or whether it'd be better to have a TLS specific BCP.

I'd really really hope we disentangle that discussion from this
draft though, so please replace the last sentence with:

                "The sense of the UTA Working Group was to complete
work on this document about best practices for TLS in general, and to
for work on a separate BCP document about opportunistic security
to be done later."

Cheers,
S.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Feb 2015 14:43:35 -0500

On Fri, Feb 20, 2015 at 2:12 PM, Stephen Farrell <[email-masked]>
wrote:

> [email-masked]>
> revisions
> we develop a BCP on OS.

FWIW:
- That text is not mine; it has been in since -07.
- I would personally be A-OK with UTA working on opportunistic TLS,
especially in the sense of providing advice on how to interop with old
stuff in ways most likely to result in TLS usage.
- It's probably not a great idea to say that in this document

How about:
"The sense of the UTA Working Group was to complete work on this document
about best practices for TLS in general, and to leave recommendations about
opportunistic TLS for future work."

> Such a document might or might not be all

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Feb 2015 14:22:03 -0600

On 2/20/15 1:43 PM, Richard Barnes wrote:
>
> On Fri, Feb 20, 2015 at 2:12 PM, Stephen Farrell 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>>         The sense of the UTA Working Group was to complete
>     we develop a BCP on OS. [...]
>
> "The sense of the UTA Working Group was to complete work on this 
> document about best practices for TLS in general, and to leave 
> recommendations about opportunistic TLS for future work."

Or we could drop mention of the WG entirely:

"This document specifies best practices for TLS in general. A separate 
document with recommendations for the use of TLS with opportunistic 
security is to be completed in the future."

pr

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Feb 2015 15:34:07 -0500

Yes, the passive voice *is* good for avoiding responsibility!

On Fri, Feb 20, 2015 at 3:22 PM, Pete Resnick <[email-masked]>
wrote:

> On Fri, Feb 20, 2015 at 2:12 PM, Stephen Farrell <
> [email-masked]> wrote:
>
>>
> Pete Resnick <http://www.qualcomm.com/~presnick/> <http://www.qualcomm.com/~presnick/>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 20 Feb 2015 13:41:46 -0700

> security is to be completed in the future."

Sure.

So (with some hopefully slight edits)...

###

    There are several important scenarios in which the use of TLS is
    optional, i.e., the client decides dynamically ("opportunistically")
    whether to use TLS with a particular server or to connect in the
    clear.  This practice, often called "opportunistic security", is
    described at length in [RFC7435] and is often motivated by a desire
    for backward compatibility with legacy deployments.

    In these scenarios, some of the recommendations in this document
    might be too strict, since adhering to them could cause fallback to
    cleartext, a worse outcome than using TLS with an outdated protocol
    version or cipher suite.

    This document specifies best practices for TLS in general.  A
    separate document containing recommendations for the use of TLS with
    opportunistic security is to be completed in the future.

###

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 20 Feb 2015 20:52:53 +0000

On Fri, Feb 20, 2015 at 06:50:17AM +0000, Viktor Dukhovni wrote:

[ Top post: So should the title and text of 4.4 be changed? ]

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 20 Feb 2015 13:55:52 -0700

> [ Top post: So should the title and text of 4.4 be changed? ]

Well, modp is, I assume, short for Modular Exponentiation so the RFC 
Editor is going to ask us to spell it out on first use anyway.

Personally, this is not a hill to die on for me...

Peter

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Feb 2015 15:57:59 -0500

SGTM, except your use of "#" confused my mental Markdown parser :)

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 20 Feb 2015 14:08:17 -0700

> SGTM, except your use of "#" confused my mental Markdown parser :)

Sorry about the parser issues!

Since we seem to all be on the same page, I'm going to submit -11 with 
this text and Viktor's little modp fix so that we can all move on with 
our lives...

Peter

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Feb 2015 21:14:16 +0000

Richard's, Pete's or Peter's takes on this are all fine. Let's ship it!

S.

---

From: Richard Barnes <[email-masked]>
Date: Fri, 20 Feb 2015 17:08:56 -0500

Thanks!  I cleared.

On Fri, Feb 20, 2015 at 4:08 PM, Peter Saint-Andre - &yet <[email-masked]>
wrote:

> this text and Viktor's little modp fix so that we can all move on with our
> lives...
>
> Peter
>
>
>

---

From: Leif Johansson <[email-masked]>
Date: Fri, 20 Feb 2015 23:12:11 +0100

> Thanks!  I cleared.

The sound you are hearing in the background is the sound of the the two
chairs exhaling.

Thx everyone for very good work!

	Cheers Leif

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 20 Feb 2015 17:31:55 -0500

> this text and Viktor's little modp fix so that we can all move on with 

If we could use the term "finite field" instead of modp, that would
align the text with
https://tools.ietf.org/html/draft-ietf-tls-negotiated-ff-dhe which might
present less confusion for someone reviewing both documents in the
future.

Apologies for chiming in late in the day on this.

          --dkg

---

From: Leif Johansson <[email-masked]>
Date: Fri, 20 Feb 2015 23:34:43 +0100

> present less confusion for someone reviewing both documents in the

Once you start to try to learn about ec, confusion avoidance really
isn't a tenable position anymore.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Fri, 20 Feb 2015 15:48:41 -0700

> isn't a tenable position anymore.

If we absolutely need to clarify this small bit of terminology, we can 
do that during AUTH48.

Peter

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

---

From: Pete Resnick <[email-masked]>
Date: Fri, 20 Feb 2015 16:49:22 -0600

Sounds like a plan. I'm off to push the approval button. Thanks all.

pr

---

From: t.p. <[email-masked]>
Date: Sat, 21 Feb 2015 10:50:52 +0000

----- Original Message -----
From: "Pete Resnick" <[email-masked]>
To: "Richard Barnes" <[email-masked]>
Sent: Friday, February 20, 2015 8:22 PM
> security is to be completed in the future."

Pete

As you may recall, this is in the charter for UTA.  The wording is
slightly different but as you clarified last October
=============================
>  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."

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

so it seems to me that the decision now is that the UTA WG will do it in
a separate document (or else will have a revised charter).

Tom Petch

> pr

------------------------------------------------------------------------
--------

---

From: Pete Resnick <[email-masked]>
Date: Mon, 23 Feb 2015 12:42:10 -0600

On 2/21/15 4:50 AM, t.p. wrote:
>>> <[email-masked] <mailto:[email-masked]> wrote:
>>>
>>>>     work on this document about best practices for TLS in
>>>>     general, and to initiate work on a separate document
>>>>     about opportunistic TLS.
>>>>
>>> How about: "The sense of the UTA Working Group was to complete work 
>>> on this document about best practices for TLS in general, and to 
>>> leave recommendations about opportunistic TLS for future work." 

I read the -09 text as saying, "The WG considered this, but decided that 
there will be a separate document." There is nothing in the charter that 
says how many documents to work on, and Stephen and Richard wanted to 
make it clear that the WG hasn't decided what (if anything) it wants to 
say about OS. So we made the text softer on this point. I don't think 
there's anything inconsistent with what I said before. I don't see the 
circumstance in which a revised charter will be needed.

pr