Re: [Emu] draft-ietf-emu-eaptlscert-04

[Mohit Sethi M <[e-mail]>]

Hi Hannes,

Thanks for the follow up. I have submitted a new version which should 
address your concerns. Here is a diff for your convenience:
https://www.ietf.org/rfcdiff?url2=draft-ietf-emu-eaptlscert-05

Please see in-line for details.

I believe that the draft is now ready for publication.

--Mohit

On 6/10/20 12:02 PM, Hannes Tschofenig wrote:
> Thanks for the update.
>
> A few more minor comments on -04:
>
> Section 4.1:
>
> "TLS 1.3 [https://tools.ietf.org/html/rfc8446] requires implementations to support ECC."
>
> This is only true absent an application profile defining something else.
> The UTA group has just adopted a WG item that defines such a profile.
>
> Hence, I suggest to add the remark about the profile. Something like
>
> "In the absence of an application profile standard specifying
> otherwise, a TLS 1.3-compliant application must support ECC."
Done!
>
> 4.2.  Updating TLS and EAP-TLS Code
>
> Why are you calling the section "updating code"? The suggestion in 4.2.1 does not require code update and whether something requires a code update depends what you have in the code already. Maybe you just need to enable the feature.  Updating the code is also a negative aspect because you are likely going to update the code on a regular basis anyway to fix bugs and to support new algorithms. Luckily TLS has the extension negotiation built-in and hence you can detect and negotiate new features on the fly.
I agree that all code indeed should be updated to fix bugs and 
vulnerabilities. However, updating applications and certificates is 
certainly different from updating the underlying TLS library and EAP 
implementation. Administrators in enterprise environments (where EAP-TLS 
is widely used) have great control over when and how the server and 
client updates are rolled out. The categorization in section 4 should 
help administrators to decide how to avoid the fragmentation problem. 
Whether it is issuing new certificates, updating the access points, or 
updating the TLS and EAP-TLS implementation. Nonetheless, I have added 
the following text: "This section discusses how the fragmentation 
problem can be avoided by updating the underlying TLS or EAP-TLS 
implementation. Note that in many cases the new feature may already be 
implemented in the underlying library and simply needs to be taken into 
use."
>
> 4.2.4.  Caching Certificates
>
> "The extension however necessitates a successful full handshake before any caching."
>
> This is not true. The spec defines a way to populate the cache by running a full handshake.
> However, you could also populate the cache by out-of-band means, for example by pre-distributing certs.
>
> The mechanism to re-run the handshake to populate the cache is, however, a safe fallback in case configuration changes and the pre-distributed certs become invalid. It is better to have a fallback.
>
> I thought I made that comment before.

You had raised this issue before and I had responded to you before. Here 
is the response again:

Where does RFC 7924 (https://tools.ietf.org/html/rfc7924) talk about 
populating the cache with an out-of-band mechanism? The text in Section 
1 of RFC 7924 clearly states that:  "This specification defines a TLS 
extension that allows a client and a server to exclude transmission 
information cached in an earlier TLS handshake.". Notice the "earlier 
TLS handshake" part. I certainly refuse to add or describe new 
functionality which isn't discussed in the original RFC.

>
> 4.2.3.  Compact TLS 1.3
>
> You are still stating "This naturally means that cTLS is not interoperable with previous versions of the TLS protocol."
>
> cTLS is a compression of TLS, which means that you can fall-back to TLS, if the other peer does not support cTLS. As mentioned in my previous email, I don't understand why you are mentioning this aspect at all given that this document is about certificate size reduction.
I understand your desire of making cTLS look good. I am not sure how 
hiding the information that cTLS doesn't interoperate with older 
versions of TLS helps. Anyhow, I have removed that sentence since 
progressing the draft at this is stage is more important than arguing 
over one sentence.
>
> Raw Public Keys
>
> I wonder whether you should mention the possibility to use RPKs (https://tools.ietf.org/html/rfc7250) in Section 4.1.2 because those would be a fairly obvious choice in EAP-TLS given that we are talking about a nailed up connection between the EAP peer and the EAP server. This would obviously reduce the overhead associated with certificates considerably.

Added a new sub-section.

With this, I believe that all issues are resolved and the document is 
ready for publication.

>
> Ciao
> Hannes
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
>
> _______________________________________________
> Emu mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/emu