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

From: Michael Procter <[email-masked]>
Date: Fri, 26 Jul 2013 10:54:29 +0100

I read draft-miller-posh-00 with interest, and have a couple of
questions about the expected usage.

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

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.

Regards,

Michael

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 27 Jul 2013 19:22:22 +0200

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

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

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

---

From: Philipp Hancke <[email-masked]>
Date: Sun, 28 Jul 2013 21:09:45 +0200

> so obvious. I think there is a better way to word it...

It isn't. In server-to-server XMPP what is typically done is to let the 
tls handshake succeed and only offer sasl external if the peer 
certificate is "valid". The same could be done for POSH... after the 
handshake is complete, look at the verification result. If it is valid, 
send stream features including external; if not, do the POSH dance.

That would typically be done in the application, not the TLS lib. Doing 
an asynchronous https request inside the verification is not something I 
would expect to be trivial.

---

From: Michael Procter <[email-masked]>
Date: Mon, 29 Jul 2013 11:25:30 +0100

On 28 July 2013 20:09, Philipp Hancke <[email-masked]> wrote:
> It isn't. In server-to-server XMPP what is typically done is to let the tls
> handshake succeed and only offer sasl external if the peer certificate is
> "valid". The same could be done for POSH... after the handshake is complete,
> look at the verification result. If it is valid, send stream features
> including external; if not, do the POSH dance.

Thanks, Philipp.  That is the sort of scenario I was thinking about,
which is why I questioned the MUST.  Doing the POSH lookup after the
TLS handshake seems fine, as long as the application doesn't try to
use the not-yet-verified connection until POSH completes.  I can't
think of a protocol reason why the TLS handshake must be held off
until POSH completes, unless you wish to withold a client cert until
the server is trusted.  That obviously doesn't apply if you aren't
doing mutual auth.

Regards,

Michael

---

From: Michael Procter <[email-masked]>
Date: Mon, 29 Jul 2013 11:34:56 +0100

Regards,

Michael

---

From: Michael Procter <[email-masked]>
Date: Mon, 29 Jul 2013 11:42:02 +0100

Regards,

Michael

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 31 Jul 2013 09:50:38 +0200

[...]
> so obvious. I think there is a better way to word it...

While implementing this I found another reason why this MUST doesn't work.

In XMPP we want DNA to have the ability to multiplex several domain 
pairs, with multiple remote domains.

However, at the time of the TLS handshake we only know a single remote 
domain (taken from the stream's from).

At any later time, the remote end may use this <db:result/> stuff to add 
another remote domain. This might trigger the POSH dance and clearly 
happens after the TLS handshake is done.

I would suggest removing this MUST.

---

From: "Matt Miller (mamille2)" <[email-masked]>
Date: Wed, 31 Jul 2013 08:18:50 +0000

On Jul 31, 2013, at 9:50 AM, Philipp Hancke <[email-masked]>
 wrote:

> In XMPP we want DNA to have the ability to multiplex several domain pairs, with multiple remote domains.
> 
> However, at the time of the TLS handshake we only know a single remote domain (taken from the stream's from).
> 
> At any later time, the remote end may use this <db:result/> stuff to add another remote domain. This might trigger the POSH dance and clearly happens after the TLS handshake is done.
> 

These are all good points.

I will note that there is general queasiness with suspending disbelief on a connection, accepting the TLS handshake but then actually verifying  (and potentially failing) the connection because of TLS failings; not the least of which is the potential for abuse is very very great.  This also means that any error reporting that one might get from their TLS implementations for better error reporting is lost.

However, the multiplexing case is important for XMPP (not sure about others).  We need to allow for that to work.

I'll confer with my co-author, and we'll try to come up with some text that preserved the intent without being overly constricting.

- m&m

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

---

From: Dave Cridland <[email-masked]>
Date: Wed, 31 Jul 2013 10:01:20 +0100

On Wed, Jul 31, 2013 at 9:18 AM, Matt Miller (mamille2)
<[email-masked]>wrote:

> I will note that there is general queasiness with suspending disbelief on
> a connection, accepting the TLS handshake but then actually verifying  (and
> potentially failing) the connection because of TLS failings; not the least
> of which is the potential for abuse is very very great.  This also means
> that any error reporting that one might get from their TLS implementations
> for better error reporting is lost.
>

If there is queasiness here it's misplaced. The case for abuse here is
predicated on the TLS handshake being the authorization, which it is not in
any SASL based protocol.

So in XMPP, we must already perform auth during the SASL exchange, and
during the <db:result/>, too.

If you have a protocol which conflates authentication and authorization, of
course, then the situation is different.

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 31 Jul 2013 15:38:55 +0200

[ removing [email-masked] since this is a general issue ]

On 7/31/13 11:01 AM, Dave Cridland wrote:
> <[email-masked] <mailto:[email-masked]>> wrote:
> 
> I will note that there is general queasiness with suspending 
> disbelief on a connection, accepting the TLS handshake but then 
> actually verifying  (and potentially failing) the connection
> because of TLS failings; not the least of which is the potential
> for abuse is very very great.  This also means that any error
> reporting that one might get from their TLS implementations for
> better error reporting is lost.
> 
> 
> If there is queasiness here it's misplaced. The case for abuse here
> is predicated on the TLS handshake being the authorization, which
> it is not in any SASL based protocol.
> 
> So in XMPP, we must already perform auth during the SASL exchange,
> and during the <db:result/>, too.
> 
> If you have a protocol which conflates authentication and
> authorization, of course, then the situation is different.

I don't think we want POSH to be limited to SASL application protocols.

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 31 Jul 2013 16:13:47 +0200

Am 31.07.2013 15:38, schrieb Peter Saint-Andre:
[...]
> I don't think we want POSH to be limited to SASL application protocols.

Nor do we want it to be limited to non-multi-tenant usecases.