Subject: [saag] new terminology ID posted

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Apr 2014 11:59:02 -0400

revised as per SAAG discussion and directions from Stephen Farrell:

https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/

Steve

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 01 Apr 2014 17:36:46 +0100

Thanks Steve,

> https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/

Good job. Modulo some wordsmithing, I think this is good enough
to go on with.

I'd like to AD sponsor this as an informational RFC after
we've thrashed about a bit on that wordsmithing, if there
seems to be rough consensus for that.

Does that sound like a good (enough!) plan to folks?

*Please* note I'm asking if this is *good enough* plan
not whether the document will be perfect after wordsmithing.

Ideally, I'd like to see responses like:

a) "go for it, and here are my editorial comments," or,

b) "go for it, sorry no time for comments right now" (note:
more (a)'s than (b)'s is better, a (b) is useful if you
commented before maybe), or,

c) "Don't do it, and here's why" with a link to whichever
mail in the archive makes your point (its probably there
already:-), or, if you really must,

d) a mail that succinctly makes a new point as to why to
not do this at all.

Also: let's try control ourselves and not follow up on
everything in nit-picking style, if we do go ahead with
this there's time for that when we know where we're
headed.

If it looks like there're a good set of go-for-it responses
and no real showstoppers then I think we could try for
letting Steve produce a -01 based on the editorial comments
you send to the list (say in the next week or two?) and then
do a sorta-LC here and then an IETF LC (so maybe a -02
will be needed before IETF LC, we'll see).

Thanks,
S.

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

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Apr 2014 16:36:54 +0000

> https://datatracker.ietf.org/doc/draft-kent-opportunistic-security/

Thanks.  A few quick comments.

    - There is not always a user, some applications are non-interactive,
      and so:

      6.   Use of opportunistic security must not introduce human
	   perceptible delays in session/connection establishment, as that
	   will discourage its use.  As a result, authentication and MiTM
	   detection should take place after an encrypted session is
	   established.  This ordering implies that some data may be
	   transmitted prior to authentication or detection of a MiTM.

      is not necessarily applicable.  Even with human users (see below)
      some modes of opportunistic security may be strong enough to make
      MiTM protection worth the wait.

    - With DANE used opportunistically, i.e. only for connections to
      servers that publish usable DNSSEC validated TLSA records,
      and otherwise a fallback to unauthenticated TLS or even
      cleartext, there is in fact MiTM and integrity protection
      when said usable TLSA records are published.  Connections to
      DANE authenticated servers can for many applications be
      considered sufficiently well authenticated to be equivalent
      to cases in which strong authentication was required.

      The difference is that policy about which destinations are
      fully protected is not fixed at the client, rather the policy
      is securely published by some destination systems and applied
      only to those systems that publish such policy (say in form
      of DANE TLSA records).

      It seems that the draft defintion of the the umbrella term
      "opportunistic security" may not extend quite far enough from
      a floor of "better than nothing" a strongly authenticated
      ceiling in cases where strong authentication policy is partly
      published by the server system, and thus from the client's
      perspective is applied only when possible.

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

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 1 Apr 2014 13:45:28 -0400

I just read it, pretty carefully.  Definitely "go for it"; this is a very readable and useful/important document.  A few nits below, most on the level of typo's.

Is this the first time an RFC has used "OUGHT NOT"? :)

I think Victor's concerns about #6 are addressed by saying "if it's two programs talking, it's not human perceptible" Although perhaps some wording making that explicit is a good idea.1

In #7, should OK be OS?  And there's a spurious ">" before Since.

Sec 2 (ever consider a career at the OED? :)  "In fact, it the key management process"  is an is missing there?

In Sec 3 about S/MIME, "so the originator knows" seems a little off; perhaps "can specify" instead of knows?  In the last paragraph "and alternative way" should be "an"  "Lof or TOFU" since they're the same, perhaps the or should become a parenthetical "(also known as"  And I think TOFU is more well-known, even if LoF is more evocative.

In sec 4, "to avoid the term 'anonymous' her" should be "here".And a missing space after the period. Should the reference to RFC2818 also reference 6797?

Sec 5, extra space between (data) and confidentiality.  Shared secret references CEK without any definition.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Apr 2014 17:59:16 +0000

On Tue, Apr 01, 2014 at 01:45:28PM -0400, Salz, Rich wrote:

> I think Victor's concerns about #6 are addressed by saying "if
> it's two programs talking, it's not human perceptible" Although
> perhaps some wording making that explicit is a good idea.1

[ By the way, go for it. ]

Perhaps "human user" is not the key difference.  Some applications
are latency-sensitive, and others latency tolerant.  In latency-
sensitive applications, where opportunistic security is competing
with no security, one should indeed pay attention to the latency
cost, and perhaps be willing to cut corners on round-trips if
stronger authentication means substantially higher latency.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Apr 2014 14:46:43 -0400

Viktor,
>        MiTM protection worth the wait.
I called out human users because in that context perceptible delays may
pose problems wrt adoption. The sense at the STRINT workshop was that, in
general, since these services are invisible, we should strive to make them
painless. That motivates performing MiTM detection and authentication in
parallel, after establishing an encrypted session. I have changed the text
to make it clear that the delay issue is specific to apps with human users.
However, that does not address the rest of your concerns.
>        to cases in which strong authentication was required.
I agree that the example you cite provides very good security, equivalent
or better (given the problems with Web PKI) to an HTTPS connection to a
server. I can re-word #6 to accommodate the example you cited. But, it
is an example that requires the target of a session to publish a DANE 
record.
Thus it may not result in as much encryption as a mechanism which does not
impose that prerequisite. Folks will have to decide if we want to create a
different term for DANE-enabled TLS (and IPsec) sessions, or broaden the
definition of opportunistic security to encompass them. I'm happy to 
generate
text to accommodate whatever folks decide.
>        only to those systems that publish such policy (say in form
I understand.
>        perspective is applied only when possible.

see my comment above re your example.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Apr 2014 14:48:33 -0400

Rich,

Thanks for the comments and for spotting the typos.
> Is this the first time an RFC has used "OUGHT NOT"? :)
see RFC 6919 :-).
> I think Victor's concerns about #6 are addressed by saying "if it's two programs talking, it's not human perceptible" Although perhaps some wording making that explicit is a good idea.
two apps may not be as sensitive to delays as people, hence my choice of 
terms. I've
replied to Viktor separately, as the issue he raised is based on issues 
other than
human vs. machine "users".
> In #7, should OK be OS?  And there's a spurious ">" before Since.
fixed.
> Sec 2 (ever consider a career at the OED? :)
I am someone who knows when to use fewer vs. less, that vs. which, etc. :-)
>   "In fact, it the key management process"  is an is missing there?
fixed.
> In Sec 3 about S/MIME, "so the originator knows" seems a little off; perhaps "can specify" instead of knows?  In the last paragraph "and alternative way" should be "an"  "Lof or TOFU" since they're…
fixed, and fixed.
> In sec 4, "to avoid the term 'anonymous' her" should be "here".And a missing space after the period. Should the reference to RFC2818 also reference 6797?
fixed.
> Sec 5, extra space between (data) and confidentiality.  Shared secret references CEK without any definition.
fixed.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Apr 2014 19:26:03 +0000

On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote:

> generate text to accommodate whatever folks decide.

I was hoping that "opportunistic DANE TLS" (the proposed terminology
for this type of security policy in the DANE SMTP draft) will fit
under the broad "umbrella term" of "opportunistic security".

In other words "opportunistic security" has no explicit floor or
ceiling.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 01 Apr 2014 15:49:21 -0400

Viktor,

> ...
I'm not saying it won't. That's not for me to decide. We are
still working on the text.
> In other words "opportunistic security" has no explicit floor or
I disagree on this point. If there is no floor, then doing nothing
could count, and that doesn't make sense to me. We have existing security
mechanisms that may yield better security than OS, so they should not
be encompassed by the term, hence there ought to be a ceiling as well.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 1 Apr 2014 19:55:29 +0000

> be encompassed by the term, hence there ought to be a ceiling as well.

Sorry, agreed about not encompassing mandatory non-opportunistic
cases.  I meant no floor or ceiling on the actual security achieved
for a given connection.  It may be none, it may be as strong or
stronger than traditional PKIX.  The difference is that the security
achieved is roughly the best possible under the circumstances (though
DANE may resist downgrade attacks).

Given that there's no real confusion about the points made, I think
that's all on this subject from me for now.

-- 
	Viktor.

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 3 Apr 2014 15:59:45 +0300

> a) "go for it, and here are my editorial comments," or,

I would say "go for it"...

and here is my comments to it:
----------------------------------------------------------------------
In 3) in Section 1 there is reference to IKE but the RFC points to the
TLS 1.0:

       passive wiretapping.  IKE [RFC2246] has offered this capability,
       	       		     	  ^^^^^^^
       though it does not appear to be commonly used.)

This should be RFC5996 (and this is why I like much better to use
refences in style of [IKEv2] than [RFC5996]).

--

In section 2 we should refer to IKEv2 not IKE first, as RFC2409 is
obsoleted by RFC5996:

   Opportunistic encryption still calls for each party to identify the
   other, using IKE [RFC2409] (equivalently, IKE v2 [RFC5996])
   authentication mechanisms, so it is not an unauthenticated key
   management approach.  ....

i.e change "using IKE [RFC2409] (equivalently, IKE v2 [RFC5996])" to
"using IKEv2 [RFC5996] (equivalently, IKEv1 [RFC2409])"

--

In section 3 it says that TLS uses LoF or TOFU for the client
authentication, but I do not think that is true:

		      	     	   TLS normally affords server
   authentication (based on X.509 certificates and the so-called Web
   PKI), and offers optional support for client authentication based on
   a leap of faith (LoF) or trust on first use (TOFU) approach.  Because
   SSH is most often employed in an enterprise context, reliance on
   these initial authentication mechanisms represents a reasonable risk-
   based design tradeoff.

Both LoF and TOFU quite often do require user interface i.e user to be
able to notified if the certificate changes or whether this is new
connection. When doing TLS *CLIENT* authentication the server does not
have user at all, so using LoF or TOFU there would be hard.

I would say that in TLS the client authentication is commonly not done
at all inside the TLS, but it is done after the connection to the
server is done in a form of user name and password or similar
non-cryptographic ways.

The next paragraph talks about SSH, but even in SSH it does not use
LoF or TOFU on the *CLIENT* authentication. SSH commonly uses the
method where the first connection to new server gives a warning saying
this is new connection and user will accept the connection and the key
returned from the other end on the first connection is stored to the
database and checked for all later uses. If key is changed then user
is given again a warning asking what to do (connect anyways, connect
and change the key in database, or do not connect). All of this is
done on the server authentication not client authentication.

There is no CLIENT authentication in the SSH, there is USER
authentication which usually will require server and client to share
some kind of bilateral arrangement (store the password to the server
side database, or store the user's public key to the authorized keys
file on the server etc), and this user authentication is run after the
server authentication has finished.

As the next paragraph talks about the TLS, I assume the first
paragraph was supposed to talk only about SSH, i.e. the first TLS was
typo.

BTW, I myself have categorized the different generic IETF security
protocols as follows:

+---------------+-----------------------+---------------------+
|		| Bilateral		| Unilateral          |
|		| agreement  		| or no		      |
|		| between		| agreement	      |
|		| peers			| between peers	      |
+---------------+-----------------------+---------------------+
| Above TCP	| SSH			| TLS		      |
| i.e. usually	|			| 		      |
| implementable	|			|		      |
| in usermode	|			|		      |
|    		|			|		      |
| Asymmetric	|			|		      |
| authentication|			|		      |
+---------------+-----------------------+---------------------+
| Below TCP	| IKE			| HIP		      |
| i.e. usually	|			|		      |
| do require	|			|		      |
| kernel change	|			|		      |
|    		|			|		      |
| Symmetric	|			|		      |
| authentication|			|		      |
+---------------+-----------------------+---------------------+

Of course TLS with client authentication will require bilateral
agreement, and also if you use TLS with username + password
authentication over HTTP or similar that will require bilateral
agreement.

On the other hand Opportunistic Encryption in IPsec does not require
bilater agreement, i.e it moves to the same box than HIP. I.e. the
uses for the protocols are not that clear, but that gives at least in
my understanding the basic idea where the protocol was designed for
and/or what is the main use for it now.

The bilateral agreement makes it harder to get it used everywhere.
Unilateral or no-agreement are much easier in that sense (usable
everywhere). Whether the protocol can be implemented in the usermode
(or inside application) that makes it much easier to get it deployed
everywhere. Requiring access to parts below TCP stack usually requires
kernel modification or at least special credentials which makes it
much harder to deploy the protocol everywhere.

Symmetric authentication is more suitable in peer to peer connection,
compared to the asymmetric authentication where the protocol is more
suitable for client (with user) and server uses.

--

In section 4 you have reference to the RFC4306 (IKEv2), which should
be replaced with RFC5996 (latest version of IKEv2).

Also there is text saying:

   Finally, we avoid using the term "unauthenticated
   encryption" because "authenticated encryption" is a well-defined term
   in the crypto community.  Instead we use the term "authenticated
   encrypted communication".

Is this text correct? You say we avoid using therm "unauthenticatged
encryption" but use "authenticated encrypted communication" instead? I
would assume both of them should either say "unauthenticated" or
"authenticated", i.e. change the text to say '... term "unauthenticated
encrypted communication".'
-- 
[email-masked]

---

From: Stephen Kent <[email-masked]>
Date: Fri, 04 Apr 2014 10:23:04 -0400

Tero,

Thanks for your comments. Responses inline below.

> and here is my comments to it:
I've been working with two colleagues here at BBN to do the edits and 
some errors
have crept in via that interaction. We've fixed this reference to point 
to IKEv2.
At this stage I am loathe to change the reference style throughout the 
doc, but when
we near the end we can revisit that decision.
fixed.
another editing whoops that we have fixed.
> have user at all, so using LoF or TOFU there would be hard.
absolutely correct.
> server is done in a form of user name and password or similar
agreed.
> done on the server authentication not client authentication.
yes. I have revised the text here to make clear that TOFU/LoF applies
to server, not client, auth.
> server authentication has finished.
I have added some text to better describe SSH user auth. Let me
know if the text in the next rev suffices.
> paragraph was supposed to talk only about SSH, i.e. the first TLS was
Actually, it was the other way around, but because text was mashed
together in the course of making revisions, the result was just a mess.
> BTW, I myself have categorized the different generic IETF security
Nice diagram. I'll have to see if we can make use of it, or a similar
version in the future.
> authentication over HTTP or similar that will require bilateral
agreed, but when one uses a password with TLS it's not part of TLS
anymore, it's the app above TLS. I want to address intrinsic properties
of the protocols, as specified and as commonly used, in this doc.
> and/or what is the main use for it now.
agreed. do you think we need to include more text about this?
> much harder to deploy the protocol everywhere.
yes, bilateral, a priori agreement requirements are clearly an impediment to
deployment, and thus should be avoided when one is trying to maximize use
of encryption. (Gee, I guess I should find a place to say that :-) in 
the doc.)

Also, changes to kernel code are another impediment to deployment, at least
in terms of rate of uptake. (The recent comments about how many copies 
of XP are
still in use should be a lesson for us re OS-based changes.)
> suitable for client (with user) and server uses.
I'll have to think about that. IPsec is p-t-p.
fixed.
fixed.

Thanks for all of the comments.

Steve

---

From: Nico Williams <[email-masked]>
Date: Sat, 5 Apr 2014 16:11:30 -0500

On Tue, Apr 01, 2014 at 02:46:43PM -0400, Stephen Kent wrote:
> is an example that requires the target of a session to publish a
> DANE record.

Right: DANE affords the client opportunistic _and_ strong security (as
strong as the DNSSEC) IFF the targets publish TLSA RRsets for
themselves.  But why wouldn't targets do that?  I believe they will when
doing so becomes widely recognized as a best practice, which I believe
will happen.

> text to accommodate whatever folks decide.

One might still always use TLS (with PKI or no authentication at all)
when TLSA RRsets are not found, but now we have fallback-to-no-TLS
security issues.  DANE removes the fallback problem , which is why DANE
should quickly become a best practice.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Sat, 5 Apr 2014 16:20:25 -0500

> generate text to accommodate whatever folks decide.

Er, are you asking for a consensus call on this point?  I'm definitely
for DANE-enabled TLS.  Who wouldn't be?  Can we hear some arguments
against?  I'm curious about this.

Or, if we don't hear any such arguments, then I think we must have
consensus on this point.

Until then, what's the harm in including "DANE-enabled TLS" in your I-D?
How might we get feedback on that if you don't?

As to IPsec, I really think there are two "correct" approaches to making
end-to-end IPsec work:

 - Apps (or the OS libraries/kernel) lookup IPsec-equivalents of TLSA
   RRsets for the desired host/service name (not IP addresses!), then
   arrange for local IPsec policy to require the remote's ID/credentials
   for the address found in the DNS to match those found in the IPsec
   DANE.

and/or

 - Use IPsec connection latching and channel binding to IPsec channels
   at the app layer.

Note that the first effectively refers to connection latching.  The
latter is only relevant when there's an app-layer authentication
mechanism with various properties, making the first approach the only
general one.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 6 Apr 2014 03:39:29 +0000

> How might we get feedback on that if you don't?

Thanks.  Specifically, I'd like to see opportunistic use of DANE
TLS (as secure as DNSSEC when TLSA records are found) included
under the "opportunistic security" umbrella.  There will of course
also be uses of DANE which are not "opportunistic", but they won't
have the scalability of "opportunistic DANE TLS".

Anyone else in support of having the I-D definition of "opportunistic
security" be broad enough to include the opportunistic DANE TLS
use-case?

-- 
	Viktor.

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 6 Apr 2014 09:52:41 -0700

> security" be broad enough to include the opportunistic DANE TLS

Yes, definitely. Given the increasing interest in DANE, it would be silly to have this document not handle it as a possibility.

--Paul Hoffman

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Apr 2014 10:14:32 -0400

Nico,

> against?  I'm curious about this.
I was not asking for a consensus call, yet. And, even if I were, the
issue is not whether DANE-enabled TLS is good or bad (I think it';s
very good) but whether it will be included in a definition of OS.
> Or, if we don't hear any such arguments, then I think we must have
DANE-enabled TLS does not meet some of the posited requirements for
OS, e.g., PFS, and encrypt first and authenticate later. Gee, that sounds
a lot like "shoot first and ask questions later" now that I think about 
it :-).
> How might we get feedback on that if you don't?
Include it as what? I have included notes on what I viewed as "legacy"
IETF security protocols. DANE-enabled TLS is rather new to be viewed
as one of those. I don't want to discuss all of the proposals that are
now on progress, lest we never complete this doc. In that sense DANE-enabled
TLS tends to fall in the middle. If folks feel it's important to mention,
then I will do so, but not as an example of OS.
> mechanism with various properties, making the first approach the only

I think this level of detail is beyond what needs to be discussed in 
this doc
but, as above, let's see what other folks feel.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Apr 2014 10:17:42 -0400

Paul,

> Yes, definitely. Given the increasing interest in DANE, it would be silly to have this document not handle it as a possibility.
As I noted in my reply a few minutes ago, one of the precepts for OS as per
the STRINT workshop was PFS. It doesn't seem that DANE-enabled TLS meets 
that
criteria, but maybe I'm mistaken. So, either we change the criteria for 
OS, or
we view DANE-enabled TLS and a good thing, but not as an example of OS.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Apr 2014 10:21:08 -0400

Viktor,
> security" be broad enough to include the opportunistic DANE TLS
As I mentioned in my reply to Paul, PFS was highlighted as a critical part
of OS 9ro whetever we call it) in the STRINT workshop. So, unless folks
decide to change that, it doesn't seem that DANE-enabled TLS fits. That's
not a criticism of DANE-enabled TL, just a side effect of the criteria.

I suggest Stephen, Jari, and Steve Bellovin chime in, since they were all
supporters of PFS as part of the criteria.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Apr 2014 15:08:34 +0000

On Mon, Apr 07, 2014 at 10:21:08AM -0400, Stephen Kent wrote:

> of OS (or whatever we call it) in the STRINT workshop. So, unless folks

I posit that an explicit *requirement* to negotiate PFS for a security
mechanism to be called "opportunistic security" (or WWCI) is nonsense.
Rather, "opportunistic security" (and other countermeasures to pervasive
monitoring) should strive for and prefer PFS, but requiring PFS is absurd.

Recall that "opportunistic security" is roughly speaking "as strong
as possible", and when nothing better is in fact possible, includes
cleartext.  Is cleartext stronger than a non-PFS TLS connection?

This is best illustrated by an interesting observation from my
employer's mail logs just last week:

    * Email sent via mimecast.com was observed to trigger TLS handshake
      errors in the mail log.  I was asked to look at these to determine
      whether something is wrong on our side, and whether mail was being
      delayed.

    * The error message in the logs was a TLS alert(46) from the SMTP client,
      which per http://tools.ietf.org/html/rfc5246#appendix-A.3 is
      "certificate_unknown".  One might say: "fair enough", after all, our
      SMTP server certificate was (and still is) self-signed.

    * However, STARTTLS in email is opportunistic, and like most MTAs, when
      TLS is not available, the mimecast.com MTA within a few milliseconds
      reconnected in cleartext and delivered the mail!

So what should one make of the server certificate check and refusal
to proceed with unauthenticated TLS?  My answer is: "cluelessness".
For the mimecast.com SMTP client checking certificates has as its
only effect the downgrading of a large fraction of SMTP connections
(self-signed certificates are naturally quite common with SMTP) to
cleartext.  No MITM protection is achieved, but pervasive monitoring
is made easier.

> supporters of PFS as part of the criteria.

I very much doubt that Steve Bellovin et. al. would seriously
suggest that "opportunistic security" require fallback to cleartext
when PFS is not available.  You do the best you can and recommend
to all concerned to *implement support* for PFS.  But surely no
requirement ala mimecast.com to throw in the towel and fall back
to cleartext when the TLS connection is not sufficiently righteous.

In light of the above, there is nothing in DANE TLS that specifically
contra-indicates PFS.  Indeed, for example, with Postfix PFS
ciphersuites will be used at highest preference whenever the server
supports these, whether the authentication mechanism is DANE or
PKIX and none at all (legacy opportunistic TLS).

It is surely clear that "opportunistic security" CANNOT REQUIRE
that PFS be the outcome, just as it CANNOT REQUIRE that even
encryption be the outcome.  This is surely a desired/recommended
capability, not a required outcome.

PFS is as much a goal for "opportunistic DANE TLS" as it is for
other forms of "opportunistic security".  The definitions of
"opportunistic security" in the draft should be broad enough to
accommodate "opportunistic DANE TLS".

-- 
	Viktor.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 07 Apr 2014 19:26:17 +0400

Dear Steve,

Thank you for taking this on.  Really good job.  I agree with Stephen,
and with everyone who said, “Go for it!”

Eliot

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 7 Apr 2014 10:37:18 -0700

On Apr 7, 2014, at 7:17 AM, Stephen Kent <[email-masked]> wrote:

> the STRINT workshop was PFS. 

I wasn't at the STRINT workshop, but I did talk to participants at the IETF afterward. None of them said that PFS was a requirement, some said it was a goal.

Stephen Farrel's slides in SAAG don't reflect the "PFS is a precept" idea. In fact, the opposite seems to be the case; his one point on OE was "Requiring a tight coupling of authentication and ability to encrypt not a good plan".

In addition, I'm not sure I see the why getting a server's cert via DANE inherently limits PFS. Not all certificates are for RSA encryption keys, right?

So, please do really consider making this document more open to the technologies that many people believe will help achieve OE.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Mon, 7 Apr 2014 12:50:21 -0500

> So, please do really consider making this document more open to the technologies that many people believe will help achieve OE.

+1

(sorry for not trimming more of the quotes; they are relevant to my
agreement, which is to all of the above)

Does SAAG have area working group items, like the Apps Area does?
This should be such a work item.

I'd add that maybe we ought to have competing I-Ds on this matter.

Nico
--

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Apr 2014 18:52:28 +0100

On 04/07/2014 06:37 PM, Paul Hoffman wrote:
>> As I noted in my reply a few minutes ago, one of the precepts for
>> OS as per the STRINT workshop was PFS.
> 
> I wasn't at the STRINT workshop, but I did talk to participants at
> the IETF afterward. None of them said that PFS was a requirement,
> some said it was a goal.
> 
> Stephen Farrel's slides in SAAG don't reflect the "PFS is a precept"
> idea. In fact, the opposite seems to be the case; his one point on OE
> was "Requiring a tight coupling of authentication and ability to
> encrypt not a good plan".
> 
> In addition, I'm not sure I see the why getting a server's cert via
> DANE inherently limits PFS. Not all certificates are for RSA
> encryption keys, right?
> 
> So, please do really consider making this document more open to the
> technologies that many people believe will help achieve OE.

Since I was (mis:-)named...

I think PFS is a fine thing for OE/OS, and would like to see
it as at least the common case that we strongly encourage. I
guess we'll all easily agree on that.

I'm not sure whether or not we ought go as far as to say that
use of RSA key transport means that a scheme does not conform
to our OS/OE terminology.

I could personally go either way on this, or put another way,
I'd be fine myself with if we have a rough consensus either way
on the topic, and yes, there are pros and cons. For me, the
biggest I think are that without PFS there's no possibility to
detect an attack that has succeeded. OTOH, declaring PFS as
required means that a bunch of useful things might take longer
to get deployed.

So colour me uncertain on this one.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 07 Apr 2014 19:03:54 +0100

> This should be such a work item.

Not nearly as organised. Sean and I had generally not liked
that idea. Kathleen and I haven't really discussed it but will.

The downside Sean and I saw was that area WGs can tend to throw
up ideas that really ought have had more review and/or charter
discussion as a result of which it can be too late to fix stuff
when drafts get to IETF LC or IESG eval. Appsawg are now for
example putting in place what they call "mini-charters" partly
(I think) to handle that.

One could argue that the overall perpass stuff means we're
now doing some of these kinds of drafts I guess and that we
ought organise that a bit more, but give Kathleen and I a
while to ponder that please. For example, consider beating us
up about it at IETF-90 maybe:-)

> I'd add that maybe we ought to have competing I-Ds on this matter.

Personally, I very much dislike that idea. We discussed
this topic and what to do and agreed that opportunistic
something was where to go. If you think that Steve K's draft
is not good enough to work from then please reply to my mail
asking about exactly that from last week. (But *please* reply
as requested to that so we don't re-run the entire terminology
discussion from scratch.)

S.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Apr 2014 18:13:41 +0000

> guess we'll all easily agree on that.

Yes, strongly encourage.

> to our OS/OE terminology.

More to the point, when encountering a server that *only* supports
RSA key transport, should an OS/OE client avoid using TLS, and send
in cleartext?  Clearly not!

> on the topic, and yes, there are pros and cons.

There really are no "pros and cons" here.  Opportunistic security
clients MUST be willing to accept RSA key transport when that's
all that is available, cleartext is never a better option.  However,
servers that want to claim support for OS/OE (the marketing term),
SHOULD support PFS.

The PFS red-herring is quite orthogonal to the opportunistic
component of client policy.  That is, PFS is motherhood and apple
pie goodness across the board from opportunistic unauthenticated
encryption to pre-shared peer fingerprint authentication.

> So colour me uncertain on this one.

I think you're letting yourself off the hook too easily.  Or in
any case I am not letting you of the hook that easily.  Elementary
logic leads one quickly to conclude that PFS *cannot* be a requirement.
Otherwise we end up in mimecast.com silly-land where, for example,
cleartext is used in place of TLS because certificate verification
fails or TLS did not use PFS, ...

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Apr 2014 14:33:13 -0400

Paul,
> I wasn't at the STRINT workshop, but I did talk to participants at the IETF afterward. None of them said that PFS was a requirement, some said it was a goal.
Well, the summary slides for the breakout session were not posted, so I 
can't point to
them. I'm still waiting for comments from the other folks in the session 
to see what
their recollection is.
> Stephen Farrel's slides in SAAG don't reflect the "PFS is a precept" idea. In fact, the opposite seems to be the case; his one point on OE was "Requiring a tight coupling of authentication and abil…
The quote above supports (though does not mandate) PFS use; it is not, 
as you suggest,
indicating the opposite! PFS via a blind DH exchange is pure encryption 
w/o authentication.
it epitomizes the comment you attributed to Stephen. Can you clarify 
what you meant above?
> In addition, I'm not sure I see the why getting a server's cert via DANE inherently limits PFS. Not all certificates are for RSA encryption keys, right?
Right, but if a cert for a server contains a DH key, unless that key is 
changed
after each time if is retrieved, the result will not be what I consider 
PFS. If
the private key corresponding to the public key in the TLSA record were 
compromised,
every passively wiretapped session with the server is vulnerable. The 
central
security idea behind PFS is to limit the damage done by disclosure of a 
private
key. That's why two-way, ephemeral DH is so attractive. From an ease of 
deployment
perspective, ephemeral DH is attractive because there is no a priori 
posting of
security data needed to enable it.

> So, please do really consider making this document more open to the technologies that many people believe will help achieve OE.
I'm not working to achieve OE, I'm working on OS :-).

Still, if the Sec ADs and others (not just the folks who have put a lot of
effort into DANE) indicate that want a less prospective (yet still useful)
definition for OS, I'll modify the doc accordingly.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 07 Apr 2014 14:33:23 -0400

Viktor,

I'm guessing that you did not attend the STRINT workshop, right?

My comments on requiring PFS are taken from that context. That's why
I asked Stephen, as workshop chair, and Jari and Steve Bellovin, all folks
who participated in the breakout session that generated the list that I
included in my doc, to comment. (Our new Sec AD, Kathleen, also attended
that session, so she shoudl feel free to comment as well.)

DANE-enabled TLS is a great technology. But, it requires that a target of
a session create a TLSa record. That, by itself, is a potential impediment
to widespread use. In contrast, a protocol that calls for the initiator
and responder to perform an ephemeral D-H exchange does not impose such a
burden. If a TLSA record exists, one could send it after the encrypted
session was in place.

I'm not sure how to interpret your response. It could be that you worry that
it DANE-enabled TLS isn't covered under the OS term, that will hinder its
adoption. Maybe. Maybe you feel that it's better to push for 
DANE-enabled TLS now,
and now wait for a PFS solution, i.e., the protocol in the hand is 
better that a
PFS in the bush, so to speak. I don't disagree with that observation. 
But, does
that mean we need to make the definition as set of statement of the form:
"you can do A, or B, and if you do A, then you may or may not do C, but if
you do B, then ..." That seems confusing, at least to me.

Your said:

"In light of the above, there is nothing in DANE TLS that specifically 
contra-indicates PFS. Indeed, for example, with Postfix PFS ciphersuites 
will be used at highest preference whenever the server supports these, 
whether the authentication mechanism is DANE or PKIX and none at all 
(legacy opportunistic TLS)."

Sorry that I missed that in the RFC. Can you remind me of the specific 
text that
indicates PFS support? I know that TLS can support PFS via the DH or 
ECDH cipher
suite, but the TLS RFCs indicate that this is an intentionally 
server-anonymous
mode of communication.

Your also said:

"It is surely clear that "opportunistic security" CANNOT REQUIRE that 
PFS be the outcome, just as it CANNOT REQUIRE that even encryption be 
the outcome."

I don't think my message said that. It said that a protocol 
characterized as OS
makes use of PFS. If one tries to execute an OS protocol, and a peer 
does not support it, and if we stick with the criteria developed in the 
workshop, then one would fallback to plaintext. You seem to be saying 
that it would be preferable to not require PFS if that
means falling back to plaintext, when one could use DANE-enabled TLS 
instead. I don't
disagree with that order of preference; the question is whether this 
should be called
OS.

Steve

---

From: Nico Williams <[email-masked]>
Date: Mon, 7 Apr 2014 14:09:55 -0500

> very good) but whether it will be included in a definition of OS.

OK, so let's define OS.  My definition:

    You get the strongest security in the Internet threat model that
can be obtained, and you get as strong a floor on security in the
Internet threat model as that which you can securely discover, else
the floor may be as low as protection only against passive attacks.

Note the importance of getting the floor to be as high as possible
when we can discover that it can be.  That's the point of using DNSSEC
to securely learn the server's/service's security capabilities: so
that you can then accept nothing less.

If the floor is always the lowest that's higher than just sending
plaintext then I'm afraid we won't be helping much at all.  We'll be
selling snake oil, and the public will eventually notice and call us
out for it.  The floor has to be variable, and fallback-safe.

> a lot like "shoot first and ask questions later" now that I think about it
> :-).

That's just ridiculous:

 - DANE doesn't say you don't get PFS;

 - nor is RSA key transport worse than not exchanging keys (and using
them) at all.

(I know, I'm repeating what Viktor's already said.)

I'm not sure what is the antecedent of "that" in you last sentence
above, so I can't tell if I agree with it or not :)

> then I will do so, but not as an example of OS.

So let's not discuss DANE.  Let's instead discuss semantics.  I
offered a definition of OS above.

> I think this level of detail is beyond what needs to be discussed in this
> doc

I don't care so much whether that detail/those proposals end up in the
I-D so much as that IF you're going to propose an OS mode for IPsec
then it'd better be meaningful.

End-to-end IPsec currently is not deployable on a large scale on
account of the issues that I've described too many times to bother
repeating myself right now.  Either you don't agree and we then debate
the issues, or you agree and wordsmith your I-D accordingly with
whatever level of detail is appropriate to that I-D's purpose.

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Apr 2014 19:51:28 +0000

On Mon, Apr 07, 2014 at 02:33:13PM -0400, Stephen Kent wrote:

> Paul,
>
> >I wasn't at the STRINT workshop, but I did talk to participants
> >at the IETF afterward. None of them said that PFS was a requirement,
> >some said it was a goal.
>
> can't point to them. I'm still waiting for comments from the other folks
> in the session to see what their recollection is.

Their recollection does not trump first-order logic.  PFS *cannot*
be a *required outcome* for an opportunistic mode of operation.
Otherwise, welcome to mimecast.com SMTP client silly-land.

PFS can and should be a preferred mode of operation regardless of
whether security is opportunistic or mandatory.  In this regard
nothing disqualifies DANE.

> >In addition, I'm not sure I see the why getting a server's cert
> >via DANE inherently limits PFS. Not all certificates are for RSA
> >encryption keys, right?

There are in practice negligibly few certificates that are limited
to RSA key transport (presumably via the keyUsage extension).  This
is a non-issue.  Secondly, in practice DANE TLSA (RFC 6698) does
not publish the server certificate, the vast majority of TLSA
records will be certificate or public key digests.  The certificate
will be provided in the server handshake (as with non-DANE TLS).

> changed after each time if is retrieved, the result will not be what I
> consider PFS.

Even with long-term fixed DH keys on the server (which are as common
with TLS as unicorns are on the prairie) the server is still free
to perform an ephemeral DH key exchange.  PFS is not ruled out by
fixed DH keys.

> If the private key corresponding to the public key in the TLSA record were
> compromised, every passively wiretapped session with the server is
> vulnerable.  The central security idea behind PFS is to limit the damage
> done by disclosure of a private key. That's why two-way, ephemeral DH is
> so attractive. From an ease of deployment perspective, ephemeral DH is
> attractive because there is no a priori posting of security data needed
> to enable it.

Though the public key will generally in fact not be *in* the TLSA
record, I'll read the above as equally applicable to the case when
the public key *digest* is in the TLSA record, which is I think
equivalent for your purpose.

Now if we're to take this objection to DANE as a mode of opportunistic
TLS seriously, we should note that there is nothing DANE specific
here.  ANY server with a long-term key, whether it corresponds to
a DANE TLSA record or not, if it employs a non-PFS key exchange
mechanism, may facilitate decryption of past session via disclosure
of long-term keys.

Thus, we might conclude, that OS/OE clients MUST refuse to connect
to existing servers with stable long-term keys, or refuse to
negotiate non-PFS key exchange mechanisms, and thus, since we're
making encryption invisible, transparent, ... use the superior
cleartext mechanism which is free of the RSA key exchange failure
mode.

Clearly not!  So all that could possibly be meant by the PFS goodness
from STRINT (I read the abstracts of most of the papers, and read
some in full) is that PFS should be promoted, and used as widely
as possible.  This in no way excludes DANE any more than it excludes
any other opportunistically authenticated or unauthenticated
protocol.

> definition for OS, I'll modify the doc accordingly.

This is rather a strange stance.  There is NOTHING in DANE that
makes disclosure of long-term keys any more risky than with other
protocols.  It seems you've the wrong end of the stick with respect
to DANE.  It is *precisely* the folks who understand DANE in detail,
who are best positioned to provide guidance on whether DANE fits
the opportunistic security model or not.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 7 Apr 2014 20:36:58 +0000

On Mon, Apr 07, 2014 at 02:33:23PM -0400, Stephen Kent wrote:

[ Reordered, because the below may the crux of the contention. ]

> > whether the authentication mechanism is DANE or PKIX and none at all (legacy
> > opportunistic TLS)."
> 
> Sorry that I missed that in the RFC. Can you remind me of the specific text
> that indicates PFS support? I know that TLS can support PFS via the DH or
> ECDH cipher suite, but the TLS RFCs indicate that this is an intentionally
> server-anonymous mode of communication.

I think this nails the source of the confusion.  TLS supports PFS *with*
authentication.  That's the distinction between the:

    # 	ADH-* and DHE-* ciphersuites.  The former are anonymous, in the
	latter the PFS key exchange is signed with the server's long-term
	keys.

    #   AECDH-* and ECDHE-* ciphersuites.  The former are anonymous,
        in the latter the PFS key exchange is signed with the server's
	long-term keys.

> a session create a TLSA record. That, by itself, is a potential impediment
> to widespread use.

Of course, I am not suggesting that "opportunistic DANE TLS" is
the one only true "opportunistic security".  I am merely suggesting
that DANE TLS is (for now pending wider DNSSEC deployment) a small
legitimate corner case that should not be *excluded* from the wide
umbrella term of "opportunistic security".

> In contrast, a protocol that calls for the initiator

This view of "opportunistic security" as a single protocol is
clearly too narrow.  For example, an HTTP client that opportunistically
upgrades to HTTPS would be ill-advised to refuse to employ non-PFS
cipher-suites and fall back to HTTP.

Sure, we want to encourage servers and clients to support PFS and
preferentially negotiate PFS key exchange mechanisms.  This does
not mean that technologies that are *capable* of non-PFS modes of
operation on either the client or the server are automatically
disqualified.

> I'm not sure how to interpret your response. It could be that you worry
> that if DANE-enabled TLS isn't covered under the OS term, that will hinder
> its adoption.  

No, my concern is that you've proposed a needlessly narrow view of
"opportunistic security" that hinders technical discussion of
related approaches to getting "as strong as possible" security.

> Maybe you feel that it's better to push for
> DANE-enabled TLS now, and now wait for a PFS solution, i.e., the protocol
> in the hand is better that a PFS in the bush, so to speak.

    * With respect to definitions of OS/OE I not pushing for DANE
      in preference to any other opportunistic approach.  Perhaps
      that's the source of confusion.  I am asking that your
      definitions not *exclude* opportunistic use of DANE, but
      definitely you SHOULD NOT prescribe DANE.

    * DANE neither demands nor precludes PFS, you don't need to
      wait for anything.  Postfix uses DANE with PFS, PKIX with
      PFS, opportunistic unauthenticated TLS with PFS, ...

    * PFS is orthogonal to all other aspects of the various protocols,
      it just a set of key exchange mechanisms that happens to be
      advantageous in the face of demands for disclosure of long-term keys.

> I don't disagree
> with that observation. But, does that mean we need to make the definition
> as set of statement of the form:  "you can do A, or B, and if you do A,
> then you may or may not do C, but if you do B, then ..." That seems
> confusing, at least to me.

To be honest, I no longer recall at this point which parts of the
definitions in the most recent version of the I-D seemed to exclude
DANE, and if I misread the defintions, and none do, great!

However, if the definitions are in fact restrictive to the point
of excluding opportunistic DANE from the umbrella defintion of
opportunistic security, then that is my objection.  I don't believe
that you should be defining a single protocol.  Rather this I-D
should be defining a new approach to securing many protocols in
which the security bar is not fixed at a high minimum that leaves
most traffic completely unprotected.

Opportunistic use of DANE is one mechanism to allow the bar to
float between cleartext and DNSSEC authenticated that fits within
the overall philosophy of "opportunistic security".

> I don't think my message said that. It said that a protocol characterized as
> OS makes use of PFS. If one tries to execute an OS protocol, and a peer does
> not support it, and if we stick with the criteria developed in the workshop,
> then one would fallback to plaintext. You seem to be saying that it would be
> preferable to not require PFS if that means falling back to plaintext,

Absolutely, and I think I would get majority support for this view.

> when one could use DANE-enabled TLS instead.

No, when one could use other key exchange mechanism, including RSA
key exchange.  Even with RSA key exchange one is free to ignore
the server's certificate leaving the server unauthenticated.  DANE
is irrelevant here.

> I don't disagree with that order of preference; the question is whether
> this should be called OS.

With "opportunistic DANE TLS" (for example), DANE authentication
is mandated when TLSA records are published, but in their absence
the policy degrades to "opportunistic TLS", which in the absence
of TLS support (e.g. with SMTP no STARTTLS) degrades to cleartext.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 08 Apr 2014 10:34:11 -0400

Viktor,

Your message appears to be a reply to some of my responses to Paul.
That makes my responses a bit confusing, but let me inject a few 
comments anyway.
> Otherwise, welcome to mimecast.com SMTP client silly-land.
You are begging the question. The unstated assumption is that any security
mechanism that is not labelled as OS is not a good thing to do, or will not
be deployed. I have never said that, nor do I believe it.
> nothing disqualifies DANE.
The DANE WG was created well before the PM discussion began, and the
relevant RFC (6698) was published a year before the IETF declared war
on PM. So, DANE is a new, but existing IETF security technology, one that
improves on the Web PKI model, but which still strives for creation of 
encrypted,
authenticated sessions. It is NOT a new design generated in response to 
the war
on PM, and thus whether it falls under the term OS should be irrelevant.
> to perform an ephemeral DH key exchange.  PFS is not ruled out by
I'm not sure what you're referring to here. If one publishes a D-H
public key via DANE, for what is it used if not key agreement?

> equivalent for your purpose.
yes, my comment is equally applicable if DANE published the hash of
a DH key used by a server.
> mechanism, may facilit
> ate decryption of past session via disclosure
> of long-term keys.
agreed. and that's a motivation to discourage use of such keys in
the future. (Of course we already have this in IPsec, on a per-peer
basis.)

> cleartext mechanism which is free of the RSA key exchange failure
Begging the question, again. The unstated assumption here is that OS
is the ONLY option available to the client and sever. Note that one of
the statement about OS is that it is NOT a substitute for existing, high
quality security mechanisms that afford authentication as well as 
encryption.
TLS with the Web PKI is one such mechanism, invoked by HTTPS, As far as I
am concerned, DANE-enabled TLS is another such mechanism (if the TLSA record
has been acquired via DNSSEC.) Since OS is to be invisible, there is a 
presumption
(which I will endeavor to clarify) that a user will explicitly invoke an
authenticated mode of communication if he/she so desires.
> any other opportunistically authenticated or unauthenticated
I think our only disagreement is whether DANE-enabled TLS (or IPsec, etc.)
warrants the OS label. I say no, because use of DANE offers high quality,
authenticated sessions as its primary goal, and because it precedes the
war on PM. For future efforts, where removing all barriers to use of 
encryption
is more important than authentication, OS is the term we ought to use. As I
noted, since DANE requires publishing a TLSA record, it does not seem to be
a good candidate to label as OS, i.e., because such publication is a 
barrier.
Now, admittedly, one can say that deploying a new protocol that does not
require each target of an OS connection to publish a DANE record is a 
barrier
as well. That's true, but DANE use requires protocol changes, so it imposes
2 barriers to adoption: new software at the client and server, plus server
publication of the TLSA record. I don't see that as a fatal flaw; I 
think DANE
is a excellent mechanism, one that is superior to DV certs issued under the
Web PKI model. But, that does not mean DANE-enabled foo should be 
labelled OS.
> the opportunistic security model or not.
Again, your comments are focused on arguments that I am not making.
DANE is not unique wrt the risks implied by use of long term keys.
TLS based on the Web PKI has the same problem, as does S/MIME and SSH
when they make use of key transport. The issue is that, going forward,
there seems to be a strong desire to move to PFS-based encryption, and
thus it makes sense to make that a criteria for new protocols that will
be called OS. DANE is not "new" relative to this discussion.

Steve

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Apr 2014 07:46:57 -0700

Multiple people have asked for this document to be more inclusive of DANE. So far, only you have stated an opinion in the negative. You stated early on that your reason was due to requirements from the STRINT workshop and asked for support from people at that workshop. That support has not come, and I showed a message from a participant that indicated the opposite.

Can you say how much more support from this list will be needed in order for you (as author) to make the document more inclusive?

--Paul Hoffman

---

From: "Olle E. Johansson" <[email-masked]>
Date: Tue, 8 Apr 2014 16:51:05 +0200

> Can you say how much more support from this list will be needed in order for you (as author) to make the document more inclusive?

Related question:

In SIP, we use DNS to indicate availability or requirement to use TLS - NAPTR and SRV records. Our RFCs allow a client implementation to prefer TLS and use it if it's available, regardless of what the user requires. A server operator can enforce TLS too.

Now, I would like to include clients that actually by code prefer TLS for any SIP connection. If it's available, use it.
The lucky part is that it doesn't seem like we have to update or write any documents for this. Just enforce and encourage a better practise out there.

In my world, this way of thinking is part of "Oppurtunistic Security". Is it in yours?

/O

---

From: Nico Williams <[email-masked]>
Date: Tue, 8 Apr 2014 10:07:54 -0500

> public key via DANE, for what is it used if not key agreement?

Typically one would publish a signing (and/or encryption) certificate or
bare public key in a host's TLSA RRset and then one would use an
authenticated key exchange in TLS using that certificate to authenticate
the server.  This allows the client/server to use (or not use) [EC]DHE
(PFS).

Yes, it would be possible to publish [EC]DH keys/certs instead, thus
leading to authenticate key exchanges that lack PFS, however, one could
still get PFS via renegotiation.

You seem to think that DANE -> not-PFS.  This is not even remotely true!

If that was your only concern about DANE then you should have none
left :)  If you have other concerns I'd like to know.

Of course, one could come up with other concerns, such as that DNSSEC is
a PKI with many of the problems inherent in a PKI, but since you're not
rejecting PKI yourself...

Nico
--

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 8 Apr 2014 15:32:55 +0000

On Tue, Apr 08, 2014 at 10:34:11AM -0400, Stephen Kent wrote:

> warrants the OS label.

You still have not really taken the time to internalize the
distinction between DANE TLS in general (which may or may not be
opportunistic) and "opportunistic DANE TLS".

I make *no claim* that DANE TLS in general is opportunistic security.
Recall that DANE can be used with protocols such as HTTPS or IMAPS
where the requirement to authenticate the peer is presupposed.

Nobody will benefit from anointing DANE TLS with inapplicable
marketing labels however popular or appealing they might be.

However, I *do claim* that "opportunistic DANE TLS" which is use
of DANE authentication ONLY when TLSA records are published and
otherwise fallback to strongest available security (typically
"opportunistic TLS" which even includes cleartext as an option).

The above behaviour is fundamentally a form of opportunistic
security, except that it has a higher ceiling than you propose, in
that it resists downgrade when enabled via DNSSEC TLSA records.

Furthermore, it appears that you were unaware that TLS support
authenticated PFS (signed ephemeral key exchange).  Given that
therefore the PFS objection is moot (DANE does not in any way
preclude PFS), while the I-D should not specifically single out
"opportunistic DANE TLS" as the preferred model for opportunistic
security, the definition needs to be broad enough to include it.

Opportunistic security needs to be broad enough to include most or
all variations on: encrypt when possible, authenticate when possible,
achieve best possible results, ... but don't throw in the towel
just because for some peer all that's possible is cleartext or
unauthenticated TLS.  With "opportunistic DANE TLS" the only twist
is that to avoid downgrade attacks clients don't fall back when
usable TLSA records are published.

> I say no, because use of DANE offers high quality,
> war on PM.

You're still not listening, you have a pre-conceived notion of what
DANE TLS means and ignoring all facts to the contrary.  RFC 6698
specifies a TLSA record format, it does not specify all possible
uses of that record format.  In "opportunistic DANE TLS" that record
format is used to *opportunistically* achieve downgrade-resistant
DANE authenticated security (when possible) but it is still
fundamentally a best effort security mechanism like the original
STARTTLS in SMTP.

Please make sure that the I-D definition does not preclude this form
of opportunistic security.  Please take the time (ask questions if
need be) to better understand what "opportunistic DANE TLS" is and
why it is relevant as an example of OS.

> For future efforts, where removing all barriers to use of
> encryption is more important than authentication, OS is the term we ought
> to use. As I noted, since DANE requires publishing a TLSA record, it does
> not seem to be a good candidate to label as OS, i.e., because such
> publication is a barrier.

Opportunistic DANE TLS works even when zero servers have published
TLSA records, it is simply identical to "opportunistic TLS" in that
case.  There is no barrier to adoption of the client's "opportunistic"
behaviour.

Unlike IPSEC in which client and server roles are largely symmetric,
or even meaningless, in TLS OS is fundamentally a *client* behaviour.
Server software does nothing to enable DANE TLS opportunistic or
otherwise, it just sits there and does TLS.  The operators of servers
who want to enable DANE security, publish TLSA records in their DNSSEC
signed zones.  This enables opportunistically DANE enabled clients to
make downgrade-resistant DANE authenticated connections to JUST the
servers that have done so.

Yes, DNSSEC is a barrier to adoption of server-side TLSA record
publishing, but that has nothing to do with OS/OE. There is no
barrier to adoption of the client behaviour of doing DANE when
possible, failing that TLS when possible, failing that cleartext.

> Now, admittedly, one can say that deploying a
> new protocol that does not require each target of an OS connection to
> publish a DANE record is a barrier as well.

It seems you're still trying to define a single protocol, where-as
OS should be an umbrella term for a family of protocol designs that
includes a variety of existing and future IETF protocols.

> That's true, but DANE use
> requires protocol changes, so it imposes 2 barriers to adoption: new
> software at the client and server, plus server publication of the TLSA
> record.

Yes, "opportunistic DANE TLS" will not be the *primary* form of
opportunistic security.  Perhaps for the next 5-10 years as DNSSEC
adoption increases (or fizzles out) "opportunistic DANE TLS" will
be used in only a small fraction of the connections that qualify
as "OS".  This does not make this use-case invalid.

> I don't see that as a fatal flaw; I think DANE is a excellent
> mechanism, one that is superior to DV certs issued under the Web PKI model.
> But, that does not mean DANE-enabled foo should be labeled OS.

Unless DANE is used *opportunistically*!

> The issue is that, going forward,

Whether DANE is new or existed before is irrelevant, existing
protocols that meet a sensible definition of "OS" should not be
excluded from OS, just because they existed before the summer of
2013.  And in fact while DANE is not "new", "opportunistic DANE
TLS" is new, it was proposed by me in the DANE SMTP draft specifically
as a new use-case for DANE.

We will only make progress if you take the time ask questions to
help you better understand the nature of the requested more inclusive
definition, rather than continue to object on the basis of firmly
held preconceived counter-factual notions.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 08 Apr 2014 15:22:49 -0400

Viktor,

>          in the latter the PFS key exchange is signed with the server's
I asked for references (from RFC 5246). I scanned that RFC for AECDH and 
for
ADH found no hits. I did find text for DHE and ECDHE and you are correct 
that
these cipher suites offer the potential for PFS, and F.1.1.3 explicitly 
states
that one should use a fresh DH secret for each exchange to achieve PFS. 
Is this
done by many servers? Anyway, thanks for the clarification (I was 
focusing on F1.1.1).
> umbrella term of "opportunistic security".
why should it not be excluded as we create definitions for a NEW set
of security protocols?
> cipher-suites and fall back to HTTP.
this use of the term "opportunistic" argues for he need to have a
more precise definition :-). Nothing needs to be labelled as
"opportunistic" to be good or to be deployed.
> operation on either the client or the server are automatically
Again, the term "disqualified" strikes me as inappropriate. My focus
has been on documenting criteria for a set of new protocols, created
in response to the IETF war on PM. These criteria were discussed in
a STRINT workshop session devoted to the topic, and attended by current
and former Sed ADs, the IETF Chair, and several WG chairs who are
dealing with the topic. None of this should be seen as competing with
existing security protocols, e.g., TLS or IPsec. TLS, whether used with
the Web PKI or with DANE, offers potentially better security service
guarantees than an OS protocol.
> related approaches to getting "as strong as possible" security.
You say "needlessly narrow" I say "clearly defined" :-). Your 
characterization
of "as strong as possible" makes no mention of widely deployed, which is a
critical aspect of OS. It also seems to suggest that if something isn't 
labelled
OS, it will not be deployed. That's silly, to paraphrase your criticism.
>        definitely you SHOULD NOT prescribe DANE.
why?
>        PFS, opportunistic unauthenticated TLS with PFS, ...
DANE certainly does not demand PFS, but only one of the three
certs types defined in 6698 is supportive of PFS w/o authentication.
But, as you noted, if one employs authenticated cipher suites plus
DH (ECDH) one can still achieve PFS.

>        advantageous in the face of demands for disclosure of long-term keys.
yes, PFS is just one aspect of a key management mechanism. It happens to
be an aspect that was strongly endorsed at the workshop, which is why it
is called out in the doc.
> DANE, and if I misread the defintions, and none do, great!
Then I suggest you read the next rev when it appears. But, frankly,
I see no need to accommodate DANE (RFC 6698) under the OS umbrella,
and I have heard no good explanation for why it ought to be included.
> most traffic completely unprotected.
I am not defining a single protocol. But I also see no reason to
include DANE as an OS protocol. You have not provided a simple,
compelling argument for inclusion. Please do so.
> the overall philosophy of "opportunistic security".
Oh, have you been alluding (but not stating explicitly) to I-Ds that
propose new ways to make use of DANE, as opposed to the extant RFC?
That was not clear to me from any of your messages. My comments about
whether DANE needs to be included under the OS definition have been
based on 6698.

> Absolutely, and I think I would get majority support for this view.
that was not the view of the workshop breakout session participants, but
perhaps that's because the focus was on maximizing use of encryption, with
minimal added connection setup delay.
> the server's certificate leaving the server unauthenticated.  DANE
Implementations may choose to ignore a server cert, but it's not
the general intent of TLS, certainly if a human user is involved.
> of TLS support (e.g. with SMTP no STARTTLS) degrades to cleartext.
OK, now I see what you're focusing on. It was not at all clear in your
previous messages, which referred to DANE, which I interpreted as 6698.
(BTW, your I-D refers to CAs as "certificate authorities."
They're "certification authorities.")

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 08 Apr 2014 15:23:48 -0400

Viktor,
> in cleartext?  Clearly not!
That is not the question in the table. The question I'm addressing
is for NEW protocols/mechanisms being developed as part of the IETF
war on PM. TLS typically is used with RSA key transport. The proposed OS
criteria says that OS is NOT a substitute for existing security protocols,
especially ones that provide authenticated, encrypted communication.
> servers that want to claim support for OS/OE (the marketing term),
I guess we should start with the question of how one defines an OS client.
Because OS is not intended to be a substitute for TLS (for example), when
invoked via HTTPS (or redirect to HTTPS), use of key transport in that
context is fine; it's not OS.
> encryption to pre-shared peer fingerprint authentication.
PFS is a beneficial side effect of ephemeral key agreement. Ephemeral
key agreement is a good starting point for OS because it impose NO
requirements on the initiator or target of a session to have done
anything other than run software that supports that capability. Perhaps
it would be better to make that a more explicit element of the OS criteria,
separate from PFS.
> fails or TLS did not use PFS, ...
Elementary logic, absent unstated assumptions, does not lead one to the
conclusion you stated, as per my response to your prior message that used
the same text.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Tue, 08 Apr 2014 15:27:13 -0400

Paul,
> Multiple people have asked for this document to be more inclusive of DANE. So far, only you have stated an opinion in the negative. You stated early on that your reason was due to requirements from…
no, you didn't. if you read (and understood) my reply, you would see 
that Stephen's comment
do not contradict what I said. Try again.
> Can you say how much more support from this list will be needed in order for you (as author) to make the document more inclusive?
I see a lot of comments from you and Viktor, two ardent DANE supporters 
who seem
to be concerned that if DANE isn't labelled as OS, it will somehow be 
ignored.

I see a separate set of comments from Nico, focusing on a different set 
of issues.
That's a useful, not DANE-centric, discussion in which I am participating.

I saw one comment from Stephen Farrell, who indicated indicated that he 
was not
sure whether PFS was a strict requirement.

I'm willing to wait a few days to let others who participated in the 
workshop
have a chance to comment.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 8 Apr 2014 21:23:04 +0000

> compelling argument for inclusion. Please do so.

I am not asking you to classify RFC 6698 DANE as OS.  Rather, I'm
asking you leave room for opportunistic variants of RFC 6698 such
as:

Opportunistic DANE TLS is a protocol in which (for now SMTP) clients
employ as strong as possible security with each (SMTP) server.
This subsumes cleartext for servers that neither publish TLSA
records nor offer STARTTLS (or some MITM downgraded their EHLO
response).  It also subsumes opportunitic unauthenticated TLS when
no TLSA records are found, but STARTTLS is available.  It also
subsumes mandatory unauthenticated TLS when TLSA records exist,
but none are usable, ...

> propose new ways to make use of DANE, as opposed to the extant RFC?

Yes.

> whether DANE needs to be included under the OS definition have been

RFC 6698 is NOT "opportunistic DANE TLS".

> and I have heard no good explanation for why it ought to be included.

Because DANE is not just RFC 6698.  The DANE SMTP draft defines
"opportunistic DANE TLS", which should be included, and I expect
will be excluded, once confusion and the needless objections cease.

> They're "certification authorities.")

Thanks for the feedback, I will make appropriate changes this
evening.

> certs types defined in 6698 is supportive of PFS w/o authentication.

This is false.  If you have questions about DANE, feel free to ask,
but making clearly erroneous statements does not help move this
issue forward.  None of the 4 certificate usages in DANE are in
any way correlated with use or non-use of PFS.

> DH (ECDH) one can still achieve PFS.

Across all TLSA record types, the TLSA record does not select the
TLS key exchange mechanism.  It can be PFS or RSA key transport if
the keys happen to be RSA keys, but even RSA keys work with PFS.

> the general intent of TLS, certainly if a human user is involved.

The primary use-case for opportunistic DANE TLS is not HTTPS.  It
is a reasonable protocol wherever one would otherwise typically
have no security or best unauthenticated security, and where there
both some tolerance for latency and some desire for authentication
when possible.  For SMTP it fits like a glove, especially because
PKIX is profoundly unusable with SMTP.  Similar considerations lead
to an essentially opportunistic use of DANE TLS in XMPP (they've
just not applied the term yet).

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Apr 2014 09:57:36 -0400

Viktor,

> subsumes mandatory unauthenticated TLS when TLSA records exist,
I understand, now. Sorry for the confusion.
> the keys happen to be RSA keys, but even RSA keys work with PFS.
You are correct. But, I suspect that most folks reading 6698 interpret
it relative to the most common practice for TLS, in which RSA is used
for key transport. If one conveys an EE cert via a TLSA record, I think
most folks would not expect that cert to be used for auth and NOT key
transport, even though that use case is covered by TLS.

Anyway, I was confused by which doc we were debating. My bad. And, you
are correct that TLSA records do not, strictly speaking, dictate the
cipher suite used with TLS, so PFS is not incompatible with use of DANE.

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 14 Apr 2014 15:40:09 +0000

On Mon, Apr 14, 2014 at 09:57:36AM -0400, Stephen Kent wrote:

> >response).  It also subsumes opportunistic unauthenticated TLS when

Thanks.  Much appreciated, glad to get this part out of the way.

> for key transport.

I am not sure whether it is still correct to say that we expect
RSA key transport for RSA keys.  PFS with RSA keys is increasingly
more common.  Here is a frequency count of ciphers from a maillog
file:

-------------------------------------------------------------------------
   count OpenSSL cipher name and bits		PFS or RSA key transport?
-------------------------------------------------------------------------
    7399 AECDH-AES256-SHA (256 bits)		PFS
    5548 ECDHE-RSA-AES256-SHA (256 bits)	PFS
    1410 ADH-CAMELLIA256-SHA (256 bits)		PFS
    1173 ECDHE-RSA-RC4-SHA (128 bits)		PFS
     991 DHE-RSA-AES256-SHA (256 bits)		PFS
     354 ADH-AES256-SHA (256 bits)		PFS
     229 AES128-SHA (128 bits)			RSA
     209 AES256-SHA (256 bits)			RSA
      73 ECDHE-RSA-AES128-SHA (128 bits)	PFS
      39 DHE-RSA-AES128-SHA (128 bits)		PFS
      32 RC4-SHA (128 bits)			RSA
      22 DHE-RSA-CAMELLIA256-SHA (256 bits)	PFS
       7 RC4-MD5 (128 bits)			RSA
       1 EDH-RSA-DES-CBC3-SHA (168 bits)	PFS
-------------------------------------------------------------------------
TOTAL:
-------------------------------------------------------------------------
   17010 					PFS
     477 					RSA

So for my domain's SMTP server, which has an RSA key, the current
mail log file had only ~500 non-PFS connections out of ~17500 total.

So RSA key transport is rather the exception on this SMTP server,
despite its RSA key.  I expect that other PFS-capable MTAs observe
similar usage patterns.

Perhaps with HTTPS RSA key transport is still used more
frequently, but this is changing I believe:

    http://www.netcraft.com/internet-data-mining/ssl-survey/

	Perfect Forward Secrecy (PFS) provides a defence against the
	compromise of the private key corresponding to an SSL certificate.
	If an SSL web server uses a PFS cipher suite, the secret keys
	used to encrypt historical TLS sessions are not revealed even
	if the long-term private key is compromised.  In the news in
	2013, usage of PFS in August 2013 was not particularly widespread:
	around one third of SSL sites negotiated a cipher suite with
	the PFS property and a further 28% of SSL servers are capable
	of PFS, but actively avoid using PFS cipher suites.

That was in August, the picture is probably already quite different,
though I don't know whether PFS as yet accounts for more than 50%
(by whatever metric is employed).

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 15 Apr 2014 10:35:54 -0400

Viktor,

Thanks for the reply.

> RSA key transport for RSA keys.
PFS using RSA keys is a poor choice wrt performance, i.e., it is much
more costly (CPU cycles) to generate an ephemeral RSA key pair than
to generate an ephemeral D-H key pair. Why would folks choose that option?

(Or, are you saying that people are using RSA-signed certs but then
using ephemeral D-H? That's a totally different matter, but understandable
because certs signed using RSA are so common anyway.)

As you noted, the situation may be different for HTTPS vs. use of
TLS in other contexts, but I'm still surprised. But, it's great to
have some real numbers!

Steve

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 15 Apr 2014 14:45:08 +0000

> to generate an ephemeral D-H key pair. Why would folks choose that option?

In TLS that's not how PFS works with RSA keys.

> because certs signed using RSA are so common anyway.)

It goes beyond what "people are using"!  Key agreement via ephemeral
RSA keys is ONLY defined in the TLS RFCs with long-obsolete export
cipher-suites (use RSA 1024 signing keys to sign ephemeral 512-bit
export RSA keys).  In TLS, the ONLY way to do RSA key transport
with non-export cipher-suites is to use ECDHE or DHE signed with
the RSA key.

So PFS in TLS basically means ephemeral ECDH or DH.

-- 
	Viktor.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 16 Apr 2014 08:59:19 -0400

Viktor,

> In TLS that's not how PFS works with RSA keys.
I didn't think so, but I was confused by the terms you used.
> export RSA keys).
I didn't look back to those older, "exportable" cipher suites. Thanks
for the reminder.
>   In TLS, the ONLY way to do RSA key transport
> the RSA key. So PFS in TLS basically means ephemeral ECDH or DH.
Agreed. Sorry I became confused by the terminology issue.

Steve