Re: Upgrade status for impl draft 1

[Eliot Lear <[e-mail]>]

On 2/27/13 10:52 PM, Ted Hardie wrote:
> On Wed, Feb 27, 2013 at 1:44 PM, Eliot Lear <[e-mail]> 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. 
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
>> 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