Subject: [Uta] Proposed list of deliverables

From: "Orit Levin (LCA)" <[email-masked]>
Date: Sat, 18 Jan 2014 06:24:44 +0000

Below is the list of deliverables for your consideration:

1. A threat analysis document containing a collection of known security breaches to application protocols due to poor use of TLS (Likely an Informational RFC) 
2. Applications' independent document recommending best existing and future practices for using TLS (Likely a BCP or a Proposed Standard RFC) 
3. A set of documents, each describing best existing and future practices for using TLS with a specific application protocol, i.e., SMTP, POP, IMAP, XMPP, HTTP 1.1, etc. (Case-by-case likely a BCP or a Proposed Standard RFC) 
4. A document discussing (and potentially defining) how to apply the opportunistic encryption approach (preliminary outlined in draft-farrelll-mpls-opportunistic-encrypt-00.txt) to TLS. (Category TBD)

Please, send your feedback to the list (including short +1s to indicate that the direction makes sense to you).

Thanks,
Leif and Orit - the chairs.

---

From: Linus Nordberg <[email-masked]>
Date: Mon, 20 Jan 2014 12:09:27 +0100

"Orit Levin (LCA)" <[email-masked]> wrote
Sat, 18 Jan 2014 06:24:44 +0000:

| Below is the list of deliverables for your consideration:
| 
| 1. A threat analysis document containing a collection of known
| security breaches to application protocols due to poor use of TLS
| (Likely an Informational RFC)
| 2. Applications' independent document recommending best existing and
| future practices for using TLS (Likely a BCP or a Proposed Standard
| RFC)
| 3. A set of documents, each describing best existing and future
| practices for using TLS with a specific application protocol, i.e.,
| SMTP, POP, IMAP, XMPP, HTTP 1.1, etc. (Case-by-case likely a BCP or a
| Proposed Standard RFC)
| 4. A document discussing (and potentially defining) how to apply the
| opportunistic encryption approach (preliminary outlined in
| draft-farrelll-mpls-opportunistic-encrypt-00.txt) to TLS. (Category
| TBD)

These all seem fine to me. I'd like to propose another document
describing fingerprintability of TLS traffic and how TLS is being
fingerprinted in practice.

---

From: Leif Johansson <[email-masked]>
Date: Mon, 20 Jan 2014 12:39:59 +0100

> fingerprinted in practice.
Isn't that more a perpass thing? Unless you propose operational BCPs for
avoiding fingerprinting that is...

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 20 Jan 2014 11:51:32 +0000

Hi,
This looks sensible, but I am trying to figure out how existing drafts 
fit into this plan.

> 3. A set of documents, each describing best existing and future practices for using TLS with a specific application protocol, i.e., SMTP, POP, IMAP, XMPP, HTTP 1.1, etc. (Case-by-case likely a BCP…
It sounds like the following 2 would cover this for SMTP/POP/IMAP:

http://datatracker.ietf.org/doc/draft-melnikov-email-tls-certs/
http://datatracker.ietf.org/doc/draft-moore-email-tls/

(Some pieces of draft-newman-email-deep might apply here as well).
> 4. A document discussing (and potentially defining) how to apply the opportunistic encryption approach (preliminary outlined in draft-farrelll-mpls-opportunistic-encrypt-00.txt) to TLS. (Category T…

There is a document defining this for email:
http://datatracker.ietf.org/doc/draft-newman-email-deep/

Last time I talked to Chris and Keith, they were planning to merge it 
with Keith's document:
http://datatracker.ietf.org/doc/draft-moore-email-tls/

I would like to confirm with WG chairs that the proposal above makes sense.

Best Regards,
Alexey

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 20 Jan 2014 07:58:20 -0500

> 1. A threat analysis document containing a collection of known security breaches to application protocols due to poor use of TLS (Likely an Informational RFC) 

Is this meant to also cover application protocols with *no* use of TLS? That is, is the threat analysis supposed to cover "why you should encrypt", or just "why you should encrypt well when you encrypt"?

> 2. Applications' independent document recommending best existing and future practices for using TLS (Likely a BCP or a Proposed Standard RFC) 

Good.

> 3. A set of documents, each describing best existing and future practices for using TLS with a specific application protocol, i.e., SMTP, POP, IMAP, XMPP, HTTP 1.1, etc. (Case-by-case likely a BCP…

This needs to be defined more. The phase "using TLS" can mean one or more of:
- TLS with server authentication, with encryption
- TLS with server authentication, without encryption
- TLS without server authentication, with encryption
- TLS with server authentication, with client authentication, with encryption
- TLS with server authentication, with client authentication, without encryption
- TLS without server authentication, with client authentication, with encryption
Different short names are applied different scenarios, making it all the more confusing. If we don't get this one right, we can easily delay useful results from the WG by two years.

> 4. A document discussing (and potentially defining) how to apply the opportunistic encryption approach (preliminary outlined in draft-farrelll-mpls-opportunistic-encrypt-00.txt) to TLS. (Category T…

The preliminary outline in that document is transitory, and in some ways not easily applicable to TLS. Why are we not making our own definition so that we can apply it to TLS precisely?

--Paul Hoffman

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 20 Jan 2014 10:44:40 -0500

> http://datatracker.ietf.org/doc/draft-moore-email-tls/

Both of these drafts use the term "pinning" in line with the way it is
used in RFC 6125, which is in contradiction to the way the term
"pinning" is used in websec's Key Pinning draft:

 https://datatracker.ietf.org/doc/draft-ietf-websec-key-pinning/

In 6125 and the two e-mail drafts above, "pinning" is used to refer to
the activity that firefox describes as "adding a security exception" and
chrome calls "proceed anyway" -- where the user (or someone) overrides
the TLS verification stack to indicate that a particular certificate is
acceptable to them for a particular site, regardless of the name or
other entity identifiers found in the certificate.  I'd call this
"permissive" pinning, since it increases the set of acceptable
certificates in general.

In the draft-websec-key-pinning, the term "pinning" is used to indicate
a set of keys (not certificates) that the server communicates to the
client which *must* be used for future connections to that server.  I'd
call this "restrictive" pinning, because it reduces the set of
acceptable certificates in general (certificates that are signed by
other trusted root authorities over end entity keys that aren't in the
set of pins will be considered unacceptable).

Even worse, these two "pinning" ideas could overlap for a particular
browser/website: a site could use the restrictive key pinning to
indicate which public keys are acceptable, and then offer a certificate
over one of those keys which isn't signed by a root authority accepted
by the client; so the client would need to "set a security exception" or
"proceed anyway", which is forbidden by draft-ietf-websec-key-pinning
(section 2.6).  But it's also possible that the user already added a
"permissive" pin (a "security exception") for that web site before
receiving draft-ietf-websec-key-pinning pinning instructions from the
web server :/

I think we're heading for trouble with this terminology overlap, in a
space that is already difficult to understand for implementers, server
administrators, and browser users.  but i don't know how to best avoid
further confusion.

In the server administration circles i travel in, people who are
security conscious tend to associate the term "pinning" with the ideas
behind draft-ietf-websec-key-pinning.  If you tell them that "setting a
security exception" in firefox is also "pinning", it will cause no small
amount of concern (since their goal in deploying public-key-pinningis to
avoid having their users tricked by an MITM offering bogus
certificates).  OTOH, RFC 6125 itself is published, so its meaning of
"pinning" won't be going away any time soon :/

At the very least, it seems like new drafts should make it clear that
their meaning of "pinning" does not mean the other well-known "pinning".

Any better suggestions for avoiding the ambiguiity?

	--dkg

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 20 Jan 2014 17:30:22 +0000

On 20/01/2014 15:44, Daniel Kahn Gillmor wrote:

> [RFC6125 'pinning' => security exception vs. websec 'certificate
> pinning' => specified certificate confusion ]

Ohh, that could indeed be confusing. They're very nearly opposite
meanings, with a tiny overlap (the ≤0.001% of users that might
actually check a fingerprint via some out-of-band means).

It seems to me that the only obvious course to try to avoid confusion
is to call the one that's not in an RFC yet something else, while we
still have a slim chance to.

Certificate 'anchoring', perhaps, since we're anchoring the
authentication to a particular certificate or chain of trust?

- -- 
/akr

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Mon, 20 Jan 2014 21:35:08 +0000

Thanks, Paul!
See inline. \Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Paul Hoffman
> Sent: Monday, January 20, 2014 4:58 AM
> To: [email-masked]
> Subject: Re: [Uta] Proposed list of deliverables
> 
> > 1. A threat analysis document containing a collection of known security
> breaches to application protocols due to poor use of TLS (Likely an
> Informational RFC)
> 
> Is this meant to also cover application protocols with *no* use of TLS? That is, is
> the threat analysis supposed to cover "why you should encrypt", or just "why
> you should encrypt well when you encrypt"?
> 

I envision this document to be as specific to TLS usage as possible (or the lack of it when TLS should have been a natural choice).

I could imagine the document to be organization by specific and/or publicly documented security breaches, each followed by a "threat analysis" targeted to application protocol designers and application users, who are not necessarily crypto professionals or security experts. The analysis should point to more "deep dive" security and other UTA documents when appropriate. Of course, at this stage this is a suggestion for feedback.

> > 2. Applications' independent document recommending best existing and future
> practices for using TLS (Likely a BCP or a Proposed Standard RFC)
> 
> Good.
> 
> > 3. A set of documents, each describing best existing and future practices for
> using TLS with a specific application protocol, i.e., SMTP, POP, IMAP, XMPP,
> HTTP 1.1, etc. (Case-by-case likely a BCP or a Proposed Standard RFC)
> 
> Different short names are applied different scenarios, making it all the more
> confusing. If we don't get this one right, we can easily delay useful results from
> the WG by two years.

If this organization proves useful, it probably belongs to #2 Applications' independent document. For the application-specific documents, similar discussion could be helpful for focusing on use cases (topologies) relevant to this application with its application clients, servers, proxies, etc. (each implementing a TLS client or a TLS server).

> 
> > 4. A document discussing (and potentially defining) how to apply the
> opportunistic encryption approach (preliminary outlined in draft-farrelll-mpls-
> opportunistic-encrypt-00.txt) to TLS. (Category TBD)
> 
> The preliminary outline in that document is transitory, and in some ways not
> easily applicable to TLS.

Sections 2.1 - 2.3 in this draft are generic and can be applicable to an arbitrary protocol. As it was pointed out in Vancouver and on the perpass list earlier, other definitions/interpretations of opportunistic encryption (OE) exist in RFCs and peoples' minds. I believe that IETF needs to agree on a conceptual meaning of OE or whatever alternative name(s) are chosen for different things. 

>Why are we not making our own definition so that we
> can apply it to TLS precisely?
> 

That is exactly what this deliverables is for; that is regardless whether we call it OE or not :-). Still, the terminology needs to be understood and consistent across the industry (at the very least, across all IETF).

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

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 20 Jan 2014 16:55:18 -0500

On 01/20/2014 01:57 PM, Chris Palmer wrote:
> On Mon, Jan 20, 2014 at 7:44 AM, Daniel Kahn Gillmor
> <[email-masked]> wrote:
> 
> (Note that Chrome does not remember your decision to Proceed Anyway,
> although we are working on that.)

ah, that's good to know, thanks for the heads-up.

> Perhaps "key pinning" vs. "exception pinning"? I wanted to call
> "exception pinning" "name pinning" at first, until I remembered DNS
> pinning (to defend against
> http://en.wikipedia.org/wiki/DNS_rebinding). So maybe we have 3
> pinnings. :) It's worth noting that 2 of the 3 (key pinning and DNS
> pinning) refer to *reducing* the number of trusted entities.

Hm, RFC 6125 pinning is also about certificates, not just public keys,
so maybe it's "certificate exception pinning" -- but really it seems
like a flavor of permissive TOFU (trust on first use) more than anything
else.

so we have:

 * DNS pinning: maintain DNS records in the browser (possibly past their
TTL) to avoid DNS rebinding attacks.

 * key pinning: binds public keys to domain names (at the request of the
origin server), forbids the use of certificates that do not include the
pinned public keys somewhere in the cert chain.

 * certificate pinning: associate an otherwise non-valid End Entity (EE)
certificate with a domain name (at the request of the user), permitting
that certificate to be used with the domain name, but *without*
forbidding any other certificate from use.

> Anyway, I consistently refer to the behavior described in the key
> pinning draft as "key pinning", if that helps. (Probably not.) 

I think it's a start, at least.

> I can add an explanatory note to our draft, if that would help.

I think a clarifying note in draft-ietf-websec-key-pinning is necessary
(i don't know that it is sufficient).  it could be just something to
indicate that the key pinning described in the draft  has entirely
distinct semantics and characteristics than "RFC 6125 certificate
exception pinning".

	--dkg

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Tue, 21 Jan 2014 07:14:22 +0000

Alexey et al,
Sounds good to me. Removing overlaps by merging the drafts is definitely the right way forward.

draft-newman-email-deep has a number of interesting suggestions. Some of the described techniques could be generalized and discussed in the context of the application-independent deliverable #4, indeed.

Overall, it would be great if the authors of these and other UTA-related drafts make a stab at identifying practices and techniques useful for other application protocols. Once specified in a way independent from the application logic, they will become candidates towards #4.

Thanks,
Orit.

> From: Alexey Melnikov [mailto:[email-masked]]
> Sent: Monday, January 20, 2014 3:52 AM
> To: Orit Levin (LCA)
> Cc: [email-masked]; Pete Resnick; Barry Leiba