Subject: [TLS] Should TLS 1.3 use an augmented PAKE by default?

From: Andy Lutomirski <[email-masked]>
Date: Tue, 18 Mar 2014 11:11:15 -0700

I'd like to see TLS 1.3 solve what I consider to be two major problems
in past versions.

1. When clients authenticate with a password, if they send their
password to the wrong server, that server learns their password.  This
is the basis of most phishing attacks.  (I'm ignoring TLS-SRP, which is
basically unused.)

2. If a client uses a client certificate, the client has to store the
private key *and* certificate associated with the certificate.  That
means that any encrypted form of that certificate is subject to a
dictionary attack.

Both of these problems can be solved if the default mode of client
authentication in TLS 1.3 were an augmented PAKE or a non-key-exchanging
equivalent.  #1 is addressed directly, and it would even be safe to
share passwords between different servers.  #2 is also solved: a client
certificate could be some identifying information (which does *not*
contain a PAKE verifier) and a high-entropy "password" encrypted with a
real password.  As long as the encryption doesn't provide a way to check
whether the key is correct, no one can brute-force the client's password
without a round trip to the server for each guess.

It might make sense to use similar techniques to authenticate servers to
clients.  First, symmetry is nice.  Second, I think that several of the
protocols for doing this kind of authentication are actually *faster*
than using digital signatures.

Should TLS do something like this?  This may fit in with Watson Ladd's
suggestions about using something other than conventional DH for key
exchange.

--Andy

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 18 Mar 2014 17:13:03 -0400

Hi Andy--

Thanks for raising this question.

On 03/18/2014 02:11 PM, Andy Lutomirski wrote:
> password to the wrong server, that server learns their password.

I think you're talking about HTTP basic auth here, or IMAP AUTH=PLAIN,
right?  Other authentication mechanisms that are layered on top of TLS
don't necessarily have the same concern.

>  This

TLS SRP's lack of use suggests that there is not a high pressure for
deployment here.

It's probably worth thinking some about why SRP adoption has been so
slow (i don't know the global answer here, but i only know a few folks
who are using it)

> means that any encrypted form of that certificate is subject to a

i'm not sure i understand.  the certificate is public, right?  i think
you mean that the stored public key (presumably encrypted locally) is
subject to an offline dictionary attack.  This is no better or worse
than a client with an encrypted password store, of course.

A client which caches credentials for the user over the long term should
be locking those credentials (whether public-key-based or
password-based) with a heavily-stretched password, to make offline
dictionary attacks expensive.

> share passwords between different servers.

how does PAKE allow sharing of passwords between servers?  can't a
server willing to do a bunch of offline computation figure out the
client's password from its stored verifier?  this moves the offline
dictionary attack from the client to the server, but it would still
allow the server to recover the client's password, which would then
enable its reuse on different sites if the user thought it was ok to
share a password between services.

> than using digital signatures.

how strong is a PAKE for a generic network-based adversary?  how strong
is it when the server itself is the adversary?

At the CFRG meeting at IETF-89 earlier this month, there was very little
enthusiasm in the room for further discussion about PAKE.  this may just
be fatigue from the dragonfly discussion, though.

> suggestions about using something other than conventional DH for key

What about this proposal is different from SRP, which we already have?
Why not encourage more adoption of SRP and learn what the sticking
points are for that authentication mechanism?

My basic sense is that PAKE models are generally useful for one-shot or
limited-time use, as a bootstrapping step to something stronger, but not
as a regular, per-connection authentication mechanism.  I'd be happy to
be convinced that they're more generally useful, though :)

Regards,

	--dkg

---

From: Andy Lutomirski <[email-masked]>
Date: Tue, 18 Mar 2014 14:55:20 -0700

> don't necessarily have the same concern.

As far as I know, pretty much all authentication methods that layer on
top of TLS either have this problem or are, at the very least,
vulnerable to dictionary attack by a rogue server.  Getting secure
augmented password-based authentication right is tricky, and I think
that TLS should offer this service.

> slow (i don't know the global answer here, but i only know a few folks

I'd guess it's a chicken-and-egg problem.

> than a client with an encrypted password store, of course.

There are several ways to make this work.  For example, suppose that a
server or organization wants to accept client certificates.  It issues
to each client c some identifier I_c that identifies that client and a
randomly generated augmented PAKE "password" P_c.  The issuer remembers
V_c (the verifier corresponding to P_c) for each client.  The issuer and
all of the servers need to be able to look up (or decrypt) V_c given
I_c, but, critically, the client must store a copy of V_c or anything
that can be used to generate V_c.

The client chooses a password and stores (I_c, E_password(P_c)).  E
should be a pseudorandom permutation keyed by the password.

Now, if the client's encrypted key is stolen, an attacker cannot mount
an offline dictionary attack to recover the low-entropy password.

With TLS client authentication as it currently stands, I think it's
basically impossible to achieve this type of security.

The goal is to achieve "Type III" security in [1].

> share a password between services.

Yes, this is true, of course.  It's still an improvement over the status
quo, where a dictionary attack isn't even needed.

> points are for that authentication mechanism?

SRP is a complicated and rather slow thing that bolts on to TLS pre-1.3.
 Since the whole key exchange concept is being rethought for TLS 1.3 (or
is at least apparently up for discussion), it may be possible to have
TLS 1.3's standard key exchange be directly usable as an augmented PAKE
without any significant drawbacks.

I'll leave the details to the more serious cryptographers, but I suspect
that triple DH could actually be made to work: rather than having Alice
send (g^a, g^x), she sends ("Alice", g^x) and lets Bob look up / decrypt
g^a on his own.

If TLS 1.3 naturally supported augmented PAKE-style authentication, then
using it as as simple as setting the credentials.  This is a far cry
from the current state of affairs, which involves using arcane and
barely supported APIs in the various awful TLS implementations to try to
get SRP to work and hoping it doesn't kill performance.

> be convinced that they're more generally useful, though :)

I think that there's no real downside to using PAKE for all or almost
all authentication, not just passwords.

After all, authenticating with a traditional keypair just means that you
prove to your peer that you know a private key that corresponds to a
public key known by the peer.  Authenticating with an augmented PAKE is
exactly the same thing, with the added properties that offline
dictionary attacks are impossible (at least against low-entropy
passwords) and that the private key can be an arbitrary string.

[1] http://eprint.iacr.org/2012/120.pdf

---

From: "Ryan Sleevi" <[email-masked]>
Date: Tue, 18 Mar 2014 22:54:49 -0700

> >> is the basis of most phishing attacks.  (I'm ignoring TLS-SRP, which is

Since you raised "phishing" as your concern, I'm entirely responding
within the context that you're talking about user-facing actions within
the context of a web browser. I have yet to hear of a good mail client
"phishing" attack (you *are* validating your IMAP certs, right?), so this
seems almost predominantly an issue of attacker-controlled UI - that is,
the web.

>  I'd guess it's a chicken-and-egg problem.

No. It's really not. It's a usability problem, and one that doesn't get
solved easily.

It's not unique to TLS-SRP. It's just as applicable to TLS client
certificates.

Browsers don't want it:
- It requires the browser implement a special (trusted) UI, since by
definition, it's the browser's responsibility to terminate TLS
connections.

Sites don't want it:
- Sites don't want to force browser UI on their users, they want to
control and customize the UI. They want to handle failures, not rely on
browsers that may or may not handle errors in the manner in which they
desire.

Users don't want it:
- Users *like* sites' form-based authentication. It integrates easily with
their mental model, provides easy avenues for trouble-shooting ("forgot my
password", etc).

This is the exact same problem with client certificates.

Both solutions (TLS-SRP and client cert auth) are trying to solve
application auth issues at the transport. This doesn't work well. Heck,
even GSSAPI doesn't have a good solution for this when authenticating to
sites with SPNEGO (although the ongoing work for cred UI is exciting
stuff).

The real drive - of sites and of browsers - is trying to find ways to give
sites as much control of the UI as possible, while simultaneously reducing
the risk - of password breaches and security incidents. If you want to see
the practical efforts to "solve" the phishing problem, look at stuff like
http://fidoalliance.org/

There are still be opportunities to improve things within TLS - channel
bindings being the most obvious issue at hand.

Sites - and browsers - want assurances similar to client certs, but
without all of the countless headaches (eg: Define a reasonable way to
"Log Out" in the case of CCA when talking to a website, where you may have
N parallel connections, which may have Y TLS sessions depending on timing,
and which have a whole host of internal state full of spit-and-glue just
trying to make CCA semi-usable for HTTP)

I'm hard-pressed to find a use case for TLS-SRP in the context of the web,
nor do we hear sites really clamoring for it, and an augmented PAKE is
just same story, different day.

If you're talking outside the context of the web, then maybe there's a use
case, but my instinct is "meh". I think you'll be hard pressed to find
anyone who really loves passwords or thinks we should encourage more of
them.

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 19 Mar 2014 08:43:19 -0700

> definition, it's the browser's responsibility to terminate TLS

I think that browsers should do *exactly* this.  There's already one
for the lock icon -- adding one for password entry seems like a
natural extension.  Even better: users who use such a thing don't need
to be nearly as careful about checking the actual URL before entering
their password.

> browsers that may or may not handle errors in the manner in which they

This can be fixed.

> their mental model, provides easy avenues for trouble-shooting ("forgot my

You're assuming that an augmented PAKE with a trusted UI can't do all
of that.  If a website could request a zero-knowledge proof of
knowledge of a secret, where the secret has this description next to
it and this set of extra buttons (the buttons would be plain links and
would *not* transmit the password), I think that everyone wins.  Heck,
the whole trusted dialog could be written in HTML and, as long as the
ability to submit forms were restricted and scripts were blocked, it
should just work.

Admittedly, this doesn't really fit in to my suggestion of doing it as
part of TLS key exchange.

> the practical efforts to "solve" the phishing problem, look at stuff like

That was actually my inspiration for suggesting this feature.  Suppose
you use a second factor (e.g. Fido U2F) device to authenticate to your
bank.  You've set a PIN "1234".  An attacker subsequently steals your
U2F device.

If the device is well designed, locks out the key after a few tries,
is suitably slow rejecting bad PINs, and is truly tamper proof, then
everything is OK.  But that's a big if.

The problem is that using ECDSA signatures or anything like then in a
second factor is the wrong approach, I think.  If a second factor
instead answered an augmented PAKE challenge, it could be implemented
in such a way that it wouldn't be able to distinguish a correct PIN
from an incorrect PIN.  Then the server could lock out the account
after a few tries, and an attacker wouldn't be able to usefully attack
the device even if they completely broke its tamper protection.

This is mostly outside the scope of the TLS WG, but I think that TLS
could do a lot to make this kind of thing easier.

--Andy

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 19 Mar 2014 09:06:23 -0700

On Tue, Mar 18, 2014 at 10:54 PM, Ryan Sleevi <[email-masked]> wrote:
> I have yet to hear of a good mail client

Even for IMAP, using PAKE, augmented or balanced, would give a
significant amount of protection against MITMs who have compromised a
CA.  Since compromising a CA seems to be a popular thing to do these
days, resisting these attacks at the protocol level would add
considerable value.

--Andy

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 19 Mar 2014 09:12:56 -0700

> > On Tue, March 18, 2014 2:55 pm, Andy Lutomirski wrote:
[Snip]
>  to be nearly as careful about checking the actual URL before entering

Challenge: Go find a site using HTTP auth (of any form - BASIC, DIGEST,
etc), that wasn't built in the 1990s or a slow-moving SDO.

Ask them how they like it.

Answer: They don't. No site wants to use browser UI. It's a bad UX.

> > browsers that may or may not handle errors in the manner in which they

And the ocean can be boiled to power a giant steam engine. These are both
true statements, but both discount the huge efforts for the minimal gains
and real harm possible.

>  part of TLS key exchange.

Which was exactly my point.

>  could do a lot to make this kind of thing easier.

It's not a technological issue. It's a social/usability issue.

And the TLS WG is, arguably, one of the least suited of all WGs to solve
this.

---

From: Anders Rundgren <[email-masked]>
Date: Wed, 19 Mar 2014 17:17:01 +0100

> to be nearly as careful about checking the actual URL before entering

You want something like this?
https://communities.intel.com/community/itpeernetwork/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display

Petty yucky stuff IMO.

Anders

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

---

From: "Ryan Sleevi" <[email-masked]>
Date: Wed, 19 Mar 2014 09:20:33 -0700

>  days, resisting these attacks at the protocol level would add

Or use key pinning - http://tools.ietf.org/html/draft-ietf-websec-key-pinning

Or use DANE - https://tools.ietf.org/html/rfc6698

My point is you can see on this list archives two common threads:
- A desire to reduce, as much as possible, the complexity of TLS
- Not a lot of fondness for another PAKE

I applaud your zeal, and my hope and goal is to try to highlight that
you're trying to solve the wrong problem. On the browser side, on the site
side, and the user side - your target demographics - no one is really
saying "Aww, if only I had a PAKE! That's what my security solution
needs".

If you're still convinced that *this* is the thing that TLS is missing, I
would only encourage you to reach out and try to first come up with a
solution for "how the password gets in the browser" before trying to
figure out how the browser gets it to the server. That will at least burn
a decade of energy and enthusiasm.

Note that the solution equally fails to meet your goals, because you will
always have browsers that don't support your solution - so sites wanting
to use it will still have to support 'naked' passwords. Equally, for
browsers, there will always be sites that continue to support the <input
type="password"> authentication (not the least because it's part of
HTML5), so they will always be phishable via downgrade attacks - not of
the TLS type, but of the UX type.

So your goal of providing a more secure UI is not really achievable, and
where it is, it's not really secure.

If that's the only justification/goal for the augmented PAKE (and your
replies suggest it is), let's just save the trouble and say "meh".

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 19 Mar 2014 17:21:15 +0100

>> slow (i don't know the global answer here, but i only know a few folks
I remember that years ago, when we implemented SRP
with openssl, I was thinking about the doing same in the NSS.
Well, not enough time.

The reason was the possibility to use the database for
url/login/password

- Browsers have the user/password containers tied to some host.

- A browser can add the ciphersuite but no user in the clienthello
   if the host is not known.

- If the host is known the browser can immediately provide the
   identity (which could be encoded as hash(user@host).

- A password could also be encoded as in Steve Bellovins draft.

This leaves us at the same "inconvenience" having a pop up
for the "PIN" outside the html layer but at least one would not
send a password to a badly authenticated site?

Peter

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 19 Mar 2014 09:38:13 -0700

> https://communities.intel.com/community/itpeernetwork/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display

My copy of Thunderbird already has a perfectly usable password prompt.
 For applications like that, no password prompt change whatsoever
would be needed -- Thunderbird would just need to know which IMAP
servers use PAKE.  (This might be very easy -- Thunderbird already
autoconfigures for various providers.)

--Andy

---

From: Andy Lutomirski <[email-masked]>
Date: Wed, 19 Mar 2014 09:45:13 -0700

> Or use key pinning - http://tools.ietf.org/html/draft-ietf-websec-key-pinning

It works, but not the first time and it's tricky to do safely from the
server's POV.

> Or use DANE - https://tools.ietf.org/html/rfc6698

I've never seen anything resembling a usable implementation of DANE.
It needs a way to pull a whole DNSSEC signature chain from a DNS
server (barely supported with current software -- the CD flag can do
it, but client code doesn't seem to support that well) or using a
nonexistent TLS extension.

> - Not a lot of fondness for another PAKE

The only reason I think my suggestion is reasonable is that I think
that it could be very simple -- the main TLS key exchange be designed
to have all of the necessary cryptographic properties to be an
augmented PAKE.  People who don't want to use it can specify null
passwords.

[...]

> the TLS type, but of the UX type.

Right.  And the better websites (banks?) will offer both and users
will learn that, when they're at home, they should only use the
trusted password prompt.

> replies suggest it is), let's just save the trouble and say "meh".

Please read the other half of my original email and most of my
replies.  I think that, even when using a second factor device (e.g.
Fido, which you brought up), using an augmented PAKE style challenge
for the device could improve security.  This has no UX issue at all --
the whole technology is new, and the UI workflow suggested in the
draft specs seems like it would work just fine with an improved
challenge-response protocol.

--Andy

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Mar 2014 10:51:55 +0200

Hi, Andy

> augmented PAKE.  People who don't want to use it can specify null

I’m sure you can add a PAKE to TLS, and it’s already been done. There’s SRP.  The fact that (as you said) it is hardly used suggests that there is not much demand for it.

I would argue that at least for the web (it may be different for IMAP) the TLS layer is a really bad place to do the password exchange. The application designers at https://www.example-bank.com, even assuming that they are OK with getting a browser UI for authentication, don’t want to get that on the landing page. That page should have grand marble structures and loan offers and most important, information that is available to non-customers. You only want to pop up the browser UI after the user clicks a “Log in to my account” button.  That is hard to do in the authentication is in the TLS handshake. See a discussion about client certificates on this and the http-bis list just a couple of weeks ago.

Of course, the assumption above is bogus, because as Ryan said, application designers don’t want to use the browser UI. There is some work being done to make authentication at the HTTP layer more appealing to them (see https://www.rcis.aist.go.jp/special/MutualAuth/  There’s even a modified Firefox and a test server ), but I don’t have high hopes for this succeeding. BTW: that work is done in conjunction with a PAKE proposal for HTTP, which is not what the designers want, but it a more appropriate layer than the transport layer. Over at http-auth we are working on standardizing that http-layer PAKE, but I don’t think it will get much use.

> will learn that, when they're at home, they should only use the

Never say never, but so far getting users to avoid doing what they intended to do just because there is some weirdness has not been successful. When faced with a different UX, people will assume that the bank has made a UX revision rather than that they are being attacked. Most of the time, they would be right. If people walked away in the face of a severe UX change, Facebook would have died five times by now.

> challenge-response protocol.

The thing is, as long as the authentication happens in the application layer, none of the fancy crypto matters. If my bank implements a PAKE in the login screen using Javascript, a decent web designer can make a website that looks identical, only the passwords go in the clear to the phisher, and there is no fancy PAKE javascript. Good crypto in indistinguishable from bad crypto or no crypto at all.

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 20 Mar 2014 11:52:10 -0400

> The thing is, as long as the authentication happens in the application layer, none of the fancy crypto matters. If my bank implements a PAKE in the login screen using Javascript, a decent web desig…

This is the core of the issue for client authentication in a web
browser, i think.  Regardless of whether we're talking about PAKE or
client certs or some other mechanism, we have two choices:

Either:

A) We begin to establish a new norm for client-authentication UX that
relies on unspoofable and easily-recognizable browser chrome (with some
sort of browser-chrome logout mechanism as well), and start training
users to distrust <input type="password"/> (perhaps at first on a
site-by-site basis), taking some serious UX control away from web site
designers.

 or:

B) We continue to let web sites drive the full UX decisions, and leave
users vulnerable to phishing attacks.

option (A) is seriously hard, maybe impossible given the state of the
web.  option (B) is terrible.

TLS can help this effort by making clear recommendations for how
cryptographically strong authentication can be used, and tailoring some
of those specifications for browsers that might want to use them.

Already, we have discussions in httpbis about some additional HTTP
mechanism so that the browser can trigger cryptographic use for client
authentication in the TLS layer, and a proposed client-cert extension to
make use of them:

 https://tools.ietf.org/html/draft-thomson-tls-care
 https://tools.ietf.org/html/draft-thomson-httpbis-catch

This should provide a way for web sites to have full control over their
unauthenticated UI and have well-specified mechanism that browser chrome
can use when presenting client-authentication activity to the user.  But
Thomson's proposed scheme targets the use of client-side certs, not
PAKE.  If you really want PAKE to work as well in the HTTP context, it
seems likely to have to think through the same cases.

Perhaps the drafts above need to be modified to provide for SRP or some
other PAKE as well as client-certs so that the same communications-flow
can be used in a PAKE context at the TLS layer?  If so, why would that
be a better outcome than using PAKE directly at the HTTP layer (e.g.
https://tools.ietf.org/html/draft-ietf-httpauth-mutual) ?

	--dkg

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 20 Mar 2014 09:18:30 -0700

> users vulnerable to phishing attacks.

As an important note, you did not define "we" above. A few possible expansions would be:

- The TLS WG, where this thread currently lives, does not get to define Web UI without a charter change.

- The HTTPbis WG has not asked the TLS WG to take over this work, nor has it embraced anything like it.

- The IETF doesn't do this kind of work as a whole body.

- The IAB (of which none of us are part of the "we") might take the topic on and suggest ways which the IETF might do the work.

> web.  option (B) is terrible.

Exactly right, for any value of "we".

--Paul Hoffman

---

From: Yoav Nir <[email-masked]>
Date: Thu, 20 Mar 2014 18:24:57 +0200

> As an important note, you did not define "we" above. A few possible expansions would be:

Huh. I was about to reply “you, me, Andy, and what army?”

Seriously, we can’t establish a new norm in any forum that does not include web designers and UX people. Somewhere there are people who design the UX for people browsing Facebook, Gmail, my bank, Amazon and some web store selling dog food over the Internet. They get to decide what technology goes into the web site, and unfortunately none of them attend the meetings of any of the groups you mentioned. In fact, they don’t follow any IETF group, so we can’t even invite them all to a BoF.

Given that, I don’t think any value of “we” that belongs to the IETF can establish any norms.  I wish this was different.

Yoav

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 20 Mar 2014 12:28:41 -0400

> - The IAB (of which none of us are part of the "we") might take the topic on and suggest ways which the IETF might do the work.

yep, thanks for the clarification.  I actually meant "we" in the broad
sense of "the community of people who care about making communications
on the web more secure", which includes groups you didn't even mention
above, like web site designers, systems administrators, etc.

It's still on-topic here (despite the broad scope implied above) because
the TLS WG does have a role to play, by considering the merits of
proposals like http://tools.ietf.org/html/draft-thomson-tls-care, as
well as considering alternatives that deal with this particular use case.

> Exactly right, for any value of "we".

:(

	--dkg

---

From: Robert Cragie <[email-masked]>
Date: Thu, 20 Mar 2014 17:21:24 +0000

It should be remembered that TLS is used in places other than web browsers
- the existence of the DICE WG is testament to this. There is a lot of
interest in the IoT community in using some form of PAKE in conjunction
with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping
of IoT devices onto IoT networks. I realise this is different to the
original proposition in this thread but wanted to draw this to the
attention of the WG nevertheless.

Robert
On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <[email-masked]> wrote:

> > - The IAB (of which none of us are part of the "we") might take the
> topic on and suggest ways which the IETF might do the work.
>

---

From: Rene Struik <[email-masked]>
Date: Thu, 20 Mar 2014 21:52:37 -0400

Hi Robert:

Wouldn't it be much easier to embed device certificates with constrained 
devices at manufacturing? This may do away with need to store info that 
is not public on servers.

If you could provide some links to discussions in "IoT community groups" 
interested in this, that would help.

Best regards, Rene

==
There is a lot of interest in the IoT community in using some form of 
PAKE in conjunction with DTLS (or TLS with EAP) for authenticating 
commissioning/bootstrapping of IoT devices onto IoT networks

On 3/20/2014 1:21 PM, Robert Cragie wrote:
>
> It should be remembered that TLS is used in places other than web 
> browsers - the existence of the DICE WG is testament to this. There is 
> a lot of interest in the IoT community in using some form of PAKE in 
> conjunction with DTLS (or TLS with EAP) for authenticating 
> commissioning/bootstrapping of IoT devices onto IoT networks. I 
> realise this is different to the original proposition in this thread 
> but wanted to draw this to the attention of the WG nevertheless.
>
> Robert
>
> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     > - The HTTPbis WG has not asked the TLS WG to take over this
>     work, nor has it embraced anything like it.
>     >
>     > - The IAB (of which none of us are part of the "we") might take
>     the topic on and suggest ways which the IETF might do the work.
>
>     [email-masked] <mailto:[email-masked]>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 21 Mar 2014 04:55:50 +0100

On 2014-03-21 02:52, Rene Struik wrote:
> Hi Robert:
> 
> Wouldn't it be much easier to embed device certificates with constrained devices at manufacturing? This may do away with need to store info that is not public on servers.

+1

way to go
> 
> If you could provide some links to discussions in "IoT community groups" interested in this, that would help.
> 
> Best regards, Rene
> 
> ==
> There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks
> 
>> It should be remembered that TLS is used in places other than web browsers - the existence of the DICE WG is testament to this. There is a lot of interest in the IoT community in using some form of PAKE in conjunction with DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT devices onto IoT networks. I realise this is different to the original proposition in this thread but wanted to draw this to the attention of the WG nevertheless.
>>
>> Robert
>>
>> On 20 Mar 2014 12:28, "Daniel Kahn Gillmor" <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Mar 2014 08:26:02 -0400

Rene,

Installing device certificates during manufacturing is not a simple process - the factory would need to act as a CA or would need to have a supply of certificates that matches whatever identifiers are used by the devices.  Not to mention how you'd manage revocation if the root was compromised...

>> > Exactly right, for any value of "we".

_________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair

---

From: t.petch <[email-masked]>
Date: Fri, 21 Mar 2014 14:44:41 +0000

----- Original Message -----
From: "Michael Sweet" <[email-masked]>
To: "Rene Struik" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, March 21, 2014 12:26 PM

Rene,

Installing device certificates during manufacturing is not a simple
process - the factory would need to act as a CA or would need to have a
supply of certificates that matches whatever identifiers are used by the
devices.  Not to mention how you'd manage revocation if the root was
compromised...

<tp>

Michael

In the context of syslog security, some years ago now, the question of
device certificates arose and it was said there that they were quite
common.  They would be self-signed, which gives much of the needed
security, while avoiding issues of CA and root compromise.

Tom Petch

On Mar 20, 2014, at 9:52 PM, Rene Struik <[email-masked]> wrote:

> Hi Robert:
>
> Wouldn't it be much easier to embed device certificates with
constrained devices at manufacturing? This may do away with need
to store info that is not public on servers.
>
> If you could provide some links to discussions in "IoT community
groups" interested in this, that would help.
>> It should be remembered that TLS is used in places other than web
browsers - the existence of the DICE WG is testament to this. There is a
lot of interest in the IoT community in using some form of PAKE in
conjunction with DTLS (or TLS with EAP) for authenticating
commissioning/bootstrapping of IoT devices onto IoT networks. I realise
this is different to the original proposition in this thread but wanted
to draw this to the attention of the WG nevertheless.

---

From: Michael Sweet <[email-masked]>
Date: Fri, 21 Mar 2014 10:57:43 -0400

Tom,

Yes, self-signed device certificates are the common implementation choice and are often generated on the first use/setup of the device (simpler than doing it in the factory...)

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 21 Mar 2014 15:59:45 +0100

> security, while avoiding issues of CA and root compromise.

In that case the identity would effectively be reduced to a fingerprint
(like an SSH key) which could be printed on the outside of the device
to facilitate password-free enrollment.

This scheme is though not universally applicable because there's a
lot of devices where you actually want to know the brand as well
including for example the FIDO/Google U2F token so for most devices
I suspect you will end-up with a CA anyway.

Anders

---

From: "Max Pritikin (pritikin)" <[email-masked]>
Date: Fri, 21 Mar 2014 15:12:04 +0000

Generating keys “on the first use/setup” of the device means that first connection is unsecured. I have serious concerns about that!

Manufacturing generated credentials can be integrated into the sales process. I agree with Ander’s that binding other information to the credential is a good thing, but even if its a raw key pair (“self-signed”) the hash can still be printed onto a barcode or distributed electronically as part of the bill of sale. 

I think the best compromise is a manufacturer CA method that can be as lightweight as the manufacturer wishes. If they want to manage their CA keys poorly because of the perceived complexity they can do so. Other manufacturers can provide a more secure product. The relying parties (and the standards they rely on) can expect real certificate chains and seamlessly support products with security goals. They can tell, based on the issuing CA, something about the constrained device. 

Don’t forget too that constrained devices need a mechanism to ensure they’re bootstrapping into the correct network/management-infrastructure. To do so they need some root of trust installed prior to deployment. I’d suggest this is the same root of trust they use for software upgrades although for constrained devices perhaps many feel updates are out-of-scope. 

- max

---

From: Don Sturek <[email-masked]>
Date: Fri, 21 Mar 2014 08:14:56 -0700

Hi Michael,

One approach we used for Smart Energy Profile 2.0 (now IEEE 2030.5) is to
use IEEE 802.1ar certificates.   These are secure device identity
certificates just for authentication.   We don't support OCP on these
certificates, however, it is possible to use CRL.

The purpose is to simply authenticate the device.   If authorization is
wanted, an operational certificate or a whitelist/blacklist can be used.

Don

On 3/21/14 7:57 AM, "Michael Sweet" <[email-masked]> wrote:

>Tom,
>
>Yes, self-signed device certificates are the common implementation choice
>and are often generated on the first use/setup of the device (simpler
>than doing it in the factory...)
>
>

---

From: Robert Cragie <[email-masked]>
Date: Fri, 21 Mar 2014 15:19:03 +0000

Hi Rene,

There is certainly a place for device certificates but they are 
generally quite expensive in terms of the infrastructure needed to 
support them as Michael points out.

There are no specific links I can point to but the use case is using 
relatively short codes which are put into e.g. a home router through a 
web interface to provide steering, a basis for authenticating another 
device onto the network and a secure channel for delivery of 
configuration/bootstrapping information. WPS PIN is an example of this 
(notwithstanding its implementational flaws). Using TLS/DTLS as a basis 
provides the possibility of reuse at the application layer, which is a 
bonus for the relatively constrained devices generally considered to be 
in use in the IoT.

Robert

On 21/03/2014 12:26 PM, Michael Sweet wrote:
> process - the factory would need to act as a CA or would need to have 
> a supply of certificates that matches whatever identifiers are used by 
> the devices.  Not to mention how you'd manage revocation if the root 
> was compromised...
>
>
> On Mar 20, 2014, at 9:52 PM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi Robert:
>>
>> constrained devices at manufacturing? This may do away with need to 
>> store info that is not public on servers.
>>
>>> browsers - the existence of the DICE WG is testament to this. There 
>>> is a lot of interest in the IoT community in using some form of PAKE 
>>> in conjunction with DTLS (or TLS with EAP) for authenticating 
>>>     > - The TLS WG, where this thread currently lives, does not get
>>>     to define Web UI without a charter change.
>>>     >
>>>     > - The IAB (of which none of us are part of the "we") might
>>>     take the topic on and suggest ways which the IETF might do the work.
>>>
>> email:[email-masked]  | Skype: rstruik

---

From: Watson Ladd <[email-masked]>
Date: Fri, 21 Mar 2014 08:49:02 -0700

On Fri, Mar 21, 2014 at 8:19 AM, Robert Cragie
<[email-masked]> wrote:
> Hi Rene,
>
> There is certainly a place for device certificates but they are generally
> quite expensive in terms of the infrastructure needed to support them as
> Michael points out.
>
> relatively short codes which are put into e.g. a home router through a web
> interface to provide steering, a basis for authenticating another device
> onto the network and a secure channel for delivery of
> provides the possibility of reuse at the application layer, which is a bonus
> for the relatively constrained devices generally considered to be in use in
> the IoT.

There are drafts for AugPAKE  and J-PAKE that could be done as RFCs
relatively quickly, The reason we haven't modernized the PAKEs is the
one scheme that was presented, Dragonfly, wasn't good enough. I don't
see any reason for either AugPAKE or J-PAKE to go through.

Granted, I've not studied them in enough detail quite yet, but they
look good so far.

Sincerely,
Watson Ladd

> Installing device certificates during manufacturing is not a simple process
> - the factory would need to act as a CA or would need to have a supply of
> certificates that matches whatever identifiers are used by the devices.  Not
> to mention how you'd manage revocation if the root was compromised...
>
>
> devices at manufacturing? This may do away with need to store info that is
> not public on servers.
>
> There is a lot of interest in the IoT community in using some form of PAKE
> It should be remembered that TLS is used in places other than web browsers -
> the existence of the DICE WG is testament to this. There is a lot of
> interest in the IoT community in using some form of PAKE in conjunction with
> DTLS (or TLS with EAP) for authenticating commissioning/bootstrapping of IoT
> devices onto IoT networks. I realise this is different to the original
> proposition in this thread but wanted to draw this to the attention of the
> WG nevertheless.
>
> Robert
>

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

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 21 Mar 2014 16:03:49 +0000

> On 21 Mar 2014, at 15:50, "Watson Ladd" <[email-masked]> wrote:
> 

As far as I am aware, there's no complete formal security analysis of J-PAKE. There are claims in the original paper about the security conferred by the use of ZK proofs, and some informal security analysis (stated as theorems and proofs), but, as far as I know, there's no security proof using a recognised PAKE security model. 

Cheers

Kenny

---

From: Feng Hao <[email-masked]>
Date: Fri, 21 Mar 2014 16:43:52 +0000

Hi Kenny,

>As far as I am aware, there's no complete formal security analysis of J-PAKE.
>There are claims in the original paper about the security conferred by the use
>of ZK proofs, and some informal security analysis (stated as theorems and
>proofs), but, as far as I know, there's no security proof using a recognised
>PAKE security model.

I responded to a similar comment on the lightbluetouchpaper blog about 6 years ago:

http://www.lightbluetouchpaper.org/2008/05/29/j-pake/ (See Comment 29)

My views are basically unchanged. Meanwhile, in the past 6 years, I've been trying to search for answers of obvious questions: 1) what exact PAKE security model is the "right" model; 2) which exact PAKE protocol has been proved secure under that model and how is that protocol implemented and used in real life.

I must admit I haven't found my answers. 

Best regards,
Feng

---

From: "Paterson, Kenny" <[email-masked]>
Date: Fri, 21 Mar 2014 17:54:45 +0000

> On 21 Mar 2014, at 16:44, "Feng Hao" <[email-masked]> wrote:
> 
> Hi Kenny,
> 

The comment from Jon Katz from 6 years ago is not really that similar to mine now, but I agree with him when he describes your security analysis as being hand waving.

> My views are basically unchanged.

That's a shame. I'd have hoped you'd have learned how to use PAKE models and formal security proofs in the intervening period. 

> Meanwhile, in the past 6 years, I've been trying to search for answers of obvious questions: 1) what exact PAKE security model is the "right" model; 2) which exact PAKE protocol has been proved secure under that model and how is that protocol implemented and used in real life.

Very good. Models do evolve, and the first model is not always the "right" one. Still, the provision of some analysis in one of the several by now quite standard models would not be an unreasonable expectation if you are seriously promoting J-PAKE over the alternatives. 

> I must admit I haven't found my answers. 

Indeed. But that should not stop you (or anyone else, but it's really on you) from choosing one of the existing models and giving a proof for your protocol.

Cheers

Kenny

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 21 Mar 2014 22:24:42 +0200

> Given that, I don’t think any value of “we” that belongs to the IETF can establish any norms.  I wish this was different.

There is a (small) discipline of "security usability". For example, see 
[1]. Some things that we do have a lot to do with usability, and I think 
it's time we engaged with that community. "We" here is the SAAG 
community. This applies to PAKE, browser "padlocks" and phishing. I 
think this also applies that which shall remain unnamed, but some people 
call OE, and some other people hate them for that.

Thanks,
	Yaron

[1] https://cups.cs.cmu.edu/soups/2014/

---

From: Yaron Sheffer <[email-masked]>
Date: Fri, 21 Mar 2014 22:39:24 +0200

> days, resisting these attacks at the protocol level would add

IMAP/SMTP is a great example where PAKE could add significant security: 
CA compromise is arguably rare, but coffee-shop captive portals that 
hijack IMAP/SMTP and present their own certificate are quite common. The 
user gets a message from their mail client asking if they will accept 
this certificate, and you can guess what they'll choose... Next thing 
you know, the password is sent in the clear to the server.

Thanks,
	Yaron

---

From: Feng Hao <[email-masked]>
Date: Mon, 24 Mar 2014 11:33:04 +0000

Hi Kenny,

Thanks for your advice and expert comments.

>That's a shame. I'd have hoped you'd have learned how to use PAKE models
>and formal security proofs in the intervening period.

I've learned that the formal model analysis (or "provable security") is trickier than what I hoped to see. Maybe only time can tell if adding layers of formalism to the security proofs is really the right way to go. 

>Indeed. But that should not stop you (or anyone else, but it's really on you)
>from choosing one of the existing models and giving a proof for your protocol.

Yes, I'm not giving up on it : )

Best regards,
Feng

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 28 Mar 2014 13:11:22 -0700 (PDT)

Hi Robert,

> support them as Michael points out.

  And they only allow for an authenticated statement that the thing
is a particular thing from a particular manufacturer. Not that it is
_your_ thing.

> bonus for the relatively constrained devices generally considered to be

  Yes, WPS PIN is horribly broken and should be avoided. A TLS PAKE like
TLS-SRP or TLS-pwd would work for this use case.

  Also, usable certificate can be obtained by something like EST using
a TLS PAKE or a manufacturing certificate plus a whitelist of some sort.

  Dan.