Subject: [perpass] proposed enhancement to TLS strong authentication protocol

From: Karl Malbrain <[email-masked]>
Date: Wed, 11 Sep 2013 17:31:52 +0000

Goal: facilitate usage of TLS strong authentication over the internet to thwart MITM attacks.

Rather than have each TLS server receive user public certificates individually for strong authentication, implement a global user public certificate list hosted internationally that supplies user public certificates to TLS hosts and clients. The list would be read-only, indexed by GUID, and hosted at multiple international sites. Both TLS servers and clients could then reliably obtain public certificates by GUID for use in strong authentication challenges per the TLS protocol.

Karl Malbrain

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 11 Sep 2013 14:38:56 -0400

On Wed, Sep 11, 2013 at 05:31:52PM +0000, Karl Malbrain wrote: 
>Rather than have each TLS server receive user public certificates
>individually for strong authentication, implement a global user public
>certificate list hosted internationally that supplies user public
>certificates to TLS hosts and clients. The list would be read-only,
>indexed by GUID, and hosted at multiple international sites. Both TLS
>servers and clients could then reliably obtain public certificates by
>GUID for use in strong authentication challenges per the TLS protocol.

And how would this global public certificate directory be securely
updated?  If you simply accept valid certificates, then it doesn't
solve the rogue/comrpomised CA problem.

						- Ted

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 11 Sep 2013 18:46:09 +0000

From: Karl Malbrain 
Sent: Wednesday, September 11, 2013 11:43
To: 'Theodore Ts'o'
Subject: RE: [perpass] proposed enhancement to TLS strong authentication protocol

It's a WORM list.  Users post requests to the list maintainers they trust with a GUID to register their public key, and then send this GUID as part of the TLS negotiation process.  

-----Original Message-----
From: Theodore Ts'o [mailto:[email-masked]]
Sent: Wednesday, September 11, 2013 11:39
To: Karl Malbrain
Cc: [email-masked]
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

>GUID for use in strong authentication challenges per the TLS protocol.

And how would this global public certificate directory be securely updated?  If you simply accept valid certificates, then it doesn't solve the rogue/comrpomised CA problem.

						- Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 14:50:12 -0400

> solve the rogue/comrpomised CA problem.

The normal way this is done in practice is for every relying party to issue
their own certificates. Which completely destroys the point of using public
key.

If the issuer is going to be the only relying party you might as well use
symmetric crypto and a proof of knowledge which is what I have tried to do
in the HTTP Session ID proposal.

-- 
Website: http://hallambaker.com/

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Sep 2013 14:51:05 -0400 (EDT)

> It's a WORM list.  Users post requests to the list maintainers they trust with a GUID to register their public key, and then send this GUID as part of the TLS negotiation process.

Seems to me to be basically like an unscalable central version of the TLSA record?

https://tools.ietf.org/html/rfc6698

Paul

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 11 Sep 2013 18:56:04 +0000

The goal of the proposal is to enable the use of strong authentication for all TLS connections over the internet.  The certificates as things-in-themselves don't really matter, they are actually just a vehicle to post the public key of the user/server in a reliable public place.  The security occurs when the challenges to prove private key ownership are cross-issued by each party.  MITM would not have the private keys to answer either challenge.

Note that this still doesn't solve the problem of MITM obtaining the server's private key.  I'm still working on that one.
Karl

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Wednesday, September 11, 2013 11:50
To: Theodore Ts'o
Cc: Karl Malbrain; [email-masked]
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

On Wed, Sep 11, 2013 at 2:38 PM, Theodore Ts'o <[email-masked]<mailto:[email-masked]>> wrote:

The normal way this is done in practice is for every relying party to issue their own certificates. Which completely destroys the point of using public key.

If the issuer is going to be the only relying party you might as well use symmetric crypto and a proof of knowledge which is what I have tried to do in the HTTP Session ID proposal.

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 11 Sep 2013 19:04:56 +0000

>From a very quick read rfc 6698, what I'm doing differently is to add the ability for the TLS server to authenticate the client by using the client's registration GUID rather than DNS

Karl.

-----Original Message-----
From: Paul Wouters [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2013 11:51
To: Karl Malbrain
Cc: [email-masked]
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol

Paul

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Sep 2013 15:15:54 -0400

On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <[email-masked]> wrote:

>> It's a WORM list.  Users post requests to the list maintainers they trust
>> with a GUID to register their public key, and then send this GUID as part
>> of the TLS negotiation process.
>>
>
> https://tools.ietf.org/html/**rfc6698<https://tools.ietf.org/html/rfc6698>

I think it can be decentralized and have been working on an architecture to
do that for email security.

But it does not really help much for authentication to random Web sites or
for enterprise use either.

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 11 Sep 2013 19:23:38 +0000

The list is replicated but not centralized per-se. There is only one content. Larger servers could maintain their own copy of the replicated list for their own usage.

As to the utility of the enhancement, MITM attachments/attacks are precluded by strong authentication of both the server and the client.  The specific technical problem addressed is the ability of both parties to reliably obtain client public keys during TLS negotiation.

From: Phillip Hallam-Baker [mailto:[email-masked]]
Sent: Wednesday, September 11, 2013 12:16
To: Paul Wouters
Cc: Karl Malbrain; [email-masked]
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol

On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <[email-masked]<mailto:[email-masked]>> wrote:
On Wed, 11 Sep 2013, Karl Malbrain wrote:
From: Karl Malbrain
Sent: Wednesday, September 11, 2013 11:43
To: 'Theodore Ts'o'
Subject: RE: [perpass] proposed enhancement to TLS strong authentication protocol

I think it can be decentralized and have been working on an architecture to do that for email security.

But it does not really help much for authentication to random Web sites or for enterprise use either.

---

From: George Michaelson <[email-masked]>
Date: Thu, 12 Sep 2013 09:07:41 +1000

unscaleable is a word which had currency in 16 bit computer days, and
possibly in 32 bit computers when disks and bandwidth were untenably
expensive. I am less sure that any enterprise which only has to scale to
addressing 2 billion people in the next 5-10 years is 'unscaleable' in the
real sense of the world.

'seems very inefficient' or 'seems like a problem which will carry its own
sub-problems' or 'scaling this is a challenge which demands funding and
eyeballs' are all less direct statements going to the same place.

or do you believe UUID collide, and in fact cannot uniquely identify end
entities casting the runes to make randoms?

On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain <[email-masked]> wrote:

>  The list is replicated but not centralized per-se. There is only one
> content. Larger servers could maintain their own copy of the replicated
> list for their own usage.****
>
> ** **
>
> As to the utility of the enhancement, MITM attachments/attacks are
> precluded by strong authentication of both the server and the client.  The
> specific technical problem addressed is the ability of both parties to
> reliably obtain client public keys during TLS negotiation.****
>
> ** **
>
> *From:* Phillip Hallam-Baker [mailto:[email-masked]]
> *Sent:* Wednesday, September 11, 2013 12:16
> *To:* Paul Wouters
> *Cc:* Karl Malbrain; [email-masked]
> *Subject:* Re: [perpass] FW: proposed enhancement to TLS strong
> authentication protocol****
>
> ** **
>
> ** **
>
> ** **
>
> On Wed, Sep 11, 2013 at 2:51 PM, Paul Wouters <[email-masked]> wrote:****
>
> On Wed, 11 Sep 2013, Karl Malbrain wrote:****
>
> From: Karl Malbrain
> of the TLS negotiation process.****
>
> ** **
>
> https://tools.ietf.org/html/rfc6698****
>
> ** **
>
> I think it can be decentralized and have been working on an architecture
> to do that for email security.****
>
> ** **
>
> for enterprise use either.****
>
> ** **
>
>  ****
>
> ** **
>
> --
> Website: http://hallambaker.com/****
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>
>

---

From: Karl Malbrain <[email-masked]>
Date: Wed, 11 Sep 2013 23:14:06 +0000

UUID collisions would be handled by the list servers which would silently reject posts of user public keys to occupied UUID slots.  User's would determine this by noting that a  UUID query doesn't produce their public key, and then retry the post with a different UUID.

List servers would communicate among themselves to replicate the list globally.

Karl

From: George Michaelson [mailto:[email-masked]]
Sent: Wednesday, September 11, 2013 16:08
To: Karl Malbrain
Cc: Phillip Hallam-Baker; Paul Wouters; [email-masked]
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol

unscaleable is a word which had currency in 16 bit computer days, and possibly in 32 bit computers when disks and bandwidth were untenably expensive. I am less sure that any enterprise which only has to scale to addressing 2 billion people in the next 5-10 years is 'unscaleable' in the real sense of the world.

'seems very inefficient' or 'seems like a problem which will carry its own sub-problems' or 'scaling this is a challenge which demands funding and eyeballs' are all less direct statements going to the same place.

or do you believe UUID collide, and in fact cannot uniquely identify end entities casting the runes to make randoms?

On Thu, Sep 12, 2013 at 5:23 AM, Karl Malbrain <[email-masked]<mailto:[email-masked]>> wrote:
The list is replicated but not centralized per-se. There is only one content. Larger servers could maintain their own copy of the replicated list for their own usage.

From: Phillip Hallam-Baker [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 11, 2013 12:16
To: Paul Wouters
Cc: Karl Malbrain; [email-masked]<mailto:[email-masked]>
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol

_______________________________________________
perpass mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/perpass

---

From: Jon Callas <[email-masked]>
Date: Thu, 12 Sep 2013 06:20:59 -0700

On Sep 11, 2013, at 11:56 AM, Karl Malbrain <[email-masked]> wrote:

> The goal of the proposal is to enable the use of strong authentication for all TLS connections over the internet.  The certificates as things-in-themselves don’t really matter, they are actually just a vehicle to post the public key of the user/server in a reliable public place.  The security occurs when the challenges to prove private key ownership are cross-issued by each party.  MITM would not have the private keys to answer either challenge.
>  
> Note that this still doesn’t solve the problem of MITM obtaining the server’s private key.  I’m still working on that one.

I might be misunderstanding, but it seems to me that your global directory would allow a passive listener to fingerprint the client by sniffing in a variety of places -- near the client, near the server, or near the directory.

If you assume an attacker interested in collecting metadata about the clients, this would be suboptimal.

I may be missing something, but this sounds like it is just a global, central certificate authority, albeit one that is not actually issuing the certificates, but still assigning them GUIDs, which are by definition globally unique.

Am I indeed missing something?

	Jon

---

From: Karl Malbrain <[email-masked]>
Date: Thu, 12 Sep 2013 16:00:33 +0000

The global directory is queried once per TLS server and client pair.  This is done over a TLS strong authentication connection between the global directory server and the TLS server. The query by the TLS server and its response is encrypted. After that, the server holds onto the user's public key for future connections from the client.  There is no new centralized traffic point other than all the routers that make up the internet for passive listeners to exploit.

Under current TLS strong authentication negotiations, the server must have the client's public key uploaded to it over a secondary channel before the connection can be authenticated.  This proposal eliminates this requirement.

In essence I'm proposing doing away with reliance on the Certificates entirely.  Only public/private keys are required.

Karl

From: Jon Callas [mailto:[email-masked]]
Sent: Thursday, September 12, 2013 06:21
To: Karl Malbrain
Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; [email-masked]
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

On Sep 11, 2013, at 11:56 AM, Karl Malbrain <[email-masked]<mailto:[email-masked]>> wrote:

            Jon

---

From: Karl Malbrain <[email-masked]>
Date: Thu, 12 Sep 2013 16:05:47 +0000

Thank you for your assistance!  I had just ignored the "unscaleable" attribute in favor of additional explanation.

I would think that  the introduction of a captcha in the registration process should handle your concern about flooding the registration engines.  The registration is normally done once per creation of a user private/public key combination.

From: George Michaelson [mailto:[email-masked]]
Sent: Wednesday, September 11, 2013 17:40
To: Karl Malbrain
Subject: Re: [perpass] FW: proposed enhancement to TLS strong authentication protocol

no no, I don't think this. sorry its my english. if somebody else from sound groundings had said 'palpably wrong' I'd have expected just what you did: ask why. the 'unscaleable' hit my funny bone and got a 'this is bullshit, its the I dont want it so I'll say something to fudge it response. I just meant that HAD somebody said wrong because... or broken because.. I'd not have leapt. But they didn't, they just intruded the 'unscaleable' which frankly counts as much as 'unfashionable'

with mechanisms like UUID registration, (which has come up in APNIC) there is an attack model where you flood the registration engine with huge numbers of <new> and make it die in a ditch. we have discussed how you make the TCP lifetime exponential increase to get to the submit button, or use TLS to bind to it, so the cost on the client side is non-trivial, or do captcha or the like. none of them are very good. we've been running registry/whois for years, and periodically somebody designs a new method of business which demands we handle eg 60,000 emails for whois update of their customer more specific, every month. we survive fine, but its a challenge. you need to be mindful of this kind of non-cost

On Thu, Sep 12, 2013 at 9:30 AM, Karl Malbrain <[email-masked]<mailto:[email-masked]>> wrote:
Of course you've piqued my interest.  In what sense is this palpably broken and wrong?

slow:   No, The user's UUID for his public key is only obtained once per TLS server on first login.  After that it is stored along with the UUID on the server for use in the TLS challenge.

Subvertable:  No, Since the list is read-only, MITM attackers cannot change the user's public key to one of their own choosing.  Without the user's private key the MITM attacker cannot answer the TLS challenge from the server.  If the MITM attacker tries to change the UUID, the server will have no knowledge of the bogus client.

From: George Michaelson [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 11, 2013 16:21
To: Karl Malbrain

right. none of this seems to warrant use of the 'unscaleable' word. slow, or subvertable, or palpably broken and wrong I can go with, but unscaleable just doesn't seem to me to be applicable.

On Thu, Sep 12, 2013 at 9:14 AM, Karl Malbrain <[email-masked]<mailto:[email-masked]>> wrote:
UUID collisions would be handled by the list servers which would silently reject posts of user public keys to occupied UUID slots.  User's would determine this by noting that a  UUID query doesn't produce their public key, and then retry the post with a different UUID.

Karl

From: George Michaelson [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, September 11, 2013 16:08
To: Karl Malbrain
Cc: Phillip Hallam-Baker; Paul Wouters; [email-masked]<mailto:[email-masked]>

---

From: Karl Malbrain <[email-masked]>
Date: Thu, 12 Sep 2013 16:08:44 +0000

Another minor point:  The GUIDs are submitted with the public keys by the user to any of the registration authorities which then replicates the pairs to all the other participating co-authorities.

            Jon

---

From: Karl Malbrain <[email-masked]>
Date: Thu, 12 Sep 2013 16:24:06 +0000

The assumed attack profile is a MITM insertion into a connection stream between server and client whereby the attacker gains complete unencrypted access to all traffic over the connection, not just meta data.

TLS already has a built-in concept of "strong authentication" between server and client to defeat this attack.  It requires that the TLS server pre-obtain by some secondary channel the public key of the user.  This proposal eliminates that requirement by making the user's public keys public knowledge.

Karl

            Jon

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Sep 2013 17:46:55 +0100

Hi,

We seem to be designing this protocol one mail at a time. Could
I ask that we stop doing that and that Karl and whoever else is
minded submit an internet-draft specifying the protocol so that
it can be more easily reviewed.

Thanks,
Stephen.

PS: Karl, if you need help with the mechanics just ask me
offlist.

---

From: Karl Malbrain <[email-masked]>
Date: Thu, 12 Sep 2013 17:13:50 +0000

I was under the impression that this list was to discuss things pre-draft -- e.g. general concepts first, details later in a specific work-group.  I'm sorry if you find the piece meal approach difficult.

My  proposal in a nutshell:

1. Use TLS strong authentication between client and server on all connections over the internet to obviate MITM attacks.
2. Make users' public keys public information to obviate current TLS limitations on obtaining them.

If everyone agrees with this, we can certainly move onto a draft to work out details, and yes, I'd need assistance from that point onward.

Karl

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 09:47
To: Karl Malbrain
Cc: Jon Callas; Theodore Ts'o; [email-masked]; Phillip Hallam-Baker
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

Hi,

We seem to be designing this protocol one mail at a time. Could I ask that we stop doing that and that Karl and whoever else is minded submit an internet-draft specifying the protocol so that it can be more easily reviewed.

Thanks,
Stephen.

PS: Karl, if you need help with the mechanics just ask me offlist.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Sep 2013 18:22:33 +0100

Hi Karl,

On 09/12/2013 06:13 PM, Karl Malbrain wrote:
> I was under the impression that this list was to discuss things
> pre-draft -- e.g. general concepts first, details later in a specific
> work-group.  I'm sorry if you find the piece meal approach
> difficult.

Its not that its difficult but rather that another level of
detail might be needed before its clear if the approach could
work. (Being honest, I'm skeptical of anything that needs
every client who uses TLS have a private key, if that is what's
proposed.)

> 1. Use TLS strong authentication between client and server on all
> connections over the internet to obviate MITM attacks. 2. Make users'
> public keys public information to obviate current TLS limitations on
> obtaining them.
> 
> If everyone agrees with this, we can certainly move onto a draft to
> work out details, and yes, I'd need assistance from that point
> onward.

I'd say the overall thrust of the idea is clear(ish), but you
won't get rough consensus on something like that until after
its written down (ideally with running code), so I reckon this
is at the point where an I-D is the next step.

So if you get others who're interested and who know how to
do it, write up that I-D. (And again, if you're not sure how
to do it yourself, just ping me.)

S.

> 
> Karl
> 
> -----Original Message----- From: Stephen Farrell
> [mailto:[email-masked]] Sent: Thursday, September 12, 2013
> 09:47 To: Karl Malbrain Cc: Jon Callas; Theodore Ts'o;
> [email-masked]; Phillip Hallam-Baker Subject: Re: [perpass]
> proposed enhancement to TLS strong authentication protocol
> 
> 
> Hi,
> 
> We seem to be designing this protocol one mail at a time. Could I ask
> that we stop doing that and that Karl and whoever else is minded
> submit an internet-draft specifying the protocol so that it can be
> more easily reviewed.
> 
> Thanks, Stephen.
> 
>> The assumed attack profile is a MITM insertion into a connection
>> stream between server and client whereby the attacker gains
>> complete unencrypted access to all traffic over the connection, not
>> just meta data.
>> 
>> TLS already has a built-in concept of "strong authentication"
>> between server and client to defeat this attack.  It requires that
>> the TLS server pre-obtain by some secondary channel the public key
>> of the user.  This proposal eliminates that requirement by making
>> the user's public keys public knowledge.
>> 
>> Karl
>> 
>> From: Jon Callas [mailto:[email-masked]] Sent: Thursday,
>> September 12, 2013 06:21 To: Karl Malbrain Cc: Jon Callas; Phillip
>> Hallam-Baker; Theodore Ts'o; [email-masked] Subject: Re:
>> [perpass] proposed enhancement to TLS strong authentication
>> protocol
>> 
>> 
>> On Sep 11, 2013, at 11:56 AM, Karl Malbrain
>> <[email-masked]<mailto:[email-masked]>> wrote:
>> 
>> 
>> The goal of the proposal is to enable the use of strong
>> authentication for all TLS connections over the internet.  The
>> certificates as things-in-themselves don't really matter, they are
>> actually just a vehicle to post the public key of the user/server
>> in a reliable public place.  The security occurs when the
>> challenges to prove private key ownership are cross-issued by each
>> party.  MITM would not have the private keys to answer either
>> challenge.
>> 
>> Note that this still doesn't solve the problem of MITM obtaining
>> the server's private key.  I'm still working on that one.
>> 
>> I might be misunderstanding, but it seems to me that your global
>> directory would allow a passive listener to fingerprint the client
>> by sniffing in a variety of places -- near the client, near the
>> server, or near the directory.
>> 
>> I may be missing something, but this sounds like it is just a
>> global, central certificate authority, albeit one that is not
>> actually issuing the certificates, but still assigning them GUIDs,
>> which are by definition globally unique.
>> 
>> _______________________________________________ perpass mailing
>> list [email-masked] 
> _______________________________________________ perpass mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/perpass
> 
>

---

From: Karl Malbrain <[email-masked]>
Date: Thu, 12 Sep 2013 17:37:49 +0000

I'm not an expert in TLS -- my technical background is SRP/AES.  I thought every client already has a private key in order to negotiate with the server for a session key.

If that's not true, then yes, authentication by the server that the connection is with the client directly, and not through MITM, requires each user to have a private key.

-----Original Message-----
From: Stephen Farrell [mailto:[email-masked]] 
Sent: Thursday, September 12, 2013 10:23
To: Karl Malbrain
Cc: [email-masked]
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

Hi Karl,

On 09/12/2013 06:13 PM, Karl Malbrain wrote:
> work-group.  I'm sorry if you find the piece meal approach difficult.

Its not that its difficult but rather that another level of detail might be needed before its clear if the approach could work. (Being honest, I'm skeptical of anything that needs every client who uses TLS have a private key, if that is what's
proposed.)

> work out details, and yes, I'd need assistance from that point onward.

I'd say the overall thrust of the idea is clear(ish), but you won't get rough consensus on something like that until after its written down (ideally with running code), so I reckon this is at the point where an I-D is the next step.

So if you get others who're interested and who know how to do it, write up that I-D. (And again, if you're not sure how to do it yourself, just ping me.)

S.

> [email-masked]; Phillip Hallam-Baker Subject: Re: [perpass] proposed 
> enhancement to TLS strong authentication protocol
> 
> 
> Hi,
> 
>> stream between server and client whereby the attacker gains complete 
>> unencrypted access to all traffic over the connection, not just meta 
>> data.
>> 
>> the TLS server pre-obtain by some secondary channel the public key of 
>> the user.  This proposal eliminates that requirement by making the 
>> user's public keys public knowledge.
>> 
>> Karl
>> 
>> [perpass] proposed enhancement to TLS strong authentication protocol
>> 
>> 
>> actually just a vehicle to post the public key of the user/server in 
>> a reliable public place.  The security occurs when the challenges to 
>> prove private key ownership are cross-issued by each party.  MITM 
>> would not have the private keys to answer either challenge.
>> 
>> Note that this still doesn't solve the problem of MITM obtaining the 
>> server's private key.  I'm still working on that one.
>> 
>> directory would allow a passive listener to fingerprint the client by 
>> sniffing in a variety of places -- near the client, near the server, 
>> or near the directory.
>> 
>> I may be missing something, but this sounds like it is just a global, 
>> central certificate authority, albeit one that is not actually 
>> issuing the certificates, but still assigning them GUIDs, which are 
>> by definition globally unique.
>>

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Sep 2013 20:13:47 +0200

> If that's not true, then yes, authentication by the server that the connection is with the client directly, and not through MITM, requires each user to have a private key.
I believe Stephen is asking you to spell out details like that in an
internet-draft. I would also like to move on to other things while we
wait for that draft to appear.

    thx /leif

---

From: karl m <[email-masked]>
Date: Thu, 12 Sep 2013 11:37:02 -0700 (PDT)

Leif,
 
I don't own the technical ability to spell out specific changes to the TLS strong authentication protocol needed to implement the proposed changes.  I've only been exposed to this as a client to a strong authentication server.
 
I had hoped to open a general discussion on the topic of strong authentication for every connection to every server as a means to preclude MITM.  Do you have any input on that?
 
Thanks,
Karl

________________________________
 From: Leif Johansson <[email-masked]>
To: [email-masked] 
Sent: Thursday, September 12, 2013 11:13 AM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication	protocol

    thx /leif

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Sep 2013 08:36:08 +0200

On 09/12/2013 08:37 PM, karl m wrote:
> Leif,
>  
> I don't own the technical ability to spell out specific changes to the
> TLS strong authentication protocol needed to implement the proposed
> changes.  I've only been exposed to this as a client to a strong
> authentication server.
>  
> I had hoped to open a general discussion on the topic of strong
> authentication for every connection to every server as a means to
> preclude MITM.  Do you have any input on that?
>
Only that the devil is in the details. I think most on this list
recognize that "encryption
is a problem of turning a hard problem into a hard key management
problem" and
that your proposal leaves several problems to the imagination of the
reader, including
how to build a multi-master globally scalable directory of keys and GUIDS.

I think that while you try to spell out some of those things, the list
can do other things
so I re-iterate Stephens point: go write a draft please.

        Cheers Leif

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 13:00:32 -0700 (PDT)

I've prepared an ID and have submitted it as a draft to IETF for publication.  In the interim I've attached a pdf version to this message.
 
I've dropped the idea of including both client and server public certificates in the directory in favor of a server certificate only repository with an additional TLS interface to authorize access by clients.
 
Karl

________________________________
 From: Leif Johansson <[email-masked]>
To: karl m <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Thursday, September 12, 2013 11:36 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication	protocol

Leif, 
>I had hoped to open a general discussion on the topic of strong authentication for every connection to every server as a means to preclude MITM.  Do you have any input on that? 
Only that the devil is in the details. I think most on this list recognize that "encryption
is a problem of turning a hard problem into a hard key management
    problem" and
that your proposal leaves several problems to the imagination of the
    reader, including 
how to build a multi-master globally scalable directory of keys and
    GUIDS.

I think that while you try to spell out some of those things, the
    list can do other things
so I re-iterate Stephens point: go write a draft please.

        Cheers Leif

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 13:40:04 -0700 (PDT)

I'm not familiar with DANE.  Is it operational?  Does it include changes to TLS to accept/compare the server's certificate obtained from DANE?  If so, then that part of the proposal can be mooted in favor of DANE.
 
Yes, it would be simpler to offload the certificate sourcing management to DNS.  However, I'm proposing changes to be implemented entirely within TLS, that are transparent on the client side.  Only the server side would require an additional interface to accept/reject client connections.
 
Karl

________________________________
 From: Randy Bush <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: Leif Johansson <[email-masked]> 
Sent: Friday, September 13, 2013 1:24 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

[ off lst ]

> I've dropped the idea of including both client and server public
> certificates in the directory in favor of a server certificate only
> repository with an additional TLS interface to authorize access by
> clients.

so why is this a win over dane?

randy

---

From: Leif Johansson <[email-masked]>
Date: Fri, 13 Sep 2013 23:05:54 +0200

On 09/13/2013 10:40 PM, Karl Malbrain wrote:
> I'm not familiar with DANE.  Is it operational?  Does it include
> changes to TLS to accept/compare the server's certificate obtained
> from DANE?  If so, then that part of the proposal can be mooted in
> favor of DANE.
>
The DNS is quite operational and nothing stops anyone from publishing
TLSA records right this second.
> Yes, it would be simpler to offload the certificate sourcing
> management to DNS.  However, I'm proposing changes to be implemented
> entirely within TLS, that are transparent on the client side.  Only
> the server side would require an additional interface to accept/reject
> client connections.
There have been credible arguments from browser vendors against any
scheme that involves
an in-page-rendering lookup to an external service that takes more than
a few milliseconds
because of the adverse effect on usability.

Granted, TLS is about much more than the web but its still a major use-case.

I suspect that any scheme that will have any chance of success must
involve pre-computing
some form of proof on the server-side that can be stapled onto the TLS
connection.

Also you seem to focus on the client authenticating to the server which
quite frankly could make the
privacy story worse.
>  
> Karl
>
> *From:* Randy Bush <[email-masked]>
> *To:* Karl Malbrain <[email-masked]>
> *Cc:* Leif Johansson <[email-masked]>
> *Sent:* Friday, September 13, 2013 1:24 PM
> *Subject:* Re: [perpass] proposed enhancement to TLS strong
> authentication protocol
>
> [ off lst ]
>

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 14:30:59 -0700 (PDT)

Great news.  Then all that is needed is a post connection exchange comparison in the client between the server certificate used by TLS and the one obtained from DANE.
 
As to simple HTTP content servers, the use of the client authentication interface is optional.  If there is no interface handler installed, the TLS package goes ahead and allows the connection.
 
Note, for HTTP content servers that desire to authenticate client connections as MITM free themselves, the in-page-rendering lookup is not to an external source -- it's to the servers own account record where a secure hash of the client certificate is stored during account creation.
 
However for servers that act as client agents over some domain, the server will track whether the authenticated user certificate "owns" the account or is an unrecognized user, and preclude hacking the server by guessing account names and passwords, etc.
 
Yes, with DANE in place, this proposal is now entirely focused on authentication by the server of clients.
 
Karl

________________________________
 From: Leif Johansson <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: Randy Bush <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, September 13, 2013 2:05 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication	protocol

The DNS is quite operational and nothing stops anyone from publishing TLSA records right this second.

Yes, it would be simpler to offload the certificate sourcing management to DNS.  However, I'm proposing changes to be implemented entirely within TLS, that are transparent on the client side.  Only the server side would require an additional interface to accept/reject client connections.  
There have been credible arguments from browser vendors against any scheme that involves
an in-page-rendering lookup to an external service that takes more
    than a few milliseconds
because of the adverse effect on usability.

Granted, TLS is about much more than the web but its still a major
    use-case.

I suspect that any scheme that will have any chance of success must
    involve pre-computing 
some form of proof on the server-side that can be stapled onto the
    TLS connection. 

Also you seem to focus on the client authenticating to the server
    which quite frankly could make the
privacy story worse.

>Karl 
>
> 
>From: Randy Bush mailto:[email-masked]
>To: Karl Malbrain mailto:[email-masked] 
>Cc: Leif Johansson mailto:[email-masked]

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 14:48:33 -0700 (PDT)

Sorry, I mis-read your "browser-vendor" concern section as "server" vendor.
 
The browser should be able to cache the TLSA record on the local machine.
 
Karl

________________________________
 From: Karl Malbrain <[email-masked]>
To: Leif Johansson <[email-masked]> 
Cc: "[email-masked]" <[email-masked]> 
Sent: Friday, September 13, 2013 2:30 PM
Subject: Re: [perpass] proposed enhancement to TLS strong	authentication	protocol

 

 
Karl

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Sep 2013 11:52:03 -1000

> Great news.  Then all that is needed is a post connection exchange
> comparison in the client between the server certificate used by TLS
> and the one obtained from DANE.

yes, that is what dane clients do

> authentication by the server of clients.

though occasionally useful, it is not necessarily a good idea in the
privacy context

randy

---

From: Oliver Gasser <[email-masked]>
Date: Sat, 14 Sep 2013 00:02:25 +0200

On 09/13/2013 11:48 PM, Karl Malbrain wrote:
> *From:* Karl Malbrain <[email-masked]>
> *To:* Leif Johansson <[email-masked]>
> *Cc:* "[email-masked]" <[email-masked]>
> *Sent:* Friday, September 13, 2013 2:30 PM
> comparison in the client between the server certificate used by TLS and
> the one obtained from DANE.
>  
> As to simple HTTP content servers, the use of the client authentication
> interface is optional.  If there is no interface handler installed, the
> TLS package goes ahead and allows the connection.
>  
> Note, for HTTP content servers that desire to authenticate client
> connections as MITM free themselves, the in-page-rendering lookup is not
> to an external source -- it's to the servers own account record where a
> secure hash of the client certificate is stored during account creation.
>  
> However for servers that act as client agents over some domain, the
> server will track whether the authenticated user certificate "owns" the
> account or is an unrecognized user, and preclude hacking the server by
> guessing account names and passwords, etc.

If I understand correctly, you want to dynamically create client
certificates and then check the client certificate information in
combination with a user's login name and password.
What happens if a user accesses a site from different devices/clients?
What about sites where users don't log in at all?

> *From:* Leif Johansson <[email-masked]>
> *Cc:* Randy Bush <[email-masked]>; "[email-masked]" <[email-masked]>
> *Sent:* Friday, September 13, 2013 2:05 PM
>> *From:* Randy Bush mailto:[email-masked]
>> *To:* Karl Malbrain mailto:[email-masked]
>> *Cc:* Leif Johansson mailto:[email-masked]
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 Sep 2013 18:03:24 -0400

On Sep 13, 2013, at 4:40 PM, Karl Malbrain <[email-masked]> wrote:

> I'm not familiar with DANE.  Is it operational?  

Yes, it is just not widely (enough) deployed. There are some browser extensions and a browser (Bloodhound) that has support built in. There are good tools to generate the DANE (TLSA) records, and e.g registro.br has a simple one click "generate and publish a TLSA record" record for hosted DNS customers.

It is gaining traction in mail / SMTP, with support in Postfix.

At the moment one of the main deployment hurdles is browser support (and more DNSSEC deployment!).
Browsers (understandably) don't want to be waiting on TLSA records -- latency is really important for browsers, and waiting for more DNS lookups takes time.

A few solutions have been discussed / suggested, such as only doing DANE for self-signed certs, doing the TLSA lookup in parallel with the regular lookup and making the normal connection, then aborting it (and replacing the page with a notice) if DANE shows evidence of shennanigans and / or caching TLSA records.

W

> Does it include changes to TLS to accept/compare the server's certificate obtained from DANE?  If so, then that part of the proposal can be mooted in favor of DANE.
>  

--
Hope is not a strategy.
      --  Ben Treynor, Google

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 15:09:50 -0700 (PDT)

Most https protected channels are to servers with some sort of agency on behalf of the client.  My bank account connection for example allows anyone in the universe to try to hack into my account by guessing the account name and password.  If this connection were authenticated through my public certificate to my private key I, and the bank, wouldn't have to worry anywhere near as much as I do now due to the extra layer of security being offered.
 
Portability of the private key to a new platform can be a concern to be addressed independently.  In my case I only access my account from a single computer. Theft of the computing device would be a threat vector.
 
There is also the question of due dilligence on behalf of server operators that information being transmitted over the connection cannot be eavedropped by MITM style intrusion to third parties.
 
Karl

________________________________
 From: Randy Bush <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: Leif Johansson <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, September 13, 2013 2:52 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

randy

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 15:16:06 -0700 (PDT)

Yes, I'm proposing that clients protect themselves by creating self-signed security certificates, and that servers engage in due dillegence to ensure connections are MITM free.
 
Widespread deployment of DANE registries of server certificates is also required.
 
If the client wishes to operate on multiple devices, they would need their public/private key pairs installed on each device.
 
The login to upstream applications is mostly independent of the TLS connection, except for a new interface where the upstream application can participate in rejecting the TLS connection if they have no record of the client certificate belonging to any acccounts in the server's control.
 
Karl

________________________________
 From: Oliver Gasser <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: Leif Johansson <[email-masked]>; "[email-masked]" <[email-masked]> 
Sent: Friday, September 13, 2013 3:02 PM
Subject: Re: [perpass] proposed enhancement to TLS	strong	authentication	protocol

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Sep 2013 12:17:23 -1000

> Most https protected channels are to servers with some sort of agency
> on behalf of the client.

not today, and less and less in the future if the efforts here make
progress

randy

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 15:19:09 -0700 (PDT)

Doesn't DANE produce the server's certificate in the same connection that DNS produces the servers IP address?  If not, that's an optimization that's needed.

Karl

________________________________
 From: Warren Kumari <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: Randy Bush <[email-masked]>; Leif Johansson <[email-masked]>; "[email-masked]" <[email-masked]>; Warren Kumari <[email-masked]> 
Sent: Friday, September 13, 2013 3:03 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication	protocol

W

--
Hope is not a strategy.
      --  Ben Treynor, Google

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 15:25:00 -0700 (PDT)

Well, the interface implementation to authorize authenticated clients is optional.  Static http content servers don't necessarily have to keep track of their clients yet want a secure channel to transmit content choices privately.
 
I'm primarily addressing application servers like google mail, your bank, etc.  The ones who need authentication.
 
Karl

________________________________
 From: Randy Bush <[email-masked]>
To: Karl Malbrain <[email-masked]> 
Cc: perpass <[email-masked]> 
Sent: Friday, September 13, 2013 3:17 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication	protocol

randy

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 Sep 2013 19:03:51 -0400

On Sep 13, 2013, at 6:19 PM, Karl Malbrain <[email-masked]> wrote:

> Doesn't DANE produce the server's certificate in the same connection that DNS produces the servers IP address?

Nope. 

>  If not, that's an optimization that's needed.

Would be nice, but, unfortunately DNS doesn't really allow you to return answers to questions that the client didn't ask…

There are all sorts of sexy (and dangerous :-)) things that you could do if it did...
E.g. - if a client asks for the A record for www.example.com they are presumably trying to reach my webserver and render a page --  which contains images from images.example.com and some ads from www.punchthemonkey.com, so I would like to be able to return:

www.example.com   600 IN A 192.0.2.2
images.example.com 600 IN A 192.0.2.3
www.punchthemonkey.com 600 A 192.0.2.100.

Or, even just returning MX responses in addition to A and AAA… 

W

-- 
With Feudalism, it's your Count that votes.

---

From: Karl Malbrain <[email-masked]>
Date: Fri, 13 Sep 2013 16:35:20 -0700 (PDT)

Warren,
 
Since my proposal is now hooked to the widespread deloyment of DANE, and if DANE is being hindered by an ancient DNS protocol that requires multiple connections to secure a  server's certificate and IP address, I'll have to include an item for DNS 2.0 that allows for multiple commands and multiple reponses in a simple cpio like data stream.
 
Thanks for your help!!
Karl Malbrain

Sent: Friday, September 13, 2013 4:03 PM

Nope. 

W

---

From: Yoav Nir <[email-masked]>
Date: Sat, 14 Sep 2013 04:10:27 +0000

Hi

I don't think that's necessary. DNS queries are usually done over UDP, so there's no "connection", just an extra round-trip. And for the most part, the DNS server is very close to the client, so those are not very expensive round-trips. And you can make multiple requests in the same message. What Warren is suggesting is that the DNS gratuitously return records you might want soon, which would require the DNS to know a lot about the website, so I don't think it's a worthwhile optimization.

Yoav

On Sep 14, 2013, at 2:35 AM, Karl Malbrain <[email-masked]<mailto:[email-masked]>> wrote:

Warren,

Thanks for your help!!
Karl Malbrain
From: Warren Kumari <[email-masked]<mailto:[email-masked]>>
To: Karl Malbrain <[email-masked]<mailto:[email-masked]>>
Cc: Randy Bush <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Warren Kumari <[email-masked]<mailto:[email-masked]>>
Sent: Friday, September 13, 2013 4:03 PM
Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol

Nope.

There are all sorts of sexy (and dangerous :-)) things that you could do if it did...
E.g. - if a client asks for the A record for www.example.com<http://www.example.com> they are presumably trying to reach my webserver and render a page --  which contains images from images.example.com<http://images.example.com> and some ads from www.punchthemonkey.com<http://www.punchthemonkey.com>, so I would like to be able to return:

www.example.com<http://www.example.com>  600 IN A 192.0.2.2
images.example.com<http://images.example.com> 600 IN A 192.0.2.3
www.punchthemonkey.com<http://www.punchthemonkey.com> 600 A 192.0.2.100.

W

>
>
> Karl
> From: Warren Kumari <[email-masked]<mailto:[email-masked]>>
> To: Karl Malbrain <[email-masked]<mailto:[email-masked]>>
> Cc: Randy Bush <[email-masked]<mailto:[email-masked]>>; Leif Johansson <[email-masked]<mailto:[email-masked]>>; "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>; Warren Kumari <[email-masked]<mailto:[email-masked]>>
> On Sep 13, 2013, at 4:40 PM, Karl Malbrain <[email-masked]<mailto:[email-masked]>> wrote:
>
> Yes, it is just not widely (enough) deployed. There are some browser extensions and a browser (Bloodhound) that has support built in. There are good tools to generate the DANE (TLSA) records, and e.g registro.br<http://registro.br> has a simple one click "generate and publish a TLSA record" record for hosted DNS customers.
>
> > From: Randy Bush <[email-masked]<mailto:[email-masked]>>
> > To: Karl Malbrain <[email-masked]<mailto:[email-masked]>>
> > Cc: Leif Johansson <[email-masked]<mailto:[email-masked]>>

---

From: manning bill <[email-masked]>
Date: Sat, 14 Sep 2013 05:34:36 -0700

its not at all clear that the DNS service is "close" to the client - the last two studies indicate that DNS service is usually tied to a business relationship or a trust relationship.
this will only increase with the lack of DNSSEC validation in the end system.  as for prefetching,  one -could- prefetch, I guess, but that would still be the normal query/response
unless one were to redesign the DNS protocol…  

/bill

On 13September2013Friday, at 21:10, Yoav Nir wrote:

> On Sep 14, 2013, at 2:35 AM, Karl Malbrain <[email-masked]> wrote:
> 
>> Warren,
>>

---

From: Warren Kumari <[email-masked]>
Date: Mon, 16 Sep 2013 11:11:24 -0400

> I don't think that's necessary. DNS queries are usually done over UDP, so there's no "connection", just an extra round-trip. And for the most part, the DNS server is very close to the client, so th…

Whoa there…

I wasn't really suggesting that the DNS do that -- just that if it *did* there would be a bunch of other things / optimizations that it would enable (including in the example I included, poisoning :-)) 

As to if it *should* -- well, maybe… but there would need to be a bunch of additional protection -- such as being in bailiwick, signed, preferably at the same level, etc.
Oh yes, there is also the whole legacy issue, larger responses (so better amplification, etc). 

Don't hold your breath on a draft..

W

--
The above email is neither interesting or relevant, but at least it provided no new information.