Re: [TLS] TLS 1.2 draft comments

[EKR <[e-mail]>]

<[e-mail]> writes:
> 1. signature
>
> "master secret
>        A 48 byte secret shared between the two peers in the connection."
>
> Is it appropriate to now specify the length of this, and the client random component
> of the hello nonces? If so, give a rationale for the value in light of the fundamental
> PRF architecture changes going on in TLS 1.2

I don't think there really is a rationale. At some level, this is arbitrary,
but the chosen values are fine ones.


> Right now, this all defines a particular signature for the 
>        key_block = PRF(SecurityParameters.master_secret,
>                           "key expansion",
>                           SecurityParameters.server_random +
>                           SecurityParameters.client_random);
>
> If in TLS1.2 a PRF MAY be defined by a ciphersuite and not by the standard, need it have the same 
> signature as the TLS PRF of old?

At the Montreal IETF, the consensus was to keep the signature/API the
same.


> 2. wrapped KEK/IVs in finished
>
> Im dubious about the new/amended means of protecting the integrity of the handshake, in the
> finished process. I cannot follow all its diddling with masks, and its impact on wrapped key/iv
> mechanisms when creating the first enciphered block under a server.write key. This may be 
> more Peter problem, than spec problem. Perhaps I just have to read it a 100 times, more.

What section are you talking about?


> 3. timing channels vs key
>
> This is all funny on first reading, given all the recent discussion of NULL MAC in general!:
>
>  Implementation Note: Canvel et. al. [CBCTIME] have demonstrated a
>        timing attack on CBC padding based on the time required to
>        compute the MAC. In order to defend against this attack,
>        implementations MUST ensure that record processing time is
>        essentially the same whether or not the padding is correct.  
>
> Mac secrets are not "key", and are therefore assured not to influence the keyed
> confidentiality mechanism.  if you use a secret vs key in a crypto SEF, you get what 
> you expect. 

That's not what's going on here. I suggest you read the referenced
paper for the background.


> 4. AEAD
>
> well at least I know what it is now, and how it relates to compression. Ill study the background issues
> to this some more, offline, before commenting in detail.
>
> But, interesting to see null length MAC getting involved, again -)
>
> And, interesting to see the failure alert: "fatal bad_record_mac alert"
>
> If I now calculate 2 + 2 = 5, the confidentiality service based on
> an AEAD mechanism is providing data origin authentication, and that
> DOA can control the record_layer integrity service, and the
> disconnect event. Hmm.
>
> I don't like it, at first glance. Its smells wrong. I need further
> rationale, in terms of function and assurance claims.

This is a chartered work item, so I think you're going to need to make
a stronger case if you want it removed.


> 5.  "However, you SHOULD never send data over a link encrypted with 40 bit
>    security unless you feel that data is worth no more than the effort
>    required to break that encryption.
>
> I think its time for this to go... if only because we have no "links", above the TLS. We have
> channels or bridges. If its kept, perhaps consider
>
>   "However, you SHOULD never send data over a link encrypted with 40 bit OR LESS
>    security unless you feel that data is worth no more than the effort
>    required to break that encryption.

Well, the 40-bit algroithms have been deprecated in TLS, so this 
section should simply be removed.


> This updates the text to address ciphersuites with null confidentiality regimes.
>
> 6. I notice
>               case certificate_url:     CertificateURL;
>                case certificate_status:  CertificateStatus;
>
> These need adding to the "major changes section of the summary". I can not see these in
> RFC  4346. 
>
>       enum {
>           hello_request(0), client_hello(1), server_hello(2),
>           certificate(11), server_key_exchange (12),
>           certificate_request(13), server_hello_done(14),
>           certificate_verify(15), client_key_exchange(16),
>           finished(20), (255)
>       } HandshakeType;
>
> Given the description (they are part and parcel of the extension mechanism from other docs
> being folded into TLS 1.2) I think I see what's going on.

They're being moved back out again, so not really 

> a) I like certificate URL, and it moves us beyond Nescape's tunnel vision on the format
> of the bag of certs (forwardCertPath). The bag can now contain HSM certs, for example
> from the client, where the architect has defined an "enhanced X.509 Certificate" cert type, per 
> the rationale. It can also be a set of SAML assertions, getting us beyond X.509's aging formats.
>
> There is a strong danger that this extension will get badly abused, I feel. And, many
> military implementations are NOT going to be willy-nilly going out and resolving URLs 
> sent by a (enhanced) handshake protocol, even if the handshake messages are being
> protected by an active (assured and sufficiently strong) TLS Connection. I can see such
> handshakes being used to ping a mgt port for a given user, and thus go collect data from certified 
> repositories (over TLS), stuffing their response in caches. This is just X.500 revisted, tho.
>
> b) What nut pushed for that OCSP stuff in certificate_status? Don't folks understand that it was just 
> to annoy VeriSign over the Micali patents?
>
> With TLS extensions, we will be able to recover cert status from a TLS responder, without
> bothering with OCSP. It can be authoritative as OCSP can be, once it starts putting
> digital signatures on sets of record fragments.

TLS Extensions is already a Proposed Standard (RFC 3546). It just
got moved into this document for editorial reasons.

-Ekr

_______________________________________________
TLS mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/tls