On Tue, Oct 03, 2017 at 08:43:37PM -0400, Patrick McManus wrote:
...
> Given all of that, you're much better building a session mechanism at the
> application level.. as ugly as cookies are, they are the typically way to
> do that in a consistent manner in both h1 and h2. That's going to be way
> more robust (and performant) in the long run.
AFAIK, even secure cookies depend on trust in the server certificate for the
TLS connection. And AFAIK common practices like cert pinning still have
day 0 gaps. BRSKI effectively provides a method to gain trust into a
server cert without those workarounds. Via the first HTTP transaction.
On Tue, Oct 03, 2017 at 05:15:18PM -0700, Martin Thomson wrote:
> So wait for the first request to complete before making the others.
> I'm not sure that I see the problem here.
Yes, i think so too, but i like Michael i have FUD about all those possible
changes that are coming via evolution of HTTPS and thay may create
unexpected surprises in the future. So it would certainly helpfull
to get more eyes to check:
1 -> Initiate HTTPS connection.
2 -> retrieve cert information of peer from HTTP stack.
No trust into the cert now but continue.
3 -> Do one HTTP GET to retrieve voucher artefact
4 -> Returned voucher allows to cryptographically authenticate
HTTPS peer certificate. If verification fails, close session
5 -> Continue to do other HTTP transactions
Any UD (unexpected danger) here with HTTPS evolution or APIs that
try to auto-parallelize ? Or any crazy TLS stuff that would allow
to change certificates used for the connection so that the cert looked
up in 2. would not necessarily be the one used later... ?
If there is any UD, we can still close the HTTPS connection after 4
and create a new one for which we can establish trust in the certificate
during connection setup - and continue with 5. afterwards.
On Wed, Oct 04, 2017 at 06:53:50AM +0200, Eliot Lear wrote:
> This is properly RESTful.
Not sure about all RFC7030 transactions done in 5., but should be, yes.
Cheers
Toerless
> On Tue, Oct 3, 2017 at 5:58 PM, Michael Richardson <mcr+ietf@xxxxxxxxxxxx>
> wrote:
>
> >
> > I'm seeking guidance. It might be that this is a job for lwig, or perhaps
> > there is already a document which details how to do the profiling I care
> > about. If so, please point me at that.
> >
> > In ANIMA's BRSKI protocol, which is based upon RFC7030 EST, we run over
> > HTTP
> > 1.1 today using a single TCP connection.
> > It's HTTP over TLS ("HTTPS") [h2c?] rather than an upgrade.
> >
> > In BRSKI there are state issues with both the TLS and the HTTP process.
> > The TLS server certificate is not trusted by the client until after at
> > least
> > one RESTful interaction occurs. Only once that has occured is the
> > connection
> > considered secure.
> >
> > We are concerned about how the protocol could become broken if used with
> > HTTP2 with interleaving of requests/responses. With HTTP (port-80)
> > transactions, using the RFC7540 section 3.2 upgrade, one could just decline
> > to ever do the upgrade and be done. With HTTPS, this is negotiated in
> > the TLS connection, so one can go to HTTP2 directly, I think.
> >
> > While limiting ourselves to HTTP/1.1 might be a good policy, I worry that
> > at some point in 10 years, the HTTP/1.1 code might be in the library only
> > to
> > support our use case, with the application code on the device having moved
> > on
> > to HTTP2 only.
> >
> > What I think we are looking for is a set of things we can specify that
> > will make HTTP2 as deterministic (and slow!) as HTTP/1.1. For instance,
> > I think that
> > SETTINGS_MAX_CONCURRENT_STREAMS = 1
> >
> > would do 90% of it. Should we turn off PUSH?
> > Can/should we recommend lower values for window sizes, etc?
> > (ANIMA end points are not constrained in the IoT/RFC7228 sense, but rather
> > are control plane CPUs, with megabytes of ram, often partitioned at boot
> > time. But, ANIMA BRSKI may also applies to Web connected devices like the
> > baby monitors that have wreaked havoc.)
> >
> > --
> > Michael Richardson <mcr+IETF@xxxxxxxxxxxx>, Sandelman Software Works
> > -= IPv6 IoT consulting =-