MIME-Version: 1.0
In-Reply-To: <AANLkTim8svP4Fu+1+GQVVRT48b0EhA9qnig5WeUBiN4w@mail.gmail.com>
References: <4D92317B.6020804@fifthhorseman.net>
 <BANLkTinGEt42DM1NqbrjOfdqTqLUjnQ5KQ@mail.gmail.com>
 <AANLkTim8svP4Fu+1+GQVVRT48b0EhA9qnig5WeUBiN4w@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Tue, 29 Mar 2011 14:35:58 -0700
Message-ID: <BANLkTinPMRRVwBrvRh-rHdprtgEaU=Eq=w@mail.gmail.com>
To: Tom Ritter <tom@ritter.vg>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: websec@ietf.org
Subject: Re: [websec] Decouple HSTS's two orthogonal effects?
Precedence: list

On Tue, Mar 29, 2011 at 2:29 PM, Tom Ritter <tom@ritter.vg> wrote:
> On Tue, Mar 29, 2011 at 4:58 PM, Adam Barth <ietf@adambarth.com> wrote:
>> There's no coupling between HSTS and the particular algorithm a UA
>> uses to verify certificates. =A0The UA is free to use whatever
>> verification mechanism it desires.
>
> This is good, but perhaps some clarification to the draft would be in ord=
er:
>
> Section 2.2 states:
>
> =A0 2. =A0The UA terminates, without user recourse, any secure transport
> =A0 =A0 =A0 connection attempts upon any and all secure transport errors =
or
> =A0 =A0 =A0 warnings, including those caused by a site presenting self-si=
gned
> =A0 =A0 =A0 certificates

If a self-signed certificate does not cause a secure transport error,
then you're all set.  For example, it's fine for a self-signed
certificate to be in the list of explicitly trusted certificates.  In
that case, no secure transport error is generated.  Try it.  :)

> Knowing that HSTS allows any validation method a posteriori allows you
> interpret this correctly - that self-signed certs *may* be allowed
> under HSTS, if the user has added them to their store. =A0But without
> that, it may be interpretted incorrectly - that no self-signed certs
> would be allowed.

That's not what it says.

>=A0Furthermore, I'm not sure, but "any and all secure
> transport errors or warnings" may be ambiguous. =A0I don't know if it's
> an existing standard to enter a warning or error state in event of
> (for example) a revocation check failure - although we do know that
> most browsers do not present any warning or error. =A0There's more on
> that in Adam Langley's thread. =A0 If HSTS does not define whether or
> not a revocation check failure is an error condition, I think it
> should.

Indeed.  A reference there would be helpful.

> Also Section 9 recommends distributing root CA certs to users'
> browsers, and does not mention the possibly of distributing the leaf
> certs instead. =A0Less related, but I prefer to trust organizations leaf
> certs individually than their root cert.

I don't have a problem with also recommending leaf certs, but you
should check with =3DJeffH.

Adam