Subject: [POSH] Feedback on 'draft-miller-posh-00'

From: Tobias Markmann <[email-masked]>
Date: Sun, 21 Jul 2013 20:22:29 -0000

Hi Matt and Peter,

So I've given draft-miller-posh-00 a read and have the following
feedback on the
document.

All in all the draft is well-written and, apart from the issues
mentioned,
easily understandable with less deployment requirements compared to
secure
DNS.

Below you'll find my comments for each section.

1. Introduction
---------------
> 1.  A TLS client retrieves the material to be used in checking the
>       TLS server's identity by requesting it from a well-known HTTPS
>       URI, where the response contains one or more certificates
>       formatted as a JSON Web Key set [JOSE-JWK] defined within the
>       JOSE WG.

Why are JSON Web Keys used over more common formats like
Base64-encoded DER,
for which parsers are readily available in all TLS libraries? The
'x5c' field in the JWK
set seems to be Base64ed DER; still with JSON around it. Presenting
the reasoning
behind this choice would make the document easier to grasp in its
context.

3.  Obtaining Verification Materials
------------------------------------
> For example, if the application protocol is XMPP then the
"{service}" is
> either "_xmpp-client" for XMPP client-to-server connections, and
> the "{protocol}" is "_tcp"; thus if an XMPP client were to use
> POSH to verify an XMPP server for the domain "im.example.com",
> the HTTPS GET request would be as follows:

The lone *either* suggests you also want to mention the S2S scenario
here,
though it seems to be missing. The following sounds more complete:

...either "_xmpp-client" for XMPP client-to-server connections or
"_xmpp-server" for XMPP server-to-server connections...

3.1.  Source Domain Possesses PKIX Certificate
----------------------------------------------
> In order for the TLS client to verify
> the identity of the TLS server, it MUST ensure that the PKIX
> certificate presented by the TLS server during the TLS negotiation
> matches the certificate that it obtained via POSH.

How to perform that matching/equality check? Comparing the X.509
fingerprints
should be enough, right? A paragraph or reference to a section on how
to perform
the matching would make it more clear.

3.2.2.  Redirect Depth
----------------------
> To protect against circular references, clients MUST NOT follow an
> infinite number of redirects.  It is RECOMMENDED that clients follow
> no more than 10 redirects, although applications or implementations
> can require that fewer redirects be followed.

These are basically the same precautions RFC 2616 mandates in section
10.3.
I suggest simply referring to [RFC 2616, Section 10.3] instead of
duplicating
text or describing the same with different words. If we want to set
additional
precautions these should be emphasised.

6.  Caching Results
-------------------
While this section already recommends HTTPS servers to add headers
preventing
any client side caching, I think this issue should be more
highlighted. Long
caching deplays roll-over or other changes related to the secure
delegation
setup.

Cheers,
Tobi

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Mon, 22 Jul 2013 23:14:23 +0000

Hello Tobi,

Thanks for the feedback!  More comments inline...

> Below you'll find my comments for each section.

The rationale is to certificate roll-over and alternate certificates.  The roll-over case is for operators to be able to obtain a renewed certificate, and gradually update all of their front-end servers (all identified by the same hostname) to the new certificate without compromising the verification process.  The alternate use case is to allow for the front-end servers to be identified by different hostnames, but for the same service.

Section 7 discusses how to do that, but doesn't explain these rationales.  I'll make a note to add these rationales to the document.

> 3.  Obtaining Verification Materials

Actually, the intent was to discuss the process using a single protocol; Section 2. Terminology explains that (or attempts to).  That "either" is a typo, and we'll remove it with the next revision.

> 3.1.  Source Domain Possesses PKIX Certificate

Good point.  we'll add that with the next revision.

> 3.2.2.  Redirect Depth

"Mandate" might be too strong a word for what RFC2616 § 10.3 says (-:

However, it does have recommendations, as we ought to reference those unless there's a good reason to have our own.  We'll see about changing the existing section to mostly reference this section in RFC2616.

> 6.  Caching Results

I don't disagree, but I'm not sure what we ought to do to highlight it more.  Do you have any specific suggestions?

- m&m

Matt Miller < [email-masked] >
Cisco Systems, Inc.