Re: [POSH] Comments/questions on draft-miller-posh-00

[Peter Saint-Andre <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/26/13 11:54 AM, Michael Procter wrote:
> I read draft-miller-posh-00 with interest, and have a couple of 
> questions about the expected usage.

Hi Michael, thank you for the review, and sorry about the slightly
delayed reply (travel, pre-IETF workshops, etc.).

> In section 5, you discuss the relative timing of POSH operations
> and the application TLS handshake, requiring the POSH operations to
> be complete before the application handshake completes.  At the end
> of the paragraph, you mention that all the POSH operations may in
> fact be completed before the application handshake begins.  That
> sounds reasonable, provided you know in advance that the POSH part
> is required.

Well, it's pretty clear that you'll need to complete the POSH
operations before the TLS negotiation ends. :-) IMHO you don't really
need to know in advance that a POSH retrieval will be necessary, thus
I don't think that we need some sort of discovery mechanism (in fact,
Matt and I discussed that since XMPP has a way to advertise features
and authentication methods and such before STARTTLS, but we decided it
wasn't needed). For instance, the TLS client could attempt the
negotiation, realize that it's not able to tie the TLS server's end
entity certificate back to a trusted root, then try the POSH path.
Alternatively, the TLS client could take a "happy eyeballs" approach
and retrieve all possible verification materials (PKIX, DANE, POSH) in
parallel before attempting the application-layer connection.

> Is that inferred from DNS if the target hostname is not in the
> original service domain or some other heuristic?  It seems fair to 
> me to only require the POSH part if the certificate presented is 
> invalid for reasons such as subjectAltName mismatch, which
> precludes starting the POSH operations before the application
> handshake.

I think this text is purely informational, since it doesn't have any
impact on the protocol (TLS negotiation) operations themselves.

> Similarly, I can't see anything obviously wrong with letting the 
> application handshake complete, then performing the POSH
> operations before deciding the application connection is not
> suitable and should be terminated before being used.  Is the MUST
> in this section mandating the order of operations necessary for
> some other reason?

As mentioned above, the MUST here is perhaps a bit silly because it's
so obvious. I think there is a better way to word it...

OLD
   POSH processes MUST be complete before the end of the TLS handshake
   for the application protocol, so that the TLS client can perform
   verification of reference identifiers.

NEW
   Clearly, POSH processes need to be completed before the end of the
   TLS handshake for the application protocol, so that the TLS client
   can perform verification of reference identifiers.

> In section 6, you state that ideally, caching of the certificate 
> obtained via POSH should be based on the expiration time of the 
> certificate.  I think this might be a little too trusting, as it
> ties delegation validity to certificate expiry.  If I trust 
> hosting.example.net to host my service today, that doesn't mean I
> will continue to trust them until their certificate expires.  HTTP 
> cache-control headers might be a useful way of indicating a short
> term trust though.

You make a very good point. I think this needs to be worded more
carefully, because caching of the certificate itself doesn't
necessarily apply a long-lived decision or policy to expect the TLS
server for that domain to present that certificate (e.g., as you say
the hosted domain could certainly re-delegate to a new service before
the old service's certificate has expired). Matt and I will chat about
a better way to express this guideline (or define separate guidelines
for certificate expiry and delegation expiry).

Thanks again,

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJR9AHOAAoJEOoGpJErxa2p8RkQAI2ddhxQ3dqTiYK0RzM2O34b
9a35xhDKi38uMwZ1dJChNmWtULwVQ7N87pL7V4k94/1XE7BJwi28hcj63KxnWwlE
mEAFzq0TcwWWl15zYD4J6fZXJN+glp/SCHLGULRC3Ue/zPCCofNTh1TD1mmoG7Cq
4IooLD6Cv4sLffFh0neCj0vkTKGh6HW3KbX/32qbL8mEK3cdUcQCpmDtTt/I8TXQ
aP79eXBphoqBZSN4325ULKXA0pOjvEHELpETPf3GmYJIunc0D2djssaal6Ll05Gl
tDSJUyry4OwTviPVwW1lZqYqFQ5sQLYzXxytKW84DZt+os9OzTmyczDsD/6UutBJ
Drk1Pypx29OMzHDPvRNImatGvV6DFGtrONpB/VgHS/NOgZUdT480bvDftImtXDcV
R1ribE5wRNW0qh7jMtiV9DaLeBZQdwcPYW0ISjGWqX0Tiisrdl1/KQZsiv4t8FYu
yQQN/kROSu3dUZ7Xkr6Yld7L38kKeXitIu6sETelkTEXdgE5SLxvELdcVBSAwrCn
YEz7xwvis2I4r3y9MdVrrRPDw1EAens/dujxyJusrwhV9vukElbdVcSyGs9irWyS
UbJiBem490nJYqCJppT1Dc5FOS6beQsr+nhxtRXAFb4znCmkZ56a0El0CGnBaxFE
NXS7PwyyhyEhYyRqxzFa
=b0dw
-----END PGP SIGNATURE-----