Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

[Amos Jeffries <[e-mail]>]

On 17/07/2016 7:30 a.m., Mike Bishop wrote:
> Thanks for the editorial catches!
> 
> Server might also prefer encrypted SNI, but with this model it’s only
> the client that decides whether to conceal the identity it actually
> intends to make requests of.  We can tweak the wording.  Your point
> about not calling it the “”real” certificate” with quotes is another
> candidate for wordsmithing.  The certificate of the origin to which
> it actually intends to make requests?  I’m basically taking this off
> of EKR and DKG’s idea that you do an external TLS handshake with an
> innocuous hostname, then get the cert for the hostname you actually
> care about inside the encrypted context.  So “fake” in that it’s not
> actually the origin you care about, not “fake” in the not-valid
> sense.

So one certificate is about the channel and one about the origin. Can we
agree to use those terms (or similar polite equivalents) to describe them?

I agree with Patrick. Lets avoid branding anything "fake" if its an
expected or required part of the protocol, even if only by implication
of derived from something else being "real".


> 
> Yeah, the stream states aren’t ideal.  I was trying to define invalid
> stream states, and basically came down to only one stream state where
> this exchange can’t be made.  And you’re correct – it will normally
> either be done on an idle stream (pre-HEADERS) or a closed stream
> (unauthenticated push).  We could simplify that if we just said that
> servers MUST provide the certificate prior to pushing, which is
> probably worthwhile.  If we’re not expecting/permitting clients to
> just remember which certificates were collocated, then the server
> always knows exactly what set of certificates the client has seen
> from it on the current connection.

Considered the other way, what use is the certificate if its not
received until (long?) after the recipient has delivered the related
stream data[1] on to other unsuspecting actors?

Because thats what it will probably be doing once a stream is closed.
There is also the case of the stream closure triggering the whole
connection closure and in-transit octets being discarded unseen.


[1] I mean the transaction data in its general sense. HTTP headers,
metadata and payload inclusive, either partially or in whole


> 
> We’ve gotten into the is-it/isn’t-it of IP routing, name resolution,
> and the PKI’s interrelationship in the security model a couple times
> now.  I think you’ve mostly convinced me that we’re effectively
> betting the farm on certs and routing is just our security blanket,

I don't see why you would need convincing of that. This draft is about
certificate security - its name says as much. One expects it to focus on
the certificate part of the system and rely on external resources to
define the other parts.


> but the reality is that this would still make the use of a cert
> compromise / spoof much nastier.  I don’t have to get you to connect
> to me with the origin I compromised, I just have to get you to
> connect to me with some origin.  And the restriction does exist in
> HTTP/2 already, so I’d like a little better motivation to change it
> than just having thought better of it.  If it’s actually wrong,
> should we be updating RFC 7540 independent of this work?  Do you
> ignore DNS for coalescing purposes if the presented cert is valid for
> the origin?  But yes, I’d like to see us clarify our security model
> and assumptions, and if this helps move us down that road, I’m
> happy.

Calling the important dependencies out is good of course, but not at
expense of drowning out the document focus.


HTH
Amos