Subject: Re: [keyassure] HTTPS -> HTTP downgrade

From: "Jeffrey A. Williams" <[email-masked]>
Date: Wed, 22 Dec 2010 14:03:36 -0600 (GMT-06:00)

Paul and all,

-----Original Message-----
>From: Paul Hoffman <[email-masked]>
>Sent: Dec 22, 2010 1:46 PM
>To: Paul Wouters <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [keyassure] HTTPS -> HTTP downgrade
>
>At 2:11 PM -0500 12/22/10, Paul Wouters wrote:
>>That discussion keeps circling into "you cannot dictate policy" vs
>>"that's so insecure the protocol should provide a way to prevent it".
>
>We agree that we keep circling to an either X or Y question. I would state the question as "you { can | cannot } dictate a policy that demands that a client only use a secure service on a particular host". Once we have agreement on whether that is "can" or "cannot", moving forwards on the resulting protocol is much easier.

  I agree with this but I am sure that you know that there will be
some political push back at some point from State and USTR on this.
Me thinks that they will want/demand that 'CAN' is the preferred
 or strongly desired option.  
>
>>And there is also no way to say "we prefer you to come in at port 443",
>>that would allow the local client policy to overrule a systems preference.
>
>We could add such a preference to the announcement protocol, but seems kind of silly: it is obvious that servers would prefer you use the secure protocol.

+1
>
>>>>Are you saying that other than the one corner case I've outlined that this will be a common occurrence, and that users will somehow actually want to control this, disregard the policy offered by the site?
>>>
>>>I certainly am not saying that, and I don't know if Paul Wouters is.
>>
>>The beviour of first going to port 80 and depending on a redirect to
>>port 443 is not a corner case. It is the common case.
>
>Fully agree.
>
>>Having a DNSSEC
>>validatable method to tell the client to start out on port 443 is
>>needed.
>
>Disagree, but no need to bludgeon that.
>
>>Since we are doing TLS related DNS records, this seems a good
>>time to include support for this.
>
>Fully agree.

+1
>
>>Again, these attacks are happening, they are not theoretical.
>
>No one has said otherwise.
>
>--Paul Hoffman, Director
>--VPN Consortium
>_______________________________________________
>keyassure mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/keyassure

Kindest regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
Updated 1/26/04
Network security Eng. SR. Eng. Network data security,
IT/information security.
ABA member in good standing member ID 01257402 
E-Mail [email-masked]
Phone: 214-244-4827

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Dec 2010 17:11:41 -0500 (EST)

>> We could add such a preference to the announcement protocol, but seems kind of silly: it is obvious that servers would prefer you use the secure protocol.

Note that "preference" is not good enough - it would allow an attacker
to use a downgrade attack. Though I would be okay with "80 443"
meaning preference and "0 443" meaning "just 443". But then we have the
compatibility issue of running on port 80 while HASTLS says there is
nothing on port 80. Again. I am fine with that, because I am going by
the assumption that clients that impkement HASTLS will also implement the
"no non-secure fallback when secure port is dnssec validated",

eg something like:

"If a service is offered on both insecure and secure ports, and the client
supports the secure port, it SHOULD|MUST connect to the secure port only"

To me, this falls in the same category as "MUST NOT use a nonce twice". It's
inheritant in the security protocol to counter an attack vector.

I think we all agree that is what sane clients should do. We don't agree
on forcing them to do this. And part of my argument has been that if we
don't specify this in the HASTLS document, we might end up with mixed
behaviour where some will take (80 443) to mean "443 only" and others
will take it as "either port is fine".

Paul

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 22 Dec 2010 14:29:35 -0800

At 5:11 PM -0500 12/22/10, Paul Wouters wrote:
>meaning preference and "0 443" meaning "just 443".

That was my intention...

>But then we have the

That's one assumption, but one that does not match what most users have today.

>supports the secure port, it SHOULD|MUST connect to the secure port only"

And, again, that is you telling someone else what they MUST do, regardless of what they want.

>inheritant in the security protocol to counter an attack vector.

They are completely unrelated. To repeat my example from a day or two ago: assume that the client does not have the trust anchor you require for TLS in their trust anchor store. "SHOULD|MUST connect to the secure port only" means "you're going to fail to connect, tough luck". More likely it will mean "you will tell your client to let you through anyway, ignoring what HASTLS told you securely".

>will take it as "either port is fine".

We fully agree that will happen: that's what client policy is all about. That's why hoffman-server-has-tls differentiates these types of clients as CSO and CFB, while other proposals pretends that the difference doesn't exist even though both clearly do exist.

--Paul Hoffman, Director
--VPN Consortium