Re: [TLS] Comments on draft-rescorla-tls-opaque-prf-input-00.txt

[Mike <[e-mail]>]

This I-D is no longer in the repository; is there a plan to renew it?

One comment:

Why is it necessary for the server's opaque input to be exactly the
same length as the client's?  Could it be left up to the application
to decide if the server's opaque input is acceptable?

Mike


Simon Josefsson wrote:
> Hi.  I have read the document and wrote down some comments, that I try
> to distill into this e-mail.  Take this post for what its worth, an hour
> or so worth of looking at the document and composing the feedback.  I
> may have misunderstood something, and in that case, I would appreciate
> clarifications.
> 
> In general, I believe the document is in good technical shape, and that
> implementations of it should be possible.
> 
> The abstract should spell out PRF, I suggest to replace:
> 
>    This document describes a mechanism for using opaque PRF inputs with
>    Transport Layer Security (TLS) and Datagram TLS (DTLS).
> 
> with
> 
>    This document describes a mechanism for using opaque pseudo-random
>    function (PRF) inputs with Transport Layer Security (TLS) and
>    Datagram TLS (DTLS).
> 
> The introduction, section 1, could be improved by also mentioning the
> PRF term.  I suggest to change:
> 
>    The client and server each contribute a Random value which is then
>    mixed with secret keying material to produce the final per-
>    association keying material.
> 
> into:
> 
>    The client and server each contribute a Random value which is then
>    mixed, using a pseudo-random function (PRF), with secret keying
>    material to produce the final per-association keying material.
> 
> The title of section 3.2 ('PRF Modifications') is miss-leading because
> the PRF is not modified by this document.  What is modified by the
> document is the algorithm described in section 8.1 of RFC 4346.  I
> suggest to change the title of section 3.2 to 'Modifications to Master
> Secret Computation'.
> 
> The observation in the previous paragraph may suggest that a better
> title for the entire document would be 'Opaque Inputs to Master Secret
> Computation for TLS'.  The document only discuss new PRF inputs to one
> particular use of the PRF.  The document do not discuss new PRF inputs
> to all PRF computations, which could be inferred from the current title
> 'Opaque PRF Inputs for TLS'.  I got a flawed impression of the goals
> with the document after reading the title and not having read much of
> the details in the document.
> 
> Section 3.2 uses terms 'PMS' and 'MS' without explanation, and there is
> no references to the appropriate place in RFC 4346 that is modified.  I
> suggest to replace the current paragraph:
> 
>    When the opaque PRF input feature is in use, the opaque PRF input
>    values MUST be mixed into the PRF along with the client and server
>    random values during the PMS->MS conversion.  Thus, the PRF becomes:
> 
> with the following:
> 
>    When the opaque PRF input feature is in use, the opaque PRF input
>    values MUST be mixed into the PRF along with the client and server
>    random values during the pre-master secret to master secret
>    conversion (section 8.1 of RFC 4346).  Thus, the step becomes:
> 
> The final paragraph in section 3.2 reads:
> 
>    Because new extensions may not be introduced in resumed handshakes,
>    mixing in the opaque PRF inputs during the MS->keying material
>    conversion would simply involve mixing in the same material twice.
>    Therefore, the opaque PRF inputs are only used when the PMS is
>    converted into the MS.
> 
> The statement is not specific to resumed session, as far as I can tell.
> Further, there is already a section 4.3 that explain the interactions
> with resumed handshake (a forward reference would have helped me).  I
> believe it would be clearer to drop the reference to resumed handshakes
> here, and focus on the assertion itself, because it is helpful in
> understanding the design choice.  I suggest to drop the first line, and
> to add some references and word explanations, making the paragraph read:
> 
>    Mixing in the opaque PRF inputs during master secret to keying
>    material conversion (see section 6.3 of RFC 4346) would simply
>    involve mixing in the same material twice.  Therefore, the opaque PRF
>    inputs are only used when the premaster secret is converted into the
>    master secret.  See also section 4.3.
> 
> For symmetry between (all in section 3.1):
> 
>    If a client requires the opaque PRF input feature but
>    the server does not negotiate it, the client SHOULD generate a fatal
>    "handshake_failure" alert.
> 
> and:
> 
>    In this
>    case, the server should generate a fatal "handshake_failure" alert.
> 
> I suggest the last 'should' be in upper case.
> 
> In section 4.1, I suggest to add something like this:
> 
>    This extension enables client and servers to send significant amount
>    of data "out-of-band" to each other, which can be abused to leak
>    information.
> 
> Finally, I wonder whether the size limit of the opaque prf inputs is
> appropriate.  It is currently limited to 64KB.  This is larger than what
> would be justified by entropy to better seed the PRF, where (if I
> understand the cryptography properly) you'd typically use 128 or 256
> bytes.  However, 64KB may be too limited if, as is suggested by the
> document, the data will be in some pre-agreed format that the client and
> server can parse and do something intelligible with.  This also begs the
> question whether there should be an optional type-indicator present, to
> indicate the format of the opaque data?
> 
> /Simon
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/tls
> 
> 

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