Subject: [websec] HASTLS and client policy preference

From: Paul Hoffman <[email-masked]>
Date: Sun, 26 Dec 2010 16:04:06 -0800

Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear more from folks, especially those who like the current semantics in draft-hodges-strict-transport-sec. The new draft is at <http://tools.ietf.org/html/draft-hoffman-server-has-tls-02>, and the diffs from the last draft are at <http://tools.ietf.org/rfcdiff?url2=draft-hoffman-server-has-tls-02.txt>.

FWIW, I don't think that draft-hoffman-server-has-tls formally belongs in either DANE or WEBSEC, and will probably try to move it into the AppsArea WG in the new year, but if folks want to comment before then, that's great.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Mon, 27 Dec 2010 16:52:34 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Paul Hoffman
> 
> Greetings again. I still don't like the idea of a host asserting a client policy
> preference, but I hear many folks wanting it. I think I have added it cleanly in
> draft-hoffman-server-has-tls-02, but I'm not sure and would like to hear
> more from folks, especially those who like the current semantics in draft-
> hodges-strict-transport-sec. The new draft is at
> <http://tools.ietf.org/html/draft-hoffman-server-has-tls-02>, and the diffs
> from the last draft are at <http://tools.ietf.org/rfcdiff?url2=draft-hoffman-
> server-has-tls-02.txt>.

A few thoughts.

1. I think it would be useful in the security considerations to discuss (briefly?) the MITM threat model at play here.  You discuss it in the context of delivery of the DNS data itself, but not the motivation for this proposal in the first place.  A major motivation is the MITM attack against the non-TLS version of a protocol.

2. Do you have any examples of CFB apps?  A few clients such as Mozilla's Thunderbird when in "discovery" mode will try this, but it isn't very common in my experience, and it would be good to have a few examples I could think about.

3. We argues a lot when working on HSTS about the proper behavior of a server supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic to HTTPS.  You come down on the MUST front in this proposal, at least philosophically. Some sites (well, 1 anyway) have chosen not to. I won't go into the details, and it isn't a major issue.

4. One way in protocols that don't support redirects to also indicate to a client that it should not communicate "insecurely" is with error codes.  POP/IMAP can both do this with error codes, some of which are usually shown to the user (in some implementations).  So, though they don't support protocol-level "redirects" like HTTPS, then still allow signaling to the client albeit in a non-automated way.

5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal.  If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc.  I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS.  It seems to me that they are slighty different, and co-mingling them doesn't seem quite right.   

Related to #5, the biggest protocol in our minds that is problematic wrt sslstrip-type attacks is HTTP/HTTPS, because it is the one protocol that where non fully qualified names, URI(L?)'s are entered, and where the browser has some of its own converting between names and protocols that go on.  It  is also the one protocol most easily MITM'd in a lot of ways, because much of the web is HTTP, and active attackers can easily insert references to resources causing the client to retrieve them.  The same isn't true of most other protocols such as IMAP.  Which isn't to say that this proposal isn't a good idea for IMAP, its just that IMAP/POP aren't quite so ripe for abuse generally.

---

From: "Steingruebl, Andy" <[email-masked]>
Date: Tue, 28 Dec 2010 09:25:22 -0700

> From: Paul Wouters [mailto:[email-masked]]
 
> Though I blieve the HASTLS record should not become the "legitimate open
> port list" of a host though, people should not trust clients to adhere to
> HASTLS for their server security, and instead have proper firewall policies.
> 
> Personally, I would prefer not to have to build a list of insecure ports if I have
> no secure version of it available, but then again I would expect any client that
> can do HASTLS to be able to do the secure version anyway. And for new
> protocols to not come out with an insecure version.
> 
> Perhaps it makes sense to rename HASTLS to something else. TLSSTAT?
> STATTLS? TLSAVAIL?

The idea I've been toying around with is actually changing how service lookups happen.  I don't have a well-formulated idea yet but it seems that just as many protocols/applications (I struggle for the right word here) do SRV lookups, maybe we ought to somehow bundle the TLS preference into that lookup scheme.   If we did, we could tackle the keys-in-dns problem and has/requires-TLS problem in the same SRV lookup.  HASTLS would be a part of looking up the properties of a service you're about to connect to.

I'm more than a little inexperienced with existing SRV lookups, so can't quite articulate how I think this would best work.

- Andy

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 28 Dec 2010 17:04:32 +0000

I think that is a great idea.

SRV and extended discovery in general can deliver advantages in addition to
security.

I have found persuading people to change protocol behavior for the sake of
security alone to be very hard. SRV offers potential reliability and
performance benefits. Which makes it much easier to get adoption.

On Tue, Dec 28, 2010 at 4:25 PM, Steingruebl, Andy <
[email-masked]> wrote:

> The idea I've been toying around with is actually changing how service
> lookups happen.  I don't have a well-formulated idea yet but it seems that
> just as many protocols/applications (I struggle for the right word here) do
> SRV lookups, maybe we ought to somehow bundle the TLS preference into that
> lookup scheme.   If we did, we could tackle the keys-in-dns problem and
> has/requires-TLS problem in the same SRV lookup.  HASTLS would be a part of
> looking up the properties of a service you're about to connect to.
>
> I'm more than a little inexperienced with existing SRV lookups, so can't
> quite articulate how I think this would best work.
>
> - Andy
> _______________________________________________
> keyassure mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/keyassure
>

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

---

From: Paul Wouters <[email-masked]>
Date: Sun, 26 Dec 2010 22:16:20 -0500 (EST)

> Greetings again. I still don't like the idea of a host asserting a client policy preference, but I hear many folks wanting it. I think I have added it cleanly in draft-hoffman-server-has-tls-02, bu…

I'm not sure if CIO/CSO/CFB are still described properly, because it is
no longer a "client type" but it depends on the particular tripplet.

For instance, if we have IN HASTLS (25 25 0 80 443 1) then what would you
call the "server" or the matching "client"? They are CFB/SFB for some protocols
and CSO/SSO for other protocols.

 	1 -- If the client could be configured as either CFB or CSO, and
 	the host's administrator was able to configure the client, that
 	administrator would configure the client as CSO. Stated another
 	way, the host's administrator does not want any CFB client to
 	access the host.

This should probably have some "protocol" modifiers added, eg

 	1 -- If the client could be configured as either CFB or CSO for a
         particular service tripplet, and ..."

Perhaps it should also be stated that the client policy preference MUST be
0 if either the secure or insecure port is specified as 0.

Other then that, the changes address all my issues. Thanks!

Paul

---

From: Paul Wouters <[email-masked]>
Date: Mon, 27 Dec 2010 21:35:02 -0500 (EST)

> 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal.  If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it list…

You are somewhat right.

For services where you have no secure/TLS version, their entries could
simply be omitted and not be part of the HASTLS record.  That is, you
could not specify:

 	insecure.org. IN HASTLS (80 0 0 25 25 1)

but instead:

 	insecure.org. IN HASTLS (25 25 1)

An exception might be if you want to prevent clients from connecting to
you at all, by specifying

 	insecure.org. IN HASTLS ()

Though I blieve the HASTLS record should not become the "legitimate
open port list" of a host though, people should not trust clients to
adhere to HASTLS for their server security, and instead have proper
firewall policies.

Though I think Paul Hoffman would prefer the first entry over the second
one. Though all records, including not having a HASTLS record at all,
should have the same effect for clients supporting this RRTYPE. Though
they could decided there is nothing on port 80 and refuse to even try
in the latter two examples.

Personally, I would prefer not to have to build a list of insecure ports
if I have no secure version of it available, but then again I would
expect any client that can do HASTLS to be able to do the secure version
anyway. And for new protocols to not come out with an insecure version.

Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? STATTLS? TLSAVAIL?

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:16 -0800

> 1. I think it would be useful in the security considerations to discuss (briefly?) the MITM threat model at play here.  You discuss it in the context of delivery of the DNS data itself, but not the…
Good call, yes.
> 2. Do you have any examples of CFB apps?
Many. Most SMTP servers, for example. Many POP and IMAP clients. Many 
SIP clients. And so on.
> A few clients such as Mozilla's Thunderbird when in "discovery" mode will try this, but it isn't very common in my experience, and it would be good to have a few examples I could think about.
You are focusing on "current web", not "TLS".
> 3. We argues a lot when working on HSTS about the proper behavior of a server supporting HSTS and whether it SHOULD or MUST redirect all HTTP traffic to HTTPS.  You come down on the MUST front in this proposal, at least philosophically.
If I did, it was a mistake. I don't see where I do so.
> Some sites (well, 1 anyway) have chosen not to. I won't go into the details, and it isn't a major issue.
I think both policies are reasonable.
> 4. One way in protocols that don't support redirects to also indicate to a client that it should not communicate "insecurely" is with error codes.  POP/IMAP can both do this with error codes, some…
The POP and IMAP error codes are too obtuse to show to end users.
> 5. Maybe this came up earlier but I'm still slightly confused on overall semantics of this proposal.  If HASTLS is about TLS, it is odd to me that it should talk about non-TLS policy, where it listens "insecurely", etc.
Any client-server protocol that does not require TLS all the time will 
have instances where the server is insecure. Some clients will want to 
know if a server is even offering the non-TLS version; if not, it will 
never try to go to the non-secure port on that server.
> I have a few thoughts on the general topic of service discovery, but HASTLS seems to bundle two ideas together: a) service discovery and b) whether/how that service operates with TLS.  It seems to me that they are slighty different, and co-mingling them doesn't seem quite right.
HASTLS is *not* about service discovery at all. The spec states "Setting 
both the "insecure-port" and "secure-port" to 0 in a porttriple is 
explicitly undefined", but that maybe should be strengthened to a 
prohibition.
> Related to #5, the biggest protocol in our minds that is problematic wrt sslstrip-type attacks is HTTP/HTTPS, because it is the one protocol that where non fully qualified names, URI(L?)'s are ente…
I understand your emphasis on TLS, but there is a much bigger world out 
there, and attacks in that world are just as serious. If one security 
extension can cover multiple server protocols, that would be good, I think.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:27 -0800

>     insecure.org. IN HASTLS (25 25 1)
This does not tell an HTTP client that is CIO or CFB that there is, in 
fact, a server at port 80. Why do you want to prevent them from knowing 
that?
>     insecure.org. IN HASTLS ()
That is prohibited by the spec, on purpose.
> adhere to HASTLS for their server security, and instead have proper
Correct.
> in the latter two examples.
Yes, that's a reasonable policy.
> anyway. And for new protocols to not come out with an insecure version.
Both those expectations are probably unwise. The first assumes that all 
clients that use HASTLS want to do TLS; some won't. The second assumes 
that all applications will use TLS for security, which is probably unwise.
> Perhaps it makes sense to rename HASTLS to something else. TLSSTAT? 
Bikeshed.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 28 Dec 2010 16:55:34 -0800

> no longer a "client type" but it depends on the particular tripplet.
The client still gets to decide what its policy is. It gets to decide 
whether or not it conforms to the HASTLS semantics.
> call the "server" or the matching "client"?
I don't understand the question. There is an SMTP server and an HTTP 
server. The system requesting the information might have clients for 
both, either, or none.
> They are CFB/SFB for some protocols
IN the above, if there is an SMTP client, it could be either CSO, CFB, 
or CIO.
>         particular service tripplet, and ..."
Good point, yes. I'll add that in the next draft.
> 0 if either the secure or insecure port is specified as 0.
I don't think so. This can lead to some silly states, like if you 
specify "1" and the TLS-based service goes down for some reason. I said 
in the sentence following what you quoted above:
    Note that specifying 1 for the client policy preference when a host
    does not support a protocol securely makes no sense, but it also does
    no harm.
I still believe that is true.
> Other then that, the changes address all my issues. Thanks!
Glad to hear it.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 29 Dec 2010 13:32:51 +0000

On 29 December 2010 05:26, Paul Wouters <[email-masked]> wrote:
> On Tue, 28 Dec 2010, Paul Hoffman wrote:
>
> Actually, one more question. You wrote in section 2:
>
>        An example of a hash for a single certificate:
>
>        www.example.com. IN TLSA 1 2 AgHne3GdTpxjwLCgMzvgpBiOSQthjg==
>
> The hash type here is 2, and you refer to
> http://www.iana.org/assignments/tls-parameters
> which refers to http://tools.ietf.org/html/rfc5246 for sha1, but I did not
> find that RFC
> (about TLS) mentioning anything about encoding of the hash.
>
> The above listed encoding seems to not have enough characters to be a base64
> string of a sha1 hash,

It is 30 characters, + 2 padding, which seems just about right to me.

> so I'm a little confused what you generated. Which
> means it should probably get a better explanation in the text.
>
> Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 28 Dec 2010 21:16:52 -0500 (EST)

On Tue, 28 Dec 2010, Paul Hoffman wrote:

> The client still gets to decide what its policy is. It gets to decide whether 
> or not it conforms to the HASTLS semantics.

I meant (as below) that a client type now belongs to a service tripplet.

> I don't understand the question.

Same here

> IN the above, if there is an SMTP client, it could be either CSO, CFB, or 
> CIO.

I meant to talk about servers in this aspect, because based on the HASTLS record
we know what the server is. And they can be CFB for some and SFB for others,
depending on service tripplet.

> I don't think so. This can lead to some silly states, like if you specify "1" 
> and the TLS-based service goes down for some reason.

If either the insecure or the secure service is 0 (but not both), it means
HASTLS compliant clients will only have one way to connect. So there is no
"preference". You can only connect to the one secure or insecure port.

> I said in the sentence  following what you quoted above:

But it does no good either. In some sense, it is "lying" because there can be
no preference. Imagine an implementation first checks the 5th byte, and then
blindly assumes there is a secure and insecure version (why else list the
preference as 1) and then picking the secure version, while the HASTLS record
stated (80 0 1) and there is none.

I would still say, preference SHOULD or MUST be 0 if the service is only offered
with one method.

>> Other then that, the changes address all my issues. Thanks!

Thanks for your work on this!

Paul

---

From: Paul Wouters <[email-masked]>
Date: Wed, 29 Dec 2010 00:26:49 -0500 (EST)

The hash type here is 2, and you refer to http://www.iana.org/assignments/tls-parameters
which refers to http://tools.ietf.org/html/rfc5246 for sha1, but I did not find that RFC
(about TLS) mentioning anything about encoding of the hash.

The above listed encoding seems to not have enough characters to be a base64
string of a sha1 hash, so I'm a little confused what you generated. Which
means it should probably get a better explanation in the text.

Paul