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

[Stephen Farrell <[e-mail]>]

Hiya,

On 11/29/2012 12:05 AM, Martin Rex wrote:
>> 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_.

Ah, you're right there, thanks. Silly me.

I think we agree about all the rest.

Thanks,
S.

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