Subject: [Uta] Fwd: New Version Notification for draft-ietf-uta-tls-bcp-05.txt

From: Yaron Sheffer <[email-masked]>
Date: Tue, 14 Oct 2014 00:47:33 +0300

What's new?

- Lots of edits and some section rearrangement (thanks Sean!)
- A short but important section on unauthenticated TLS.

Thanks,
	Yaron

-------- Forwarded Message --------
Subject: New Version Notification for draft-ietf-uta-tls-bcp-05.txt
Date: Mon, 13 Oct 2014 14:31:11 -0700
From: [email-masked]
To: Peter Saint-Andre <[email-masked]>, Yaron Sheffer 
<[email-masked]>, Ralph Holz <[email-masked]>, Ralph Holz 
<[email-masked]>, Peter Saint-Andre <[email-masked]>, Yaron 
Sheffer <[email-masked]>

A new version of I-D, draft-ietf-uta-tls-bcp-05.txt
has been successfully submitted by Yaron Sheffer and posted to the
IETF repository.

Name:		draft-ietf-uta-tls-bcp
Revision:	05
Title:		Recommendations for Secure Use of TLS and DTLS
Document date:	2014-10-14
Group:		uta
Pages:		22
URL: 
http://www.ietf.org/internet-drafts/draft-ietf-uta-tls-bcp-05.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-uta-tls-bcp/
Htmlized:       http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-05
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-uta-tls-bcp-05

Abstract:
    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.  This document provides recommendations for improving
    the security of deployed services that use TLS and DTLS.  The
    recommendations are applicable to the majority of use cases.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Leif Johansson <[email-masked]>
Date: Tue, 14 Oct 2014 09:28:20 +0200

> - A short but important section on unauthenticated TLS.

Excellent work Yaron, Ralph and Peter!

Folks - lets review this version asap. The chairs are still hoping and
planning for a WGLC before Hawaii!

	Cheers Leif & Orit

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Oct 2014 08:30:11 +0000

> - A short but important section on unauthenticated TLS.

Please replace the long obsolete reference to:

    https://tools.ietf.org/html/draft-dukhovni-smtp-opportunistic-tls-01

and even more obsolete:

    https://tools.ietf.org/html/draft-ietf-dane-smtp-01

with

    https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12

which supersedes both.

I don't know whether it makes sense to mention that authentication
via DANE TLSA might some day obviate the need for CRLs.  I am
guessing that this being a BCP, and DANE not yet being a significant
current practice, such a comment might be premature.  However, the
text does contain some "forward looking statements" about future
"must staple" signals, ... and thus perhaps other "forward looking
statements" might not be out of place.

Comments on particular text:
----------------------------

1.
The text about <128-bit ciphersuites is a bit imprecise:

    Implementations SHOULD NOT negotiate cipher suites that use
    algorithms offering less than 128 bits of security.	

    Rationale: Cipher suites that offer between 112-bits and 128-bits	
    of security are not considered weak at this time, however 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.

The Rationale says "between" without clarifying which end-points
are included.  Presumably the grey-zone is [112, 128).  I've seen
no credible suggestions that anyone is remotely close to brute-forcing
a 128-bit key through exhaustive search.  So perhaps "at least
several years", is rather too gloomy.

Finally, with opportunistic TLS, even 112-bit 3DES is stronger than
cleartext, and the "SHOULD NOT" does not apply.  After all, in
these cases not finding a mutually agreeable cipher suite typically
leads to cleartext transmission, and cleartext is by far the weakest
option.  I've not been able to convince Wietse that we should
disable any algorithms with opportunistic TLS (even 40bit export-grade
RC4).  And he's not wrong, even though I've not seen any evidence
of its use in years, so I would be willing to risk cleartext with
any miraculous export-only peers.

And in particular the "MUST NOT" for RC4 is also inapplicable with
opportunistic TLS.

2.
SNI requirement is I think too strong:

    TLS implementations MUST support the Server Name Indication (SNI)	
    extension for those higher level protocols which would benefit from	
    it, including HTTPS.  However, unlike implementation, the use of SNI	
    in particular circumstances is a matter of local policy.	

TLS clients SHOULD certainly signal SNI where applicable.  However,
MUST is too strong IMHO.  If the client is using opportunistic TLS
(without authentication), the server certificate is irrelevant,
and sending SNI might trigger handshake failures if the server has
no matching certificate (SMTP MTAs don't even know which reference
identifier applies to the peer).

For server applications which for various reasons don't support
multiple server identities, there is no reason to require SNI.
Such servers can simply ignore all SNI extensions in the client
HELLO.  I have no intention of adding server-side SNI support in
Postfix.  The Postfix SMTP client uses SNI only with DANE
authentication, because with DANE it is finally possibly to reliably
infer a server reference identifier (the TLSA base domain).

3.
SSL Protocol version recommendations.

Once again with unauthenticated opportunistic TLS even SSL 3.0 or
TLS 1.0 is (much) better than cleartext.  So the MUST NOT SSL 3.0
and SHOULD NOT TLS 1.0 are too strong.

4.
Integrity protection text:

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

It is not clear whether this is talking about integrity via
authenticated key exchange?  Or integrity protection of the data
stream via HMAC, AEAD, ...?  If the former, then there is once again
a conflict with keeping opportunistic TLS in scope.

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 14 Oct 2014 13:56:52 +0200

Hi Viktor,

I disagree with a couple of points you make:

* Viktor Dukhovni <[email-masked]> [141014 10:30]:
> [...]

So once again we have the whole 'opportunistic' discussion. I
strongly disagree that both should be changed from MUST NOT to a
SHOULD NOT or even something less. The whole point should be to
deprecate SSLv3 and RC4 as soon as possible, no matter what. I do
not think it does matter if the WG sees 'opportunistic' encryption
as sufficient - both have to go. They are a real world security
threat. In particular downgrade attacks on unauthenticated TLS
will enable less-than-optimal security for server and client with
SSLv3 and might enable various attack vectors. For example, the
recent virtual host confusion attack [0] relies on this fact. I'm sure
there are other attacks. If we're talking 'opportunistic' again: as
far as I can remember SSLv3 is succeptible to replay attacks on
anonymous diffie-hellman [1].

As said, I think we should deprecate RC4 and SSLv3 ASAP.

I'm happy that Google does practically the same thing with
deprecating SHA1: once their browser and android devices will issue
a warning, every snakeoil CA needs to act or will loose customers.
Sometimes you have to push to get good security widely deployed.

Aaron

[0] - http://bh.ht.vc/
[1] - https://www.schneier.com/paper-ssl.pdf

---

From: Ralph Holz <[email-masked]>
Date: Tue, 14 Oct 2014 14:05:24 +0200

+1 for what Aaron writes: weak algorithms must go. Else we can just stop
the entire enterprise of writing a BCP and break for tea and biscuits.

I think, in the context of this BCP, which is forward-looking, it is
reasonable to say all else weak crypto MUST go, and especially RC4. OE/OS
is still free to fall back to anything unauthenticated/unencrypted that may
still linger around, but even OE/OS should be happy to get newer algorithms.

On 14 October 2014 13:56, Aaron Zauner <[email-masked]> wrote:

> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>
>

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 14 Oct 2014 14:23:50 +0200

> > and SHOULD NOT TLS 1.0 are too strong.

BTW: On the SHOULD NOT for TLS 1.0, see BEAST (CVE-2011-3389). There
was also [0]. This is a protocol flaw that some tried to mitigate with
RC4 [sic!] a while ago. There's not much that you can do anyhow, AEAD
ciphersuites are not available in TLS 1.0 nor is protection against
chosen-plaintext attacks with CBC [1]. This is fixed in TLS 1.1.

Aaron

[0] - http://www.iacr.org/cryptodb/archive/2003/CRYPTO/1069/1069.pdf
[1] - http://eprint.iacr.org/2004/111
      http://eprint.iacr.org/2006/136

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 14 Oct 2014 15:19:01 +0200

Whoop, also I just discovered this:
http://www.theregister.co.uk/2014/10/14/nasty_ssl_30_vulnerability_to_drop_tomorrow/

We might need to change the attack draft again after all.

Aaron

---

From: Ralph Holz <[email-masked]>
Date: Tue, 14 Oct 2014 15:42:54 +0200

Prolly not much to change - short summary, done.

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 14 Oct 2014 17:59:13 +0300

Hi Viktor,

Thanks for your comments!

I agree we SHOULD tone down a few of the requirements, to make sure we 
do accommodate the opportunistic use case.

OTOH I agree with Aaron on (for example) still forbidding export-level 
ciphers.

We all should compromise a little bit so that we can have a single BCP 
for both the authenticated and unauthenticated use cases.

Best,
	Yaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Oct 2014 16:47:28 +0000

On Tue, Oct 14, 2014 at 01:56:52PM +0200, Aaron Zauner wrote:

> SHOULD NOT or even something less.

I'm willing to accept MUST NOT for mandatory (non-opportunistic)
TLS.  However, claiming that SSL 3.0 is worse than cleartext is
simply absurd.  Perhaps the BCP should not apply to opportunistic
uses of TLS, and those should be written up separately.  If however
the preference is to have one BCP that covers applies to both
mandatory and opportunistic TLS, then some of the recommendations
need to be made at least context sensitive, or else less strongly.

I'll take SSL 3.0 or TLS 1.0 over cleartext any day, especially
for applications where most of the HTTP attacks (BEAST, CRIME,
....) simply don't apply.  MTA to MTA SMTP is cookie-less, and
injection of chosen plaintext early in the SMTP dialogue is not
feasible.

    S: 220 ...
    C: EHLO {fixed name}
    S: 250 ...
    C: AUTH PLAIN {fixed secret} 	# Only with submission and should/must mandatory TLS!
    S: 250 ...
    C: MAIL FROM:<sender> [ESMTP options]
    S: 250 ...
    C: RCPT TO:<rcpt> [ESMTP options]   # First possible chosen plaintext
    C: ...

The only risk I'm aware of for SMTP is use of RC4 for submission
with PLAIN auth.  This may eventually leak the user's login
credentials after some number of millions of email messages are
sent, which at O(100) per day is at O(10,000) days or 30 years!

So OK, don't use RC4 with mandatory TLS in submission.  Otherwise,
with opportunistic TLS SMTP is IIRC insensitive to CRIME, BEAST,
LUCKY13, ... all or most of which rely on browser-specific chosen
plaintext injection.

For opportunistic TLS it makes a lot more sense to say that
implementations and configurations should only use weak algorithms
as a last resort (low in the handshake preference order) than to
say "MUST NOT", which just leads to unnecessary cleartext fallback.

Notice for example, that with SMTP export ciphers are essentially
never used, even though they are not disabled.  They are simply
never negotiated.  We can get to the same state with RC4, without
banning it outright.  (As for Google banning SHA1, that's nice,
but they still to this day rank RC4 first in their outbound SMTP
client).

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Tue, 14 Oct 2014 20:04:01 +0200

> need to be made at least context sensitive, or else less strongly.

I did not claim that SSLv3 is worse than cleartext. My claim is:
it's not sufficently secure in 2014. And I still think I'm right,
even for opportunistic use cases.

> sent, which at O(100) per day is at O(10,000) days or 30 years!

Yes. But you'll agree that most traffic these days is not SMTP but
rather HTTP traffic? Not that SMTP has no impact, it should be
considered in this draft. The second reply I wrote contains two
other attacks against SSLv3/TLS1.0: one generic and the other
directly related to e-mail security (IMAP) where an attacker
is able to sniff passwords.

> LUCKY13, ... all or most of which rely on browser-specific chosen

See above.

> say "MUST NOT", which just leads to unnecessary cleartext fallback.

I see that this is a real problem with MTA/MUA communication. It's
not however with other protocols. Securiting e-mail traffic is
really tricky and might require a seperate WG document or references to
appropriate documents on the web.

Cleartext fallback must not be the case in any scenario where TLS is
trying to be negotiated beween any communicating parties. In my
opinion this - however - does not change the fact that strong
wording is needed to eventually deprecate insecure (or as you
pointed out in the case of SMTP not-so-secure) protocols.

> but they still to this day rank RC4 first in their outbound SMTP

I don't see why this is even necessary? Sure implementations can opt
to ignore RC4, but we're writing a BCP, why should we not warn users
and implementers not to use it anyway? TLS and SSL support so many
different parameters it's a mess to test and configure correctly. If
we can get rid of some ciphersuites - I think we can improve
security and make it easier for administrators to configure their
servers correctly. It's not just about people that write crypto
implementations, TLS stacks and server daemons.

I spent a weekend writing a set of shellscripts that does nothing
other than to compile and negotiate connections between different
OpenSSL versions just to see if there's a possible vulnerability
when selecting a ciphersuite (as with the Mozilla Guide or
bettercrypto.org). To my surprise a cipherstring that works
perfectly for 1.0.1 may include anon-DH ciphers with 0.9.8 etc.
It's simply a mess:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4

More algorithmic agility does not improve security, it makes room
for even more attack vectors - some might be known, others unknown,
even more; implementations break (we've seen that over and over this
year). But I'm no cryptographer, here are slides by DJB on why
agility sucks: http://cr.yp.to/talks/2013.03.12/slides.pdf

Quote:
```
“Cryptographic algorithm agility”:

(1) the pretense that bad crypto is okay if there’s a backup plan +

(2) the pretense that there is in fact a backup plan.

SSL has a crypto switch that in theory allows switching to AES-GCM.
But most SSL software doesn’t support AES-GCM.
The software does support one non-CBC option: RC4.
Now widely recommended, used for 50% of SSL traffic
```

And an IAB draft on said issue:
https://datatracker.ietf.org/doc/draft-iab-crypto-alg-agility/?include_text=1

Quote (4. Security Considerations):
```
[...]

The ability to use a algorithm of one's own choosing is
very desirable; however, this does not mean that any and
all cryptographic algorithms ought to be available in every
implementation. Mandatory-to-implement algorithms ought
to be well studied, giving rise to significant confidence.
In addition, inclusion of too many alternative may add
complexity to algorithm selection or negotiation.

[...]

Support for too many algorithms can lead to implementation
vulnerabilities.  When many algorithms are supported, some
of them will be rarely used.  Any code that is rarely used
can contain undetected bugs, and algorithm implementations
are no different.
```

(Yes. Google SMTP with RC4 pisses me off as well)

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Oct 2014 19:16:46 +0000

> even for opportunistic use cases.

Well, you can't have it both ways.  Opportunistic clients that are
will use cleartext when crypto is not available, need to settle
for whatever crypto they can get, for the alternative *is* cleartext.

I'm not saying SSL 3.0 is motherhood and apple pie, but I am saying
that if SSL 3.0 is all you can get, and refusing to negotiate it
means using cleartext instead, DO NOT refuse to use SSL 3.0.

Opportunistic clients need to be more forgiving in order to get
some security (be it in some use cases sub-optimal) rather than
none.

> is able to sniff passwords.

Same attack.  However, IMAP and submission are not opportunistic.
MTA to MTA is opportunistic, often sends in cleartext, and it is
specifically that use case for which we're discussing whether
the various MUST NOTs are applicable.

Clearly when the alternative is cleartext, and one is looking to
avoid *passive* attacks, SSL 3.0 looks just fine (all attacks are
active) and RC4 only an issue with "AUTH PLAIN" which should
only be used with mandatory TLS.

> appropriate documents on the web.

In which case perhaps let's just admit that the BCP does not apply
to opportunistic TLS, since you and others are keen to avoid making
the appropriate concessions to make the text more broadly applicable,
for (perhaps justified) fear of diluting the message.

> trying to be negotiated beween any communicating parties.

Sorry, with opportunistic security, as my draft carefully explains,
"cleartext" it is not "fallback", rather it is the "baseline"
security posture, and anything better is "gravy".  SMTP is cleartext
by default, and typically reverts to cleartext when STARTTLS is
unavailable or the handshake fails.

> and implementers not to use it anyway?

Because there still exist in sufficient (be it small) numbers
systems that only work with RC4 and for opportunistic TLS, negotiating
RC4 with these is still markedly better than cleartext.  There is
no downside to doing RC4 when cleartext is the alternative.  Provided
of course that one does not use RC4 when stronger options are available.
Thus the idea to de-prioritize rather than ban RC4.

The Postfix default ciphersuite string (please pardon OpenSSL
syntax) is essentially:

	ALL:+RC4:@STRENGTH

which means RC4 is the least preferred 128-bit ciphersuite.  If
and when other implementations do likewise, RC4 disappears from
use.  Once it has not been sighted in years (as is the case with
export ciphers), I'll consider disabling it.

> TLS and SSL support so many

Well "correctly" means different things in different use-cases.
For MTA to MTA opportunistic TLS disabling RC4 and SSL 3.0 is not
correct.  Just this year the Postfix users list has seen reports
of SSL 3.0 only email servers at various banks a user needs to send
mail to.  Should the user's auditor write security findings against
his MTA configuration for leaving SSL 3.0 enabled?  Or should he
be able to use SSL 3.0 which poses no known risks for MTA to MTA
SMTP?

> perfectly for 1.0.1 may include anon-DH ciphers with 0.9.8 etc.

The cipherstring syntax was substantially improved in 1.0.0.  I
can even claim a bit of the credit, as the code by Bodo Moeller
came out of our discussion some years back around various issues
in that space.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 14 Oct 2014 19:36:17 +0000

On Tue, Oct 14, 2014 at 05:59:13PM +0300, Yaron Sheffer wrote:

> I agree we SHOULD tone down a few of the requirements, to make sure we do
> accommodate the opportunistic use case.

Thanks.

> OTOH I agree with Aaron on (for example) still forbidding export-level

Absolutely on board for export-grade ciphers, since they are in
practice no longer in use.  So banning them has no operational impact.

I may not be able to convince Wietse that Postfix should default
to disabling these, but I have no objections to a draft that states
that these MUST NOT be used.

> We all should compromise a little bit so that we can have a single BCP for
> both the authenticated and unauthenticated use cases.

Understood.  There is room to state stronger requirements for
mandatory TLS and somewhat more liberal requirements for unauthenticated
opportunistic TLS (already vulnerable to many active attacks).

E.g.:

    * Mandatory TLS MUST NOT use RC4, SSL 3.0, ...

    * Unauthenticated opportunistic TLS MAY only as a last resort,
      when no stronger options are available, negotiate RC4, SSL 3.0, ...

[ Note that when opportunistic DANE TLS determines via appropriate
  TLSA records that the peer is to be authenticated with DANE, the
  applicable requirements are those for mandatory TLS. ]

-- 
	Viktor.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 15 Oct 2014 00:48:34 +0200

> unavailable or the handshake fails.

Yes. And this is - as I mentioned - pretty specific to SMTP. Which I
know is an issue that directly reflects onto your work. But still,
we should not advise that for ANY protocol in the BCP. See below.

> The cipherstring syntax was substantially improved in 1.0.0.
I noticed that during my testing. Actually it finally somewhat
makes sense and seems to parse correctly (or should I say: as the
user intends it to be parsed).

>   applicable requirements are those for mandatory TLS. ]

This makes sense and is something I can agree with. I'd even go so
far as to directly mention protocols instead of just 'opportunistic'
TLS. e.g. 'In the case of SMTP MTA to MTA communication [...]'. The
issue with the 'opportunistic' wording in the IETF is still that
it's not really defined, although we all seem to understand that
we're talking about the same thing. Or is there a document I missed?

Anyway. Splitting parts of the document for 'opportunistic'/protocol
specific makes sense, I agree. My hope is that this does not make
the document confusing to readers - splitting this into two
documents would be even more aweful.

Thanks for the discussion,
Aaron

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Tue, 14 Oct 2014 22:52:58 +0000

Guys,
These are hardly editorial changes, so we need to resolve them ASAP and have a new version ready.
Please, see below,
Orit.

> > accommodate the opportunistic use case.
It would be unfortunate to simply tone the recommendations down and lose the edge of the whole BCP.
> opportunistic TLS (already vulnerable to many active attacks).
Victor, could you, please, make a list of ALL places, where the current wording might not work for opportunistic deployments? Then, instead of specifying what the different recommendations for "O" might be,  let's add
"with the exception of deployments using TLS opportunistically (see discussion in Section XXX of this document)."
A separate "O" document can discuss different cases with their implications in more details.

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 15 Oct 2014 00:54:03 +0200

So,.. word is out, it's another padding oracle attack combined with
SSLv3 downgrade. Pretty much what I was expecting:

http://googleonlinesecurity.blogspot.ru/2014/10/this-poodle-bites-exploiting-ssl-30.html
https://www.openssl.org/~bodo/ssl-poodle.pdf

Quote:
```
In the coming months, we hope to remove support for SSL 3.0
completely from our client products.
```

Well,.. Google seems to agree with my sentiment :)

Aaron

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 15 Oct 2014 03:01:23 +0000

> the edge of the whole BCP.

I agree, I'd prefer to qualify the recommendations in such a way
that the various MUST NOTs continue to apply to authenticated TLS
connections that are expected to resist active attacks.

When TLS is used in a manner that protects only against passive
attacks and is vulnerable to many more active attacks than just
those addressed by the BCP, the requirement can be softened to
using the weaker algorithms only as a last resort, choosing stronger
options whenever possible.  Such clients MAY employ weaker algorithms
only when they might otherwise resort to cleartext if no shared
algorithms are negotiated.

[ Of course even if a TLS client carefully arranges to list weaker
  algorithms at a low preference, a non-compliant server might
  preempt the client's preference and specifically select the weaker
  option, even though it supports stronger options.  There's not
  much we can do about that, servers need to also adopt the BCP
  recommendations. ]

> Victor, could you, please, make a list of ALL places, where the current
> wording might not work for opportunistic deployments?

Sure, I'll post a separate message with detailed comments.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 15 Oct 2014 05:33:10 +0000

* Section 2.1 first bullet below first paragraph:

  With unauthenticated opportunistic TLS this is not attainable.

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

  Confidentially protection is attained only against passive
  monitoring.  Indeed with a "baseline" security of cleartext,
  opportunistic applications may send cleartext when encryption
  does not appear to be supported by the peer.  So the above applies
  only for peers for which encryption happens to be possible.

* Section 2.1, 3rd bullet below first paragraph:

 Quote:

      Authentication: this means that an end-point of the TLS
      communication is authenticated as the intended entity to
      communicate with.  TLS allows to authenticate one or both end-
      points in the communication.  Some TLS usage scenarios do not
      require authentication, and are further discussed in Section 2.2.

  Not sure whether my comment on the above is in scope for the BCP,
  but the subtler aspects of mutual authentication in TLS are not
  widely understood, and perhaps ought to be more widely disseminated.

  One might think that mutual authentication in TLS is essentially
  agnostic about who authenticates whom and that active attack
  prevention can be attained via authentication of either the server
  or the client.  This naive view is not correct.

  When a server provides a public service open to all (accepting
  email for a domain, a free search service, ...) authentication
  of the server by the client is required and sufficient to provide
  the channel security necessary to assure the client that its
  access to the public service is not subject to active attacks.
  Any authentication of the client by the server in this context
  is no substitute for authentication of the server by the client.
  In fact clients of public services may prefer to remain anonymous.

  Thus, while in some cases (local policy, DANE, ...) a sending
  MTA may elect to authenticate the next-hop MX host, the authentication
  of sending MTAs by MX hosts plays no role in protecting the
  transmission channel and has rather limited potential utility.

  On the other hand, when a server supports the establishment of
  a bi-directional messaging channel (say XMPP) or provides access
  to confidential data available exclusively to a client or set of
  clients, then authentication of the client is needed to assure
  the server that it is initiating new messages or making data
  available to the right client.  In such cases it is not enough
  for the client to authenticate the server, the server needs to
  also authenticate the client (whether through TLS client certs,
  or some application-layer mechanism ideally channel-bound to the
  TLS connection).

  Is discussion of this topic in scope?

* Section 2.1, 3rd paragraph below initial bullet points:

  As before, this seems unclear:

      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.

   Is this talking about integrity in the AEAD sense (protection
   against modification by a party other than one with whom the
   handshake took place), or in the sense of handshake authentication
   to ensure that the key exchange took place with the right party?

* Section 2.2, paragraph 1, please update DANE SMTP draft reference.

      draft-ietf-dane-smtp-with-dane

* Section 2.2, paragraph 2, please reference

      draft-dukhovni-opportunistic-security

* Section 4.1.1, SSL 2.0 "MUST NOT":

  This is fine even for opportunistic TLS.  Clients and servers
  that support only SSL 2.0 are exceedingly rare now.  In Postfix
  SSL 2.0 is disabled in the opportunistic client (no SMTP servers
  are v2 only), but for now still enabled in the opportunistic SMTP
  server (i.e. port 25, but not 587 where TLS is mandatory).  We
  surely would not break any extant SMTP clients by disabling SSL
  2.0 also in servers, though given that the server happily accepts
  cleartext, the case for doing so is not compelling.

  If some auditor pressures users to disable said server support,
  nothing bad happens, no interesting traffic goes in the clear
  instead.

* Section 4.1.1, SSL 3.0 "MUST NOT", TLS 1.0 SHOULD NOT.

  This on the other hand is too strong for opportunistic TLS.  Even
  SSL 3.0 is better than cleartext.  We can say that opportunistic
  TLS clients that would otherwise resort to cleartext transmission
  MUST support at least TLS 1.1, so that older/weaker protocol
  versions are negotiated only with servers that don't support TLS
  1.1.  However they MAY offer to negotiate TLS 1.0 and perhaps
  SSL 3.0.

  It should also be noted the the TLS protocol does not give clients
  the option to advertise arbitrary combinations of protocol versions.
  The set of supported protocol versions must be a contiguous range,
  with the client sending just the minimum and maximum supported versions.

  Thus a client cannot, for example, disable just TLS 1.0, while
  leaving SSL 3.0 and TLS 1.1 enabled.  Users need to be careful
  to make sure that the disabled protocols start with SSL 2.0 and
  continue to some highest disabled protocol version, with all
  remaining protocols enabled.

  OpenSSL, for example, will support the first not-disabled protocol,
  up to, but not including, the first disabled protocol after that.
  Thus disabling SSL 2.0 and TLS 1.0, leaves SSL 3.0 enabled which
  means that TLS 1.1 and TLS 1.2 are also disabled, and the client
  ends up supporting *only* SSL 3.0.  Avoid "holes" in the set
  of disabled protocol versions!

* Section 4.1.1, MUST offer to negotiate TLS 1.2:

  I appreciate the need to move forward to 1.2 and some day to 1.3.

  I am concerned about the manifold issues with TLS 1.2 interoperability.
  Users will continue to disable 1.2 in various cases for some
  time.  Can there be any wiggle-room here to disable TLS 1.2 for
  selected peers where 1.2 is determined to run into problems?

* Section 4.1.3, protocol fallback.

  While I'm not aware of any opportunistic TLS implementations that
  do protocol fallback (rather than just fallback to cleartext when
  handshakes fail), perhaps some exist.  For consistency, banning
  SSL 3.0 seems too strong if the alternative is cleartext.  Ideally,
  they should try fallback with a range of 3.0--3.2 (TLS 1.1) if
  1.2 fails.  I am not aware of significant interop issues with 1.1.
  They will then use 3.0 only when nothing else is an option.

*  Section 4.2 "Strict TLS":

   Quote:

      In many application protocols, clients can be configured to
      use TLS even if the server has not advertised that TLS is
      mandatory or even supported (e.g., this is often the
      case in messaging protocols such as IMAP and XMPP).
      Application clients SHOULD use TLS by default, and disable
      this default only through explicit configuration by the user.

    Some user-agent applications contact a small fixed set of peers
    (often just one submission, IMAP or XMPP server).  For these,
    defaulting to TLS and requiring user action to use cleartext
    is reasonable.

    Other applications (MTAs, XMPP infrastructure servers, ...)
    potentially contact similar servers in any domain on the
    Internet.  They cannot default to TLS on, until TLS adoption
    by peers is universal.  They MUST operate opportunistically,
    and determine peer by peer which peers support TLS and which
    do not.  The above advice is based on familiarity with just
    the first class of applications.

    Is the "SHOULD" meant to provide sufficient wiggle-room to
    allow SMTP and XMPP relays to be out of scope?  Or should the
    advice be a bit more specific?

*  Section 4.4 Resumption:

   Quote:

       If TLS session resumption is used, care ought to be taken
       to do so safely.  In particular, when using session tickets
       [RFC5077], the resumption information MUST be authenticated
       and encrypted to prevent modification or eavesdropping by
       an attacker.  Further recommendations apply to session
       tickets:

   Not sure what "authenticated" is intended to mean here.  RFC
   5077 recommends an encrypt + MAC ticket encoding.  Why does this
   BCP need to comment on ticket encoding security?  This is rarely
   an application issue, I would expect ticket encoding/decoding
   support to be provided by TLS toolkits, not application code.

   The chief interaction between applications and session tickets
   is key management, when the same session needs to work with a
   cluster of hosts.  So I thin the BCP should restrict its attention
   to the key management issues, which are not IIRC addressed in
   5077.

   For example, Postfix has code to provide OpenSSL with the relevant
   session ticket encryption/decryption keys (which Postfix rotates
   by default hourly), but the underlying encoding details are
   handled by the OpenSSL library.

* Section 4.6 SNI.

  Consensus: Clients that do know a primary DNS reference identifier
  for a server, and will use it to authenticate that server, MUST
  send SNI.  This includes, for example, "opportunistic DANE TLS"
  clients that are expected to use the TLSA base domain in this
  capacity.  [ If "opportunistic DANE TLS" is too bleeding edge a
  notion for this draft, the example can be safely skipped. ]

  However: As I posted previously.  Not all clients know what to send in
  SNI and SNI could lead to server connection drops if servers
  react poorly to names for which don't have explicitly configured
  certificates.  With unauthenticated TLS, the client ignores the
  server certificate anyway, so there is nothing to be gained by
  sending SNI (in fact this avoids a data leakage in the clear).

  So I would so far as to say that SNI is NOT RECOMMENDED for
  unauthenticated TLS.

  On the server side, there is simply no requirement to support
  SNI when the server is not doing any "virtual hosting".  So server
  side SNI support is optional.

  Servers supporting opportunistic clients SHOULD tolerate SNI
  requests that don't corresponding to any particular server
  certificate, and just respond with some appropriate choice of
  "default" or "closest match" certificate.

* Section, 5.1, MUST NOT RC4.

  Compromise: OK as MUST NOT for mandatory TLS.

  No surprise to anyone, I think this is too strong for opportunistic
  TLS where cleartext might otherwise result if RC4 is excluded.
  RC4 has been the most performant (absent hardware AES support
  which is relatively new still) cipher for many applications until
  very recently.  Also with some of the CBC attacks even more users
  moved to RC4.

  Thus RC4 is widely used, preferred, and is the sole working
  cipher suite on a non-negligible if small fraction of servers.
  Thus for opportunistic TLS it is (for now) premature IMHO to ban
  RC4.  I'd like to see it substantially fade from use (like export
  ciphers) before it is made MUST NOT.

* Section 5.1 (<128 bit text):

  See comment upstream.

* Section 5.5 (DH cipher suites) ranking:

  Quote:

    * Elliptic Curve DHE with negotiated parameters
    * TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 2048-bit Diffie-Hellman parameters
    * TLS_DHE_RSA_WITH_AES_128_GCM_SHA256, with 1024-bit parameters.

  It should be made more clear that the choice between the last
  two is entirely based on server support for either or both.  No
  information is (as noted) available from the client.  Thus servers
  than can send DH 2048-bit parameters SHOULD do so, unless it is
  known that this will cause interoperability issues with a
  non-negligible fraction of clients.

* Section 7.1:

  Update obsolete references as previously noted.  Note that when
  TLS is unauthenticated, the entire question is out of scope.

  Further rules for establishing reference identities may appear
  in application-protocol-specific documents that refine 6125.

  This implies that authentication cannot take place when no secure
  reference identity is known, but does not say it outright.
  Applications where this is an issue must either employ unauthenticated
  TLS or must employ some identifier other than the peer hostname
  (e.g. the MX or SRV input domain used to locate the target host)
  or any explicitly configured identifier that is part of the
  mandatory TLS configuration for the destination.  The right choice
  to be specified in relevant application-specific standards.

* Section 7.5 (Revocation):

  See upstream comment re "forward looking" statements.

-- 
	Viktor.

---

From: Ralph Holz <[email-masked]>
Date: Wed, 15 Oct 2014 12:28:34 +0200

Hi,

> documents would be even more aweful.
At this stage, with exceptions already made for scenarios that do not need
encryption, and some attempts already made to accomodate OE/OS - I have
serious concerns that adding more exceptions, and here even regular ones
for almost every single point!, will lead to a BCP that is horrible to read
and will thus be mostly ignored.

I'd favour a solution where we do not accomodate OE/OS at every turn.
Consider the practical impact and what we want to achieve with this BCP:
the idea is to make the Internet (= mostly HTTP) a safer place. If people
take note of the BCP, and implement the recommendations, even OE/OS would
benefit from it as there is no need to fall back to things like RC4.

If we add exceptions at every turn, however, we will simply lose people who
won't bother with the BCP. I wouldn't.

I know I may be in a minority here. But, to be clear, I favour declaring
OE/OS out of scope and defer it to another document - keep this BCP clear,
simple, and applicable to a still wide range of use cases.

Ralph

---

From: Ralph Holz <[email-masked]>
Date: Wed, 15 Oct 2014 12:30:09 +0200

Hi,

This is a long list of changes, and pretty much exactly why I favour having
OE/OS out of scope.

Ralph

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 15 Oct 2014 20:21:07 +0000

Victor,
Thanks for your thorough review and  feedback.
This has been a fascinating and an educational read for me and has tones of useful information for those who deploy or consider deploying TLS "opportunistically" in its broadest sense.
It seems that I have been under the false assumption that only a couple of recommendations in the draft constrain "O" deployments. So it is very helpful to learn about this now - before the last call.

If the list agrees with Victor's technical assessment of "O" TLS, then I join those who think that it doesn't make much sense to include any of the specific "O" TLS recommendations in the baseline BCP. This deliverable is not intended for audience that use or plan using TCP "opportunistically"... This audience will need to know much more than the "strict TLS" in order to make smart deployment decisions. As we know, all these are in the scope of UTA and deserve separate IDs for "O" TLS and/or per application. (The TLS **implementation** recommendations must not be segmented between the two modes, though.)

Authors, please, use your judgment whether to ask the list the same scope question again or go ahead and suggest your preferred way forward.

Victor, some of your text is not directly related to the opportunistic recommendations. So, if you feel that it will be useful to include these parts or modifications into the BCP, please, submit them in a format suggesting how exactly incorporate them into the -05 version.

Thanks,
Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Viktor Dukhovni
> Sent: Tuesday, October 14, 2014 10:33 PM
> To: [email-masked]
> Subject: [Uta] [uta] TLS BCP -05 detailed comments. draft-ietf-uta-tls-bcp-
> 05.txt
>

---

From: Ralph Holz <[email-masked]>
Date: Wed, 15 Oct 2014 22:41:12 +0200

Hi,

I think that's a great summary, Orit, thanks. I think the way to go would
be to acknowledge in the BCP that a document for O-TLS is coming. While
implementations should thus retain the "old" algorithms needed for O-TLS,
deployments for strict TLS should not. We can have a look at how that could
be best built into the BCP, if the list agrees.

Ralph

On 15 October 2014 22:21, Orit Levin (LCA) <[email-masked]> wrote:

> This has been a fascinating and an educational read for me and has tones
> of useful information for those who deploy or consider deploying TLS
> "opportunistically" in its broadest sense.
> It seems that I have been under the false assumption that only a couple of
> recommendations in the draft constrain "O" deployments. So it is very
> helpful to learn about this now - before the last call.
>
> If the list agrees with Victor's technical assessment of "O" TLS, then I
> join those who think that it doesn't make much sense to include any of the
> specific "O" TLS recommendations in the baseline BCP. This deliverable is
> not intended for audience that use or plan using TCP "opportunistically"...
> This audience will need to know much more than the "strict TLS" in order to
> make smart deployment decisions. As we know, all these are in the scope of
> UTA and deserve separate IDs for "O" TLS and/or per application. (The TLS
> **implementation** recommendations must not be segmented between the two
> modes, though.)
>
> Authors, please, use your judgment whether to ask the list the same scope
> question again or go ahead and suggest your preferred way forward.
>
> Victor, some of your text is not directly related to the opportunistic
> recommendations. So, if you feel that it will be useful to include these
> parts or modifications into the BCP, please, submit them in a format
> suggesting how exactly incorporate them into the -05 version.
>
> Thanks,
> Orit.
>

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Oct 2014 22:27:57 +0100

On 15/10/14 21:21, Orit Levin (LCA) wrote:
> If the list agrees with Victor's technical assessment of "O" TLS,
> then I join those who think that it doesn't make much sense to
> include any of the specific "O" TLS recommendations in the baseline
> BCP.

Apologies, I've not read Viktor's comments in detail but I do
think the above is correct. My reasoning is that since we're not
yet done with the definitional draft for OS, it'd be premature
to start writing BCP text for OS. I do accept that some few
folks (incl. Viktor) have real experience with OS for SMTP/STARTTLS
but I also think we might be better off to punt on BCP text for
OS for a while nonetheless.

Cheers,
S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 15 Oct 2014 22:42:43 +0000

> suggesting how exactly incorporate them into the -05 version.

I am inclined to leave the "how" the authors if they agree with
the comment.  The comments that are not specific to opportunistic
TLS are repeated below.

> >     advice be a bit more specific?

The quoted paragraph seems to overlap with the opportunistic space.
The requirment to use TLS "by default" needs a somewhat narrower
scope, something like:

    User-agent configurations for statically configured connections
    to services that support both TLS and cleartext SHOULD use TLS
    "by default".

> >   to be specified in relevant application-specific standards.

I think the above clarification is needed especially for mandatory TLS.

> >   See upstream comment re "forward looking" statements.

Not strictly about opportunistic.  Really about whether discussion of
future revocation alternatives is in scope for a BCP.  And if so, which
ones (for example, BCP alternatives to revocation when using DANE?).

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Thu, 16 Oct 2014 19:53:37 -0600

> ones (for example, BCP alternatives to revocation when using DANE?).

It seems to me that, by definition, the future cannot be helpfully 
discussed in a Best *Current* Practice document. The most we can do is 
point to some possible directions of future trends that might have an 
impact on the scope and applicability of the BCP. However, my preference 
would be to let the future take care of itself: I'm sure that folks will 
see fit to update the BCP as threats and technologies change over the 
next few years. Better to get recommendations out quickly and make it 
easy for people to ship documents that update or obsolete this one.

Ship and iterate!

Peter

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Sat, 18 Oct 2014 01:14:29 +0000

On Thu, Oct 16, 2014 at 07:53:37PM -0600, Peter Saint-Andre - &yet wrote:

> It seems to me that, by definition, the future cannot be helpfully discussed
> in a Best *Current* Practice document. The most we can do is point to some
> possible directions of future trends that might have an impact on the scope
> and applicability of the BCP. However, my preference would be to let the
> future take care of itself: I'm sure that folks will see fit to update the
> BCP as threats and technologies change over the next few years. Better to
> get recommendations out quickly and make it easy for people to ship
> documents that update or obsolete this one.

I agree, which is I was somewhat surprised by the "speculative" text
about potential future revocation approaches.  The DANE (avoiding
revocation entirely) approach is at least something one can do now,
on a small scale since most domains are unsigned.  The text talks
about things which can't be practiced at all as yet.

-- 
	Viktor.

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 21 Oct 2014 19:53:59 -0600

> about things which can't be practiced at all as yet.

Then I suggest that we rip out most of the future-oriented statements. 
Viktor, which ones did you find objectionable?

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 21 Oct 2014 19:56:35 -0600

> OS for a while nonetheless.

I suggest that we put Viktor to work on a document about "opportunistic" 
(I still prefer the term "unauthenticated") encryption if he feels that 
a more general document is needed.

The initial UTA BCP was supposed to be a quick win for authenticated 
encryption with TLS. All this discussion of OE/UE is distracting us from 
that goal.

An OE/UE BCP can quite easily update the "AE" BCP if the WG decides 
that's appropriate.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 21 Oct 2014 20:13:11 -0600

>      https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12

Noted.

> "must staple" signals,

The current text does not exactly mandate support for OCSP stapling, and 
in fact says that there is no standardized solution here. But we can 
probably remove that paragraph.

... and thus perhaps other "forward looking
> statements" might not be out of place.

Are there any other forward-looking statements in the document?

> Comments on particular text:

We really have no idea, do we? "At least several" doesn't seem 
problematic to me. But this is all speculation.

> And in particular the "MUST NOT" for RC4 is also inapplicable with

Please save that for the OE BCP.

> MUST is too strong IMHO.

Do you think that MUST implement is too strong for TLS implementations? 
We're not talking about implementations of application protocols here.

> If the client is using opportunistic TLS

Something for the OE BCP.

> infer a server reference identifier (the TLSA base domain).

Again, we're talking about TLS implementations, not application protocol 
implementations.

> and SHOULD NOT TLS 1.0 are too strong.

Another great point for the OE BCP you're writing. ;-)

> a conflict with keeping opportunistic TLS in scope.

I think we're talking about integrity protection of the data stream, but 
I will check that with my co-authors.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 21 Oct 2014 20:20:15 -0600

>> accommodate the opportunistic use case.

I would rather throw out the opportunistic use case completely than dumb 
down this BCP.

> practice no longer in use.  So banning them has no operational impact.

That's an awfully low bar for a BCP: ban things that have no operational 
impact.

> opportunistic TLS (already vulnerable to many active attacks).

It is possible that we can do that, but Viktor your very long and 
detailed messages about the opportunistic use case are difficult to 
absorb and then incorporate into the base BCP. Speaking as an author of 
draft-ietf-uta-tls-bcp, I would much prefer that you write a very 
thorough OE/OS BCP in the way that only you can do, rather than try to 
address every point that you raise in these long email threads.

Quick win!

>    applicable requirements are those for mandatory TLS. ]

IMHO DANE is out of scope for this document. It's forward-looking and is 
being address by the DANE WG.

Future documents (OE/OS, DANE, etc.) can always update the base BCP for 
TLS+PKI.

If we don't scope this work carefully, we'll never finish.

Peter

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

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Tue, 21 Oct 2014 20:21:14 -0600

On 10/15/14, 4:28 AM, Ralph Holz wrote:
> At this stage, with exceptions already made for scenarios that do not
> need encryption, and some attempts already made to accomodate OE/OS - I
> have serious concerns that adding more exceptions, and here even regular
> ones for almost every single point!, will lead to a BCP that is horrible
> to read and will thus be mostly ignored.

I totally agree.

> the idea is to make the Internet (= mostly HTTP) a safer place. If
> people take note of the BCP, and implement the recommendations, even
> OE/OS would benefit from it as there is no need to fall back to things
> like RC4.
>
> If we add exceptions at every turn, however, we will simply lose people
> who won't bother with the BCP. I wouldn't.
>
> OE/OS out of scope and defer it to another document - keep this BCP
> clear, simple, and applicable to a still wide range of use cases.

A big +1.

Peter

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Oct 2014 02:47:36 +0000

> encryption with TLS. All this discussion of OE/UE is distracting us from

It was only mentioned because the document asserted SMTP and XMPP
in scope, without leaving wiggle-room to opt-out the server to
server cases.

It is sufficient for the document to explicitly disclaim applicability
to opportunistic TLS, possibly mentioning SMTP and XMPP (server to
server) as the canonical examples.

Before we consider a new BCP for opportunistic TLS, I'd like to
see the base opportunistic security informational draft become a
published RFC, and ideally also the SMTP with DANE draft.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 21 Oct 2014 22:51:03 -0400

> > I know I may be in a minority here. But, to be clear, I favour
> > declaring OE/OS out of scope and defer it to another document - keep
> > this BCP clear, simple, and applicable to a still wide range of use cases.
> 
> A big +1.

Ditto!

---

From: t.p. <[email-masked]>
Date: Wed, 22 Oct 2014 09:53:41 +0100

----- Original Message -----
From: "Salz, Rich" <[email-masked]>
To: "Peter Saint-Andre - &yet" <[email-masked]>; "Ralph Holz"
<[email-masked]>; "Aaron Zauner" <[email-masked]>
Cc: <[email-masked]>; "Viktor Dukhovni" <[email-masked]>
Sent: Wednesday, October 22, 2014 3:51 AM
> > > this BCP clear, simple, and applicable to a still wide range of
use cases.

Count me in that minority too.  Unauthenticated/Opportunistic is a
potential can of worms that can only delay or detract from the benefits
that this I-D will bring.

Tom Petch

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Oct 2014 11:20:05 +0100

> that this I-D will bring.

FWIW, I also agree that this BCP ought not address OS, but I
very much disagree with the "can of worms" tone. But we will
need to debate the pros and cons of OS later on in various
contexts so I hope folks don't get into it right now. Let's
get this BCP done and out the door.

S.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 22 Oct 2014 11:53:16 +0100

On 22/10/2014 03:20, Peter Saint-Andre - &yet wrote:
> I would rather throw out the opportunistic use case completely than 
> dumb down this BCP.
+1.
> That's an awfully low bar for a BCP: ban things that have no 
> operational impact.
>
> absorb and then incorporate into the base BCP. Speaking as an author 
> of draft-ietf-uta-tls-bcp, I would much prefer that you write a very 
> IMHO DANE is out of scope for this document. It's forward-looking and 
> is being address by the DANE WG.
>
> Future documents (OE/OS, DANE, etc.) can always update the base BCP 
> for TLS+PKI.
>
I agree with you. OE/OS turned out to be more nuanced that I originally 
thought, so my current preference is to explicitly declare it 
out-of-scope for draft-ietf-uta-tls-bcp and get draft-ietf-uta-tls-bcp 
published as a BCP soon. OE/OS can be done in another document.

---

From: Bodo Moeller <[email-masked]>
Date: Wed, 22 Oct 2014 13:32:18 +0200

The recurring theme regarding Opportunistic Encryption, unsurprisingly,
appears to be that Best Current Practices can't always be enforced, because
Mediocre Legacy Practices may be required for interoperability and still be
better than nothing. So certainly for a BCP document, it appears to make
the most sense to say that such OE use cases are out of scope.

I think it can still be useful to state that implementations going for OE
should adhere to BCP whenever possible. The BCP document shouldn't go into
the details (e.g., it's not the right place to put down a ranking of
non-BCP cipher suites), but I think that mentioning some basic ideas
non-normatively could still be useful. (Notably, clients and servers should
prefer BCP-compliant cipher suites over legacy cipher suites.)

Bodo

---

From: Manuel Pégourié-Gonnard <[email-masked]>
Date: Wed, 22 Oct 2014 15:14:07 +0200

>>> this BCP clear, simple, and applicable to a still wide range of use cases.
++

Manuel.

---

From: ⌘ Matt Miller <[email-masked]>
Date: Wed, 22 Oct 2014 08:00:25 -0600

On 10/21/14, 8:21 PM, Peter Saint-Andre - &yet wrote:
>> declaring OE/OS out of scope and defer it to another document -
>> keep this BCP clear, simple, and applicable to a still wide range
>> of use cases.
> 
> A big +1.
> 
> Peter
> 

+1

- -- 
- - m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Oct 2014 08:49:27 -0700

> get this BCP done and out the door.

I strongly disagree with not addressing OE here. This BCP has one shot at getting attention, and ignoring OE now makes it look like OE is still not ready to be addressed. Let's not miss the opportunity to say "TLS works great with full authentication (here's how) and works great in opportunistic mode (here's how)".

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 22 Oct 2014 17:24:16 +0100

On 22/10/14 16:49, Paul Hoffman wrote:
> I strongly disagree with not addressing OE here. This BCP has one
> shot at getting attention, and ignoring OE now makes it look like OE
> is still not ready to be addressed. Let's not miss the opportunity to
> say "TLS works great with full authentication (here's how) and works
> great in opportunistic mode (here's how)".

That's entirely defensible but fwiw I disagree myself, and I
think equally (or more:-) defensibly.

I don't think that BCP-like text for OS is as easy to get done
is you seem to believe and I also think this WG has been a year
on the go already and it's past time to get the basic BCP out.

S.

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 22 Oct 2014 19:27:40 +0300

> on the go already and it's past time to get the basic BCP out.

I agree with Stephen. I don't think we have enough OE practitioners "in 
the room" to reach consensus, and publishing the BCP ASAP is way more 
important than reaching closure on OE best practices.

Thanks,
	Yaron

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 22 Oct 2014 19:52:54 +0300

> I will check that with my co-authors.

Yes, this is why we talk about *data* integrity protection on the first 
line.

Thanks,
	Yaron

---

From: Ralph Holz <[email-masked]>
Date: Wed, 22 Oct 2014 21:51:04 +0200

Seconded.