Re: [keyassure] Issue #17 - Should draft-ietf-dane-protocol

[Stephen Kent <[e-mail]>]

Sorry to be so late in replying, but travel, vacation, etc.

>...
>But any assumption on the side of the sender, to throw garbage at the
>server in a security protocol and expect the server to simply ignore
>anything that doesn't fit a very clear and explicit protocol specification,
>would be totally flawed.
>
>Several protocol are in a poor shape because early implementations
>were "liberal in what they accept"ed far beyond reasonable levels.

agreed

>  > If one tries to use an offered path, life can become more complex,
>  > and, in this example, an unnecessary validation failure occurs.
>
>If all that it takes to build a cert path, for which a full cert
>path validation can be performed, is to ignore certs at
>the end of the original/given certs path, then there certainly
>is a bug in the code doing the cert path validation.

buggy code exists. I don't suggest that we contort extant specs to accommodate
such code, but we also should be mindful of pervasive limitations when
developing new specs.

>Cross-cert scenarios are pretty messy, and there seem to be some
>very unresponsible approaches a cert path validation out in the wild,
>like automatic/silent AIA-chasing.

Using an AIA to locate a CA cert is exactly what we intended when that
extension was defined, to compensate for a lack of directory access/data.
i agree that AIA chasing can be evil, but it can be use for good as well :-).

>The straight-forward way for making cert path validation work
>in cross certification scenarios is to distribute cross-certs
>as trust anchors.

One could do that, but it ought not be necessary.

>  > Thanks for reminding me of the server->client TA list.  I agree that
>  > if the client send a path that terminates at one of those TAs, the
>>  server SHOULD accept it. But, isn't this an example of asymmetry in
>>  TLS, i.e., the client has no analogous capability to let he server
>>  know what set of TAs it will accept. So there is still a problem when
>>  one tries to use TLS as a peer secruity protocol, as opposed to the
>>  client/server model that is common for most public web site access.
>
>For the big majority of TLS servers, this is not a problem.  They have
>just one single credential/cert anyway, and if that doesn't work, there
>would not be a way to handshake around this problem.

agreed.

>The "Server Name Indication" is an existing TLS extension intended
>to help the server select a suitable server credential, for servers
>that have more than one available.  So for situations, where the
>server needs to know which TAs the client has available to verify
>the servers cert path, the obvious solution would be to define
>another TLS extension to convey this information and have the
>client include it in the ClientHello handshake message.

if DANE wants to define such an extension, and if the TLS WG agrees,
then that would be one way to address this issue.

>For SSL/TLS, announcing the "standard" list of TAs from the
>TLS X.509 PKI is very undesirable.  There are simply too
>many of them (~60), and when stuffing those into ClientHello,
>the size of the ClientHello would increase from typically <100
>octets today to >16 KByte, requiring a fragmentation of ClientHello
>(which a lot of implementations will break on, although it has
>always been a MUST support feature since SSLv3), and might
>incur a penalty from TCP slow start, besides wasting a lot
>of network bandwidth (on average).

agreed.

>The original design behind SSL was the real world.  An extremely
>weak server endpoint identification was considered good enough,
>which is why hardly anyone appears to have security concerns
>about a TLS X.509 PKI with a set of ~60 independent TAs that
>bootstrap trust to like ~600 seperately operated, omnipotent CAs,
>providing server admins a choice of functionally equivalent
>server certs over a very broad price range.

we disagree on the history here, but we should not pursue the discussion
on this list.

>For TLS client certs, if they're used at all, the most reasonable and
>most manageable setup is when the server admin (organization) issues
>those themselves, similar to the membership plastic cards that inhabit
>everybodies wallets.  And then, the announcement of the trusted CAs
>by the server when asking for the client cert is somewhat similar
>to the logos at the door of businesses which plastic cards they
>will accept from clients.

This is a re-statement of what I suggested in the 1997 MILCOM paper I cited
in a previous message.

Steve