Re: Upgrade status for impl draft 1

On Wed, Feb 27, 2013 at 10:31 PM, Eliot Lear <lear@cisco.com> wrote:
>
> On 2/27/13 10:52 PM, Ted Hardie wrote:
>> On Wed, Feb 27, 2013 at 1:44 PM, Eliot Lear <lear@cisco.com> wrote:
>>> Ted, the problem is that then we are essentially requiring TLS for
>>> implementation of HTTP 2.0.  We've said we're not going to do that.
>> I don't think this is quite right.  I think it means that if you use
>> the DNS hints mechanism, you should expect TLS.  If you have other
>> upgrade methods, they would not be impacted.  That doesn't require TLS
>> for implementation of HTTP 2.0 itself.
>
> The whole point of the draft is performance and eliminating latency.
> What you suggest would penalize non-TLS implementations for no reason.

Well, it limits the optimization choices for them.  I am not sure it's fair to
cast that as "penalize", but we seem to basically agree.

> As important, we haven't really defined what a TLS deployment is in
> these cases.  For instance, as I've said before, in an enterprise
> environment, it is not reasonable to assume that every server will have
> a valid cert.  In fact we have yet to see whether this is even a valid
> assumption on the Internet as a whole.  I don't want to bind this draft
> into that discussion, and there is no reason to do so.

But the context of my remark wasn't in the context of defining a TLS deployment,
it was your proposal that all alternatives be of similar security
level unless protected
by DNSSEC.  While I agree that this avoids a downgrade attack, it either
requires you to have the DNS enforce a policy about what records may
be siblings
(something I don't think is possible by anything other than
administrative fiat) or it
requires every HTTP 2.0 implementation do DNSSEC itself (thus eliminating both
cases where the implementation is getting the data from an OS which
doesn't expose the DNSSEC status of the response and any deployment
where the organization does validation at a configured recursive caching
name server rather than the end host.)   In addition, it requires everyone
deploying this hint and a mixed-security level response to do so in conjunction
with DNSSEC; that's likely not a problem for big content-focused producers,
but it may be for internal resources inside enterprises or back-end systems.


To put this slightly differently, I don't think having a policy
requiring sibling
records to be of similar security levels actually helps much.  The
client will have
to deal with it if they are not configured correctly, so it doesn't
help the code path,
and the downgrade of the optimization is there in the absence of  DNSSEC in
any case (as the attacker can suppress the whole RR, so that the client goes
back to using A or AAAA records for www.domain.example).

Just my personal opinion,

Ted Hardie


>>> But
>>> also, the problem you describe is within control of both clients (albeit
>>> with a linkage to DNSSEC) and servers by not linking two secure and
>>> insecure services.  Ultimately what is proposed represents no change
>>> because the server itself has to provide whatever capability we're
>>> discussing.
>>>
>> I don't really follow this; can you rephrase it?
>>
>
> Sure.  There are two opportunities to avoid the risk I raised:
>
> 1.  Servers simply do not advertise via DNS the same service using both
> TLS and non-TLS.
> 2.  They use DNSSEC.
>
> The issue is entirely remediated with existing code, if necessary.  And
> for those who do want to mix security models, then they need to, at the
> very least, offer a signed zone so that clients and their resolvers can
> validate the information.  I personally wouldn't do this until I felt
> comfortable that clients had that ability.
>
> Eliot
>

Received on Thursday, 28 February 2013 17:50:37 UTC