Re: [TLS] draft-nir-tls-eap-03

[Yoav Nir <ynir@xxxxxxxxxxxxxx>]

Hello,

Thank you for reviewing our draft and for your helpful comments.

With regard to section 1 and the abstract, I agree that the abstract  
is too long and a lot of the stuff that's in the abstract would be  
more appropriate in section 1. We will rewrite them along those lines  
in the next iteration.

Regarding section 3, we will make the distinction in the text between  
TLS 1.1 and 1.2. We certainly do not wish to restrict our draft to TLS  
1.2.

Regarding section 4.2 (comment (5)) I also believe that identity  
protection is important, but that belief is not universally shared.  
For example, the TLS-PSK protocol does not provide it. I'm not sure  
what I can do to elaborate more on this, except to say (as we have)  
that "we believe that identity protection is a worthy enough goal, so  
as to justify the extra round-trip.".  Can you suggest anything  
stronger?

In comment (6) you seem to agree with the choices we have made so  
far.  We will also of course fix the typos that you have pointed out.

Thanks again for taking the time to review our draft.

Yoav

On Apr 24, 2008, at 9:42 PM, Alfred HÎnes wrote:

> Hello,
> I would like to submit a few comments on your Internet-Draft,
> draft-nir-tls-eap-03.
>
> (1)  Section 1
>
> Section 1 IMHO is too silent about the benefits obtained from
> this proposal.
>
> Arguably, there's too much stuff in the Abstract that at least
> should be restated or elaborated upon early in Section 1, e.g.,
> near the end of the second paragraph there.
>
> (2)  Section 2
>
> The second paragraph of Section 2 says:
>
>                                    [...].  Typically the AAA server
>   communicates using the RADIUS protocol with EAP ([RADIUS] and
>   [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
>
> It should better say:
>
>                                    [...].  Typically the AAA server
> |  communicates using the RADIUS protocol with EAP extensions  
> ([RADIUS]
>                                                   ^^^^^^^^^^^
>   and [RAD-EAP]), or the Diameter protocol ([Diameter] and [Dia-EAP]).
>
> (3)  Section 3.1
>
> The TLS extension framework now is part of rfc4346bis (already
> being operated upon by the RFC Editor), whereas 4366bis only
> specifies a few useful TLS Extensions using this framework.
>
> When it comes to updating the references, this makes things a bit
> complicated.  Perhaps the draft should clearly distinguish TLS 1.1
> and TLS 1.2 -- or it should restrict its scope to TLS 1.2.
>
> (4)  Section 3.4
>
> The assignment operator is missing in the formula for `verify_data`;
> it should be:
>
>     verify_data = PRF (MSK, ...) [0..11] ;
>                 ^
>
> The second-to-next paragraph apparently also should refer to this
> field:
>       vvvvvvvvvvvvvvvvvv
> |  The handshake_messages field, unlike regular TLS, does not sign all
>   the data in the handshake.  [...]
> ---    vvvvvvvvvvv
> |  The verify_data field, unlike regular TLS, does not sign all the  
> data
>   in the handshake.  [...]
>
> Also, at the end of that paragraph,    s/[TLS]and/[TLS] and/  .
>                                                       ^
> (5)   Section 4.3, alternative 2.
>
> Doesn't this variant suffer from a MITM vulnerability?
> This would totally invalidate the most significant contribution
> of this proposal, ID protection !
> If I do not err w.r.t. this threat, the draft should further
> elaborate on this issue.
>
>
> (6)  Section 10
>
> (6a)  s/reviewrs/reviewers/     (2x)
>
> (6b)  Re "Finished" / "EapFinished" / "InterimAuth"
>
> A possible alternative would have been to amend the Finished
> message format with an optional field indicating the nature /
> semantics of the particular instance of the message, and
> formally use the same handshake message for both purposes
> (subject to successful negotiation of tee_supported),
> but this variant would perhaps have been more complicated
> to specify within the extensibility rules of TLS; since
> there's no danger of namespace exhaustion for handshake
> message types, the selected design seems to be reasonable.
>
> (6c)  Re EAP exported keying material
>
> Don't make things overly complicated.
>
> The subject of the extension is TLS client authentication.
> Hence, the expected output is Boolean -- ok to proceed, or
> abort the TLS handshake.
>
> (6d)  Re identity protection
>
> That's a feature that will become even more important in the
> future.   There are already so many leaks for information
> passed around in the internet, and information privacy is
> one of the most valuable assets we have, that identity
> protection will be necessary more and more, and it's well
> worth a single additional round-trip!
>
>
> Kind regards,
>  Alfred HÎnes.
>
> -- 
>
> +------------------------ 
> +--------------------------------------------+
> | 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@TR- 
> Sys.de                     |
> +------------------------ 
> +--------------------------------------------+
>
>
> Scanned by Check Point Total Security Gateway.
>


_______________________________________________
TLS mailing list
TLS@xxxxxxxx
https://www.ietf.org/mailman/listinfo/tls