[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [TLS] TLS 1.2 draft comments
<speaking for mysef....>
<home_pw@xxxxxxx> writes:
> Inline comments, for 7 fragments of the I-D:-
>
>
> 1. - The connection is private. Symmetric cryptography is used for
> data encryption (e.g., DES [DES], RC4 [SCH], etc.). The keys for
> this symmetric encryption are generated uniquely for each
> connection and are based on a secret negotiated by another
> protocol (such as the TLS Handshake Protocol). The Record
> Protocol can also be used without encryption.
>
> There are errors both technical and semantic in the above. Fortezza connections
> don't have unique keys per connection. We also need to stop including within
> 'key' objects such as "mac secrets." Furthermore, the secret
> may always not be "negotiated" by TLS. Furthermore, if the Record Protocol
> can be used without encryption, we can hardly have the privacy asserted
> in the topic sentence: without encryption, its hard to get the data
> origin authentication of the TLS application messages that allows for
> expressing the very expectation of pairwise privacy!
> 2. - The connection is reliable. Message transport includes a message
> integrity check using a keyed MAC. Secure hash functions (e.g.,
> SHA, MD5, etc.) are used for MAC computations. The Record
> Protocol can operate without a MAC, but is generally only used in
> this mode while another protocol is using the Record Protocol as
> a transport for negotiating security parameters.
>
> Keep the point about RP can operate without a MAC, strike
> the general qualifier. Either one can or cannot...operate without
> MacTags. We readers don't need protocol design advice from TLS WG
> stuffed into an interoperability spec, thanks!
>
> 3. One such encapsulated protocol, the TLS Handshake
> Protocol, allows the server and client to authenticate each other and
> to negotiate an encryption algorithm and cryptographic keys
>
> While we are at it, lets get this accurate."One such encapsulated protocol, the TLS Handshake
> Protocol, allows the server and client to authenticate each other and
> to negotiate a __ciphersuite, key, and varios secrets.__" If I argue with myself,
> the word negotiate should really become "agree". In combination
> with the first use of the ciphersuite and keys, the final KDF executes
> an "agreement" between the named parties roles, as to those objects. One
> is forced to (I) use, (2) rely, and (3) agree, in the final protocol.
>
>
>
> 4. The peer's identity can be authenticated using asymmetric, or
> public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
> authentication can be made optional, but is generally required
> for at least one of the peers.
>
>
> how about: The peer's identity can be authenticated using asymmetric, or
> public key, cryptography (e.g., RSA [RSA], DSS [DSS], etc.). This
> authentication can be made optional, but is generally required
> for at least one of the peers __in order to establish appropriate assurance for
> the key exchange component of a ciphersuite.__"
>
> 5. The negotiation of a shared secret is secure: the negotiated
> secret is unavailable to eavesdroppers, and for any authenticated
> connection the secret cannot be obtained, even by an attacker who
> can place himself in the middle of the connection.
>
> How about: The negotiation of a shared secret is secure: the negotiated
> secret is unavailable except to the server and client, each party can confirm
> the other possesses the secret, and for any authenticated
> connection the secret cannot be _obtained from the wire_ , even by an attacker who
> can place himself in the middle of the connection.
In general, I don't agree that your proposed changes improve the
situation. This text (or minor variants) dates back to TLS 1.0 (and I
suspect back to SSLv3). Does anyone else in the WG support these
changes.
> 6. One advantage of TLS is that it is application protocol independent.
> Higher level protocols can layer on top of the TLS Protocol
> transparently. The TLS standard, however, does not specify how
> protocols add security with TLS; the decisions on how to initiate TLS
> handshaking and how to interpret the authentication certificates
> exchanged are left up to the judgment of the designers and
> implementors of protocols which run on top of TLS.
>
> To address EAP-TLS session resumption rules and TLSPSK rules on self-signed certs etc:
> the decisions on how to initiate TLS
> handshaking and how to interpret the authentication certificates
> exchanged are left up to the judgment of the designers and
> implementors of protocols which run on top of _or below_ TLS.
I don't see the virtue of this change either. TLS-PSK doesn't run
below TLS and this WG is not in the business of standardizing
anything EAP.
> 7. Concerning section 1.1:
>
>
> " - Allow the client to indicate which hash functions it supports.
>
> - Allow the server to indicate which hash functions it supports
>
> - Addition of support for authenticated encryption with additional
> data modes."
>
> distinguish indicating hash functions, from mac functions. hash functions used in securing
> the handshake are not the same as mac functions used in the record-layer. Without
> reading further, I don't know which are being referred to in this summary.
I'll put this on the list of things to change.
> I don't know what "authenticated encryption" is, only that support for it has
> been added. Apparently, it has "data modes". Its presumably not a confidentiality
> service. Its presumably not the privacy service. Its X. From the form of the
> summary, it may be an X.800 mechanism, not a service.
"authenticated encryption wiht additional data". It's combined
confidentiality and message integrity in a single algorithm, as is
explained later in the document.
-Ekr
_______________________________________________
TLS mailing list
TLS@xxxxxxxxxxxxxx
https://www1.ietf.org/mailman/listinfo/tls