Re: [TLS] Impact of draft-ietf-mptcp-api on TLS

[[e-mail] (Martin Rex)]

> Geoffrey Keating wrote:
>> 
>> Maybe a related example will help: suppose the user is trying to
>> connect to https://198.51.100.3.  There is an HTTP proxy configured,
>> so what the browser actually does is make a TCP connection to
>> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the
>> SSL negotiation.  The certificate still has to mention 198.51.100.3,
>> and doesn't have to mention 192.0.2.99.
>> 
>> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or
>> whatever), then 198.51.100.3 is the address that has to appear in the
>> certificate, even if the connection is redirected to some other
>> endpoint, even if the redirection happens before any data is actually
>> sent on the connection.

Thanks for the example!
That is what I had in mind (but failed to properly explain).


Stephen Farrell wrote:
> 
> Right. And I think that ignoring excludedSubtrees that's all
> fine

HUH?

With "excludedSubtrees", are you thinking of X.509 Name Constraints
(on IP addresses as subject alt names)?

There is no such thing as an "excludedSubtrees" return parameter
defined for the PKIX "Basic Path Validation":

  http://tools.ietf.org/html/rfc5280#section-6.1.6

   6.1.6. Outputs

   If path processing succeeds, the procedure terminates, returning a
   success indication together with final value of the
   valid_policy_tree, the working_public_key, the
   working_public_key_algorithm, and the working_public_key_parameters.


Name Constraints must appear only in CA certificates, Name Constraints
are meaningful and visible exclusively to the internals of the Certificate
Path Validation function, and apply exclusively to Names that are
actually _present_ in subordinate certificates on the path and to the
value of Names _exactly_ as they appear _in_the_certificate_.


>
>        and the right thing is to say that the TLS implementation
> ought only compare the address of with which it chose to connect
> for a client or the 1st subflow for a server against certs, if
> it needs to bother with that.

I agree, a note should probably added to very very strongly discourage using
any of the characteristics from the resulting connection for performing
server endpoint identification or a real server authentication.  Only
original/trustworthy information ought to be used that existed before
trying to establish the actual network connection with the peer.

An indirection through a "trusted directory" (secure is not sufficient)
would be OK, such as a trusted local configuration, a lookup in a secure
directory (something that existed in DCE), or e.g. transformation through
a DNSSEC-protected TLSA lookup according to DANE.


> 
> I'm not sure what to say about excludedSubtrees though.

If this is about X.509 Name Constraints, then IMO nothing should be said
within mptcp.  It is a matter completely internal to PKIX certificate
path validation.


-Martin