Re: [TLS] draft-ietf-tls-extractor-03

["Joseph Salowey (jsalowey)" <jsalowey at cisco.com>]

Hi Alfred,

I initiated WGLC on this document. Please post your issues to the list.  

Thanks,

Joe 

> -----Original Message-----
> From: tls-bounces at ietf.org [mailto:tls-bounces at ietf.org] On 
> Behalf Of Alfred HÎnes
> Sent: Thursday, November 06, 2008 4:26 AM
> To: ekr at networkresonance.com
> Cc: tls at ietf.org
> Subject: [TLS] draft-ietf-tls-extractor-03
> 
> Eric,
> I have followed up and reviewed the most recent version of 
> your TLS Extrcator I-D, draft-ietf-tls-extractor-03.
> 
> Although sent (off-list) almost three weeks before the -03 
> version has been posted, my (mostly editorial) comments on 
> the -02 version have not been addressed in the -03.  Please 
> give me an indication should that message have been lost.
> 
> All issues raised in that message still hold, and one 
> additional technical issue has been introduced in the -03 
> version -- see below.
> 
> To recall, the only non-editorial issue raised in that message was:
> 
> > (6)  Section 6
> >
> > I do not understand why the third line appears in the table 
> in Section 
> > 6.  The string "master secret" is used in TLS to derive the 
> > master_secret from the pre_master_secret using the TLS PRF (Section 
> > 8.1 / page 64 of RFC 5246), and not to derive anything else 
> from the 
> > master_secret as specified by the method in Section 4.
> > [ Beware that the other three string values originated in RFC 4346
> >   that have been included in the table are indeed used in TLS with
> >   the master_secret as the first argument to the TLS PRF. ]
> >
> > Admittedly, it would perhaps be confusing to see such use, but I do 
> > not see a cryptographical argument making it necessary to 
> avoid this 
> > use, and hence enter this string into the registry.
> 
> Additional remark:
>   I you indeed want to keep the string "master secret" in the
>   registry, I suggest to *not* give [RFC5346] as a reference
>   (which I regard as misleading), but instead declare it as
>   "reserved by RFC{this}", or change the reference to [RFC{this}]
>   and attach a footnote to the registry, indicating that this
>   entry is a reservation only, not documentation of actual use.
> 
> 
> And that's the new issue:
> 
> In Section 4, the line
> 
>            opaque context<0..2^16-1>;
> 
> has been added, which unfortunately does not match the 
> description of the computation given in the initial part of 
> that section.
> IMHO, for consistency, the above line should read:
> 
>            opaque context_value<0..2^16-1>;
>                          ^^^^^^
> 
> Kind regards,
>   Alfred.
> 
> -- 
> 
> +------------------------+------------------------------------
> --------+
> | TR-Sys Alfred Hoenes   |  Alfred Hoenes   Dipl.-Math., 
> Dipl.-Phys.  |
> | Gerlinger Strasse 12   |  Phone: (+49)7156/9635-0, Fax: -18 
>         |
> | D-71254  Ditzingen     |  E-Mail:  ah at TR-Sys.de             
>         |
> +------------------------+------------------------------------
> --------+
> 
> _______________________________________________
> TLS mailing list
> TLS at ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
_______________________________________________
TLS mailing list
TLS at ietf.org
https://www.ietf.org/mailman/listinfo/tls