Subject: Upgrade status for impl draft 1

From: Mark Nottingham <[email-masked]>
Date: Thu, 21 Feb 2013 20:11:08 +1100

Based upon discussion both at the Interim and subsequently, this is where I think we are for the upgrade/negotiation process, at least in terms of the 1st implementation draft:

1. HTTPS URLs
   - use NPN (or its replacement); uses OPAQUE TOKEN to negotiate
   - NO magic
   - SETTINGS first

2. HTTP URLs

  a. existing connection / new connection without context
      - Upgrade Dance; uses OPAQUE TOKEN to negotiate
      - NO magic
      - SETTINGS first

  b. new connection with context (e.g., because you used DNS hint, header hint, prior knowledge)
     - NO upgrade dance
     - Magic
     - SETTINGS first

The decision as to whether to use 2(a) or 2(b) in a particular situation is up to implementations, but of course we'll give (non-normative) guidance.

Does this make sense to everyone?

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: James M Snell <[email-masked]>
Date: Thu, 21 Feb 2013 07:11:56 -0800

There are two too many options in my opinion but I can live with this for
now.
On Feb 21, 2013 1:13 AM, "Mark Nottingham" <[email-masked]> wrote:

> Based upon discussion both at the Interim and subsequently, this is where
> I think we are for the upgrade/negotiation process, at least in terms of
> the 1st implementation draft:
>
> 1. HTTPS URLs
> The decision as to whether to use 2(a) or 2(b) in a particular situation
> is up to implementations, but of course we'll give (non-normative) guidance.
>

---

From: Eliot Lear <[email-masked]>
Date: Thu, 21 Feb 2013 16:20:50 +0100

James,

I had several side discussions at the Interim meeting.  We could get rid
of ALL but ONE option if we agree to eat any performance improvement on
the first exchange.  If we do that then we simply use Upgrade: and have
done with the whole mess.

Eliot

On 2/21/13 4:11 PM, James M Snell wrote:
>
> There are two too many options in my opinion but I can live with this
> for now.
>
> On Feb 21, 2013 1:13 AM, "Mark Nottingham" <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Based upon discussion both at the Interim and subsequently, this
>     is where I think we are for the upgrade/negotiation process, at
>     least in terms of the 1st implementation draft:
>
>     1. HTTPS URLs
>     The decision as to whether to use 2(a) or 2(b) in a particular
>     situation is up to implementations, but of course we'll give
>     (non-normative) guidance.
>

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 08:50:02 -0800

I took some different conclusions away:

Specifically, I believe that we discussed having magic always
regardless of how we got started, so that there was only one code
path.  That wasn't firm, but I distinctly remember the conversation
that lead to that conclusion.

We didn't conclude on whether we would always need upgrade, though it
was evident to me that avoiding upgrade was clearly desirable: see
https://github.com/http2/http2-spec/issues/29

---

From: Martin Thomson <[email-masked]>
Date: Thu, 21 Feb 2013 15:59:34 -0800

I took the liberty of drawing up a few pictures:

http: URI Upgrade
http://www.websequencediagrams.com/?lz=dGl0bGUgSFRUUC8yLjAgVXBncmFkZQoKQ2xpZW50LT5TZXJ2ZXI6IFRDUCBTWU4KAAoGLT4AGgYADwksQUNLAB8VAAQUAGkFMS4xIEdFVCArAGsJAEsQAB4JMTAxAAcgMi4wIE1hZ2ljICsgU0VUVElOR1MKbm90ZSByaWdodCBvZiAAgUIIAIFMBiBzZW5kcyBmaXJzdCBpbgCBeQkhAEYaMjAwAIE1FgBpFA&s=napkin

https: (I didn't distinguish between magic/no magic)
http://www.websequencediagrams.com/?lz=dGl0bGUgSFRUUC8yLjAgVExTCgpub3RlIG92ZXIgQ2xpZW50IFNlcnZlcjogVENQIENvbm5lY3RlZAoAFwYtPgAVCUxTACoHSGVsbG8KADAGLT4APwYAGgYARAYAGgYALBRG

Sure, you could drop the magic if you've negotiated the protocol in
the TLS handshake, but it doesn't seem that useful and it creates an
extra if() statement.

What I didn't realize was the consequences of permitting the response
to the HTTP/1.1 request to be sent immediately.  In the Upgrade, the
server sends first on the HTTP/2.0 session.  This has implications for
several things (flow control, suppressing server push, etc...).

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 22 Feb 2013 15:51:13 +1100

> that lead to that conclusion.

Works for me; I'm more interested in just getting something concrete written down.

Anyone have a problem with that?

One thing we need to discuss is how servers should handle it when the magic isn't sent, or isn't sent correctly; hard close?

Also, we haven't concluded on server->client magic. Do we have a real need for it?

> https://github.com/http2/http2-spec/issues/29

My sense is that requiring it is going to be a non-starter. That's why I proposed three distinct paths below.

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Feb 2013 08:02:48 +0100

> Anyone have a problem with that?

I agree with Martin here that we should avoid different code paths as
much as possible.

> One thing we need to discuss is how servers should handle it when the magic
> isn't sent, or isn't sent correctly; hard close?

In my opinion it will simply be an invalid protocol talked over the
wire if it does not match what is expected. We must be a bit stricter
with protocol elements than what we used to do since HTTP/0.9.

> Also, we haven't concluded on server->client magic. Do we have a real need

Depends whether an unexpected server response might be parsed as a valid
response or not. We could start with and remove it later if unneeded.

Willy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Feb 2013 08:02:14 +0100

On Thu, Feb 21, 2013 at 08:11:08PM +1100, Mark Nottingham wrote:
> Based upon discussion both at the Interim and subsequently, this is where I
> think we are for the upgrade/negotiation process, at least in terms of the
> 1st implementation draft:
> 
> 1. HTTPS URLs
> The decision as to whether to use 2(a) or 2(b) in a particular situation is
> up to implementations, but of course we'll give (non-normative) guidance.
> 

I'm still having a problem with the principle behind 2b : when you
pass through transparent intercepting proxies, by definition you're
not aware of it. So even if 2a worked for the first connection, it
does not preclude that 2b will work for the second one. Nor the DNS
will BTW.

And the issue I'm seeing is that 2b will require HTTP/2->2 proxies to
be deployed along all the path for this to succeed. If 2->1 proxies
are deployed, then we lose all benefits for 2.0 by terminating the
optimizations close to the client. Let's consider the following
common path :

  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

ISP proxy is the transparent proxy/cache at the client's ISP's, and SRV
proxy is the ADC on the server side. Eventhough the server side is fully
2.0 compatible and advertises it via the DNS, until the ISP proxy is not
a true 2.0->2.0 proxy, we'll have the following possibilities :

Upgrade connection : creates a tunnel between CLI and server, end-to-end
2.0 (just like with TLS) :
          2.0                      2.0                      2.0
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

Magic, ISP proxy not aware at all : second connection fails, client has
to fall back to 1.1 (or switch back to Upgrade ?) :
          1.1                      1.1                      1.1
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

Magic, with ISP proxy being a 2.0-to-1.1 gateway :
          2.0                      1.1                      1.1
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

Magic, with ISP proxy being a 2.0-to-2.0 gateway :
          2.0                      2.0                      2.0
  [ cli ]---->[ ISP proxy ]--~~ internet ~~-->[ SRV proxy ]---->[ server ]

The last case (2.0-to-2.0 gateway) will not happen soon, and I really
believe that because of this, we'll be much more often in second then
third case above where 1.1 only is used on the long path.

Likewise, it is not said how such 2.0 should pass through explicit proxies,
while the Upgrade provides such a solution.

Why not consider the Upgrade request the "magic" itself ? In fact it's
exactly that. I understand the complexity that the Upgrade can cause if
we require the server to process the early requests in 1.1. But if we
consider that it's just a prefix, there is no "dance" at all. It's just
the same as what was proposed in 2817 for TLS upgrade, we connect to the
other endpoint and establish a tunnel. No need to support multiple setup
methods.

Regards,
Willy

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2013 05:10:15 -0800

++

Always send the magic, at least until we have data that shows it is
detrimental.
If you don't get the magic, it isn't draft-http2/1, so unless you know what
it is, close the connection.

server->client magic. Dunno.

On Thu, Feb 21, 2013 at 11:02 PM, Willy Tarreau <[email-masked]> wrote:

> > Also, we haven't concluded on server->client magic. Do we have a real
> need
> > for it?
>

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2013 05:14:03 -0800

Are you proposing following normal Upgrade semantics (that would add an RT,
bleh).
The magic which we have now is intended to make noncompliant intermediaries
barf. We know that Upgrade doesn't work particularly well for this from WS
experimentation, and a successful Upgrade (as viewed from the server's
perspective) doesn't necessarily mean that you're free-and-clear to talk in
the next protocol.

So, if you're doing an HTTP/1 upgrade, you'd do that, and then do the
HTTP/2 magic, and then proceed with the SETTINGS frame, etc.
I suspect you may be saying roughly the same thing??
-=R

On Thu, Feb 21, 2013 at 11:02 PM, Willy Tarreau <[email-masked]> wrote:

> is

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Feb 2013 14:38:21 +0100

> perspective) doesn't necessarily mean that you're free-and-clear to talk in

I agree on this last point, but this probably is where the magic can help if
placed at the proper location. In WS, we refrained from sending anything along
with the handshake. However there is nothing that prevents us from sending the
upgrade and the magic in the same packet to validate that the channel really
is open :

 > HEAD * HTTP/1.1
 > Host: foo
 > Upgrade: HTTP/2.0
 > Connection: Upgrade
 > MAGIC-request
 (first frame etc...)

 < HTTP/1.1 101 Switching
 < Upgrade: HTTP/2.0
 < Connection: Upgrade
 < 
 < MAGIC-response

And then it makes a lot of sense to have a MAGIC-request above that
should cause an abort on most systems (as Mark has been experimenting
with), because as long as intermediaries are 1.1-compliant, they will
correctly forward 2.0 to the end point without breaking the connection.
The ones broken will only be the non-compliant ones.

Willy

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2013 05:41:21 -0800

I think we're agreeing, then, pre-supposing that we're expecting an
HTTP/1.1 server on the other side.
-=R

---

From: Roberto Peon <[email-masked]>
Date: Fri, 22 Feb 2013 05:42:45 -0800

Adding the upgrade, etc, to the mandatory magic (instead of treating the
UPGRADE as something for/from HTTP/1) is getting the bytecount large enough
to be noticable, btw, and may be getting into performance impacting areas.
Of course this is totally guesstimation and only time (and thus data) will
tell.
-=R

---

From: Roland Zink <[email-masked]>
Date: Fri, 22 Feb 2013 15:19:28 +0100

When the server respond without upgrading then I would expect that no 
MAGIC should be sent.

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Feb 2013 15:33:23 +0100

Willy,

Putting aside the rest of your post...

On 2/22/13 8:02 AM, Willy Tarreau wrote:
> If 2->1 proxies
> optimizations close to the client. 

 Consider the case of 3G clients, where header compression might
actually provide 3g (and other low bandwidth) h/w a boost.

Eliot

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Feb 2013 15:43:42 +0100

> actually provide 3g (and other low bandwidth) h/w a boost.

I'm well aware of this one, but it's already covered by devices installed
in place at providers, and would be much better handled by having an
explicit proxy configured (to save a DNS lookup and optimize connection
reuse) than just relying on the magic we need to detect the rest of the
world's compatibility.

Regards,
Willy

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Feb 2013 15:49:35 +0100

> reuse) than just relying on the magic we need to detect the rest of the

Just to be clear, you're encouraging not explicit configuration of a
proxy by an end user but a DHCP option.  Right?
Eliot

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 22 Feb 2013 15:56:58 +0100

> proxy by an end user but a DHCP option.  Right?

This can be an option, probably that mobile devices sold by the operator
could be pre-configured, I have no idea. I'm just talking about protocol
efficiency here, not about who is supposed to do his work :-)

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Feb 2013 11:56:09 +1100

> does not preclude that 2b will work for the second one. Nor the DNS

Sorry, I wasn't clear; that would be for cases where you had a high degree of confidence that not only was HTTP/2.0 able to be spoken, but where you have an even higher degree of confidence that HTTP/1.x is NOT; e.g., a separate port (that you might have discovered through DNS, for example).

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 26 Feb 2013 04:54:27 +0100

Hi Mark,

On Tue, Feb 26, 2013 at 11:56:09AM +1100, Mark Nottingham wrote:
> Sorry, I wasn't clear; that would be for cases where you had a high degree of
> confidence that not only was HTTP/2.0 able to be spoken, but where you have
> an even higher degree of confidence that HTTP/1.x is NOT; e.g., a separate
> port (that you might have discovered through DNS, for example).

Then if that's to be used on a different port, we probably don't need
to check how servers respond to this magic on port 80.

Willy

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 26 Feb 2013 14:57:48 +1100

> to check how servers respond to this magic on port 80.

My motivation is to fail on misconfiguration (e.g., telling Apache to listen on the wrong port, forwarding to a back-end that doesn't speak 2.0), and to clearly identify the protocol being spoken.

To me, it's a bonus if sending the magic helps fail the upgrade early, but I don't find the multiple code paths terribly convincing; we're talking about emitting a handful of bytes on the client side, and checking a handful on the server side.

Cheers,

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 26 Feb 2013 05:02:45 +0100

On Tue, Feb 26, 2013 at 02:57:48PM +1100, Mark Nottingham wrote:
> My motivation is to fail on misconfiguration (e.g., telling Apache to listen
> on the wrong port, forwarding to a back-end that doesn't speak 2.0), and to
> clearly identify the protocol being spoken.
>
> To me, it's a bonus if sending the magic helps fail the upgrade early, but I
> don't find the multiple code paths terribly convincing; we're talking about
> emitting a handful of bytes on the client side, and checking a handful on the
> server side.

OK, then I agree with the principle of finding something that *most often*
fails cleanly even if that is not *always* the case.

Cheers,
Willy

---

From: William Chan (陈智昌) <[email-masked]>
Date: Tue, 26 Feb 2013 19:43:47 -0800

I agree with the outcome of this thread (always requiring magic).

>   b. new connection with context (e.g., because you used DNS hint, header

QQ over here. Is this assuming only unencrypted HTTP/2? I believe Patrick
was hoping to bootstrap serving http:// URLs via HTTP/2 over SSL, using the
external discovery mechanism (DNS most likely). If so, I'm unclear on
whether or not we need to describe behavior WRT TLS-NPNesque negotiation.
Perhaps we should fork the thread for this...

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 27 Feb 2013 16:46:05 +1100

> I agree with the outcome of this thread (always requiring magic).

OK, I think that's where we're at. I've recorded the modified plan in the issue:
  https://github.com/http2/http2-spec/issues/1

I think this also resolves:
  https://github.com/http2/http2-spec/issues/29
... because it's clear that we're not dancing in 1 or 2(b). We will need some guidance on when to use 2(a) vs. 2(b), of course.

> QQ over here. Is this assuming only unencrypted HTTP/2? I believe Patrick was hoping to bootstrap serving http:// URLs via HTTP/2 over SSL, using the external discovery mechanism (DNS most likely). If so, I'm unclear on whether or not we need to describe behavior WRT TLS-NPNesque negotiation. Perhaps we should fork the thread for this...

Well, I think that's orthogonal, in that you're still going to not do the dance, and send the magic, and send settings first.

I'd like to see our spec show a handful of ways to start a new connection (acknowledging that it's an open-ended set; i.e., someone may one day decide to support starting HTTP/2 using a different mechanism, especially if it's not TCP underneath), which includes negotiating the profile in use, and sending the magic. Whatever the TLS WG defines will be one of those mechanisms, but we still have to define how to use it in the scope of our protocol (just as we need to define how TCP is used, for example).

Cheers,

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Feb 2013 07:27:31 +0100

On 2/27/13 4:43 AM, William Chan (陈智昌) wrote:
>
> QQ over here. Is this assuming only unencrypted HTTP/2? I believe
> Patrick was hoping to bootstrap serving http:// URLs via HTTP/2 over
> SSL, using the external discovery mechanism (DNS most likely). If so,
> I'm unclear on whether or not we need to describe behavior WRT
> TLS-NPNesque negotiation. Perhaps we should fork the thread for this...
>

This *is* possible, but with a big caveat: DNS should offer alternatives
that have the same security level –– UNLESS DNSSEC is in play. 
Otherwise there's a downgrade attack in the making.

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Feb 2013 13:20:44 -0800

On Tue, Feb 26, 2013 at 10:27 PM, Eliot Lear <[email-masked]> wrote:
> that have the same security level –– UNLESS DNSSEC is in play.  Otherwise
> there's a downgrade attack in the making.
>
> Eliot

Hi Eliot,

While I agree with you, the difficulty is that linking that sort of
policy statement
(DNS alternatives presented should have equivalent security levels) is not
something that is easy to find an enforcement point for inside the
DNS.  In some HTTP use cases
you may will have no integrated DNS clients (e.g. mobile apps) and in
lots of them
you will have no DNSSEC validation routines.  So doing it in the DNS
client code may be
equally problematic.

Can we express this instead as "clients should reject candidates found
via external discovery
if the candidates are not protected by TLS"?  That eliminates the
downgrade but makes
the HTTP client the enforcement point rather than the DNS.  DNSSEC
remains useful and a good
addition, but it is no longer critical path.

Just two cents,

Ted

---

From: Eliot Lear <[email-masked]>
Date: Wed, 27 Feb 2013 22:44:55 +0100

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.  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.

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Wed, 27 Feb 2013 13:52:01 -0800

On Wed, Feb 27, 2013 at 1:44 PM, Eliot Lear <[email-masked]> wrote:
> 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.

> But
I don't really follow this; can you rephrase it?

Ted

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 28 Feb 2013 18:58:36 +1300

On 28/02/2013 10:52 a.m., Ted Hardie wrote:
> On Wed, Feb 27, 2013 at 1:44 PM, Eliot Lear wrote:

Can we take a step back folks and outline _exactly_ what it is that 
needs protecting here?

  - the datum responded by DNS?
  - the HTTP channel?

Status Quo is that neither is protected. Unless you are embedding all 
sorts of security related ifnormation into this RR is can be no worse 
than A/AAAA records pointing at a domain are today.

Some of you seem to be indicating that DNSSEC protected records pointing 
at non-TS connections is a major problem. It is *not* that major. That 
case is the Status Quo. We do want to improve it, but nothing proposed 
is making it _worse_ and nothing at either step is mandating anything 
about the other step.

Amos

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Feb 2013 07:31:59 +0100

> 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.
> 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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Feb 2013 08:31:33 +0100

>  - the datum responded by DNS?

The case we're talking about is where http://www.example.com:8080 and
https://www.example.com:4343 have the exact same content and services. 
You don't want a man in the middle to be able to force clients to 8080
when a more secure encrypted service is advertised.  One simple way
around this is not to have 8080 available for this purpose.  Otherwise,
you want to ensure the information you are getting from the DNS is
accurate and complete.  DNSSEC provides that capability.

Eliot

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 28 Feb 2013 21:06:38 +1300

> accurate and complete.  DNSSEC provides that capability.

Fine. MITM have easy access to DNS to learn these details, same as the 
client does. All they will do is intercept the HTTPS channel and answer 
it from fetches sent to 8080, same as they do today. Status Quo.

My point was the only actual gain to be made is that DNS interceptors 
(dnsmasq and similar tools) are hindered by the DNSSEC stage. You get 
the same beneft from DNSSEC signing the A/AAAA records on a plain old 
HTTP/1.x connection. TCP interceptors hit the channel portion at the 
packet level and DNSSEC will not fix that.

Unless you start talking about making the TLS layer actually chain the 
security trust from DNSSEC down to the server TLS certificate the whole 
client trust system will still be vulnerable to HTTPS interceptors even 
if both are used.

Amos

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Feb 2013 11:00:02 +0100

On 2/28/13 9:06 AM, Amos Jeffries wrote:
> client does. All they will do is intercept the HTTPS channel and
> answer it from fetches sent to 8080, same as they do today. Status Quo.
No that's a poorly written client, when it accepts plaintext while
expecting TLS. Unless of course they the DO speak TLS with a fake or
invalid cert. That **is** a problem but it is a problem, but not with
the DNS mechanism.

But to your main point, the draft introduces a usage case that can be
dealt with in a number of different ways, and it is simply important to
document both the concern and the remediation.

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Feb 2013 09:50:10 -0800

> 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.

> 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

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Feb 2013 18:55:48 +0100

Ted,

What I'm trying to say form a deployment standpoint is this: “don't poke
your eye with your own finger.”  I'm not saying we should gate on DNSSEC.

Eliot

---

From: Ted Hardie <[email-masked]>
Date: Thu, 28 Feb 2013 13:23:20 -0800

> your eye with your own finger.”  I'm not saying we should gate on DNSSEC.

Fair enough.  The only really crucial piece for me is that implementers should
not presume that the entries in the hint are of equal security just because the
RFC says they ought to be.

regards,

Ted