On 9/1/17, Kyle Rose <[email protected]> wrote:
> I am strongly in favor of moving this draft toward standardization.
> This is tremendous work that will eliminate entire classes of attacks
> against protocols that depend on synchronized time.
>
> A few comments:
>
> (1) I couldn't figure out if it is possible for the client to request
> multiple cookies with time synchronization requests. If it isn't, it
> seems like it should be to avoid the inevitable re-establishment of
> keys if the client's cookie pool permanently drops by one every time a
> packet is lost. Being able to request more than one cookie will enable
> the client to maintain the recommended pool of 8.
That's exactly what the NTS Cookie Placeholder extension is for.
The client MAY include one or more NTS Cookie Placeholder
extension field, which MUST be authenticated and MAY be
encrypted. The number of NTS Cookie Placeholder extension
fields that the client includes SHOULD be such that if the
client includes N placeholders and the server sends back N+1
cookies, the number of unused cookies stored by the client
will come to eight. When both the client and server adhere
to all cookie-management guidance provided in this memo, the
number of placeholder extension fields will equal the number
of dropped packets since the last successful volley.
> (2) In section 5, the description of the record type field seems
> wrong. It says q( A 15-bit integer in network byte order (from
> most-to-least significant, its bits are record bits 7-1 and then
> 15-8). ). This seems to imply that (for example) the value 16385 would
> be encoded as 000000100000001 when read from left-to-right in the
> given diagram, when I believe it should be encoded as 100000000000001.
> I would just lose everything between the parentheses: it seems
> sufficient to say that record type is a 15-bit unsigned integer in
> NBO.
Already fixed in git.
> (3) Section 5.2 states that key material "SHALL" be extracted
> according to RFC 5705. What is the plan if some TLS 1.3-specific
> mechanism deprecates 5705?
Current TLS 1.3 drafts swaps the KDF implementation from TLS-PRF for
HKDF but keep the interface exactly the same. The intent, which seems
clear at least to me, is that anything which currently uses RFC 5705
will use TLS 1.3's exporter to extract keys from TLS 1.3 sessions.
Once TLS 1.3 is finalized, we can publish an update to clarify this if
it isn't clear enough already.
If even the *interface* changed then we'd have to do an update for
sure, but I think the odds of that approach nil.
_______________________________________________
TICTOC mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tictoc
