Re: [secdir] secdir review of draft-ietf-pce-pceps-06

[Julien Meuric <[e-mail]>]

Hola Diego,

Thank you for the feedback. Many of us are aware of "pressing issues around the end of the year", but it's always good to know what a silence mean.

Cheers,

Julien

Dec. 08, 2015 - [e-mail]:

Hi,

Thanks for the review and comments. I plan to address the actions I include inlined below during the coming days, once the current pressing issues around the end of the year (what made me delay in my reply as well) are over. I’ll upload a new version according to them and the comments we have recently received, mostly from Tom Petch.

On 1 Dec 2015, at 07:21 , David Mandelberg <[e-mail]> wrote:

Hi,

I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments.

I have a few concerns about this draft, detailed below. Otherwise it looks good though. As such, I think this draft is Almost Ready.


Major:

In section 3.4, the text about cipher suites requires support for negotiation of some cipher suites that I think are considered comparatively weak (primarily TLS_RSA_WITH_3DES_EDE_CBC_SHA). Is there a reason for the choice of suites that (I believe) are considered relatively weak? Also, does "implementations MUST support negotiation of <X>" mean that <X> must be implemented as an option, or that <X> must be implemented and enabled for use? If the latter, this might prevent people from disabling old cipher suites as new vulnerabilities are discovered. As I understand it, PCEP messages are sent unicast, so I don't see the value in enabling less secure cipher suites in situations where both endpoints are known to support more secure suites.

DRL> The listed ciphersuites are inspired (as said in the acknowledgements) in what is listed in RFC, as the authors perceived a clear parallelism between the cases of PCE and RADIUS. I know the discussion on the required ciphersuites was long and a compromise between strength and common availability (by the moment of that discussion) was made. I acknowledge things have changed since then and I am happy to change the list, or even to make a direct reference to an up-to-date list that is likely to well reasonably well maintained.

DRL> The negotiation issue you mention is there for a similar reason, and it can be eliminated as well, especially if we could have the reference to an up-to-date list.

Section 3.4 says "Certificate validation MUST include the verification rules as per [RFC5280]." Assuming that is referring to Section 6 of 5280, do you have any guidance on Section 6.1.3, step a.3 (revocation testing)? I.e., are PCEPS implementations expected to download CRLs, use OCSP stapling, or something else?

DRL> I think we can RECOMMEND that PCEPS implementation incorporate revocation methods (CRL downloading, OCSP…) according to the trusted CA policies

Section 4.1 talks about the use of DANE/TLSA to authenticate a TLS server. While TLSA is sufficient for authentication, it is not sufficient for authorization, because anybody with a DNSSEC-enabled domain can create a valid TLSA record. And that's fine, as long as authorization is properly set up as described in section 3.5. However, the other two authentication models (PKI, and a list of acceptable certificate fingerprints) can be sufficient for authorization if only authorized parties are issued certificates or have their fingerprints listed (respectively). To avoid confusion, it would be nice if section 4.1 explicitly said that the server's domain name must be authorized separately, as TLSA does not provide any useful authorization guarantees.

DRL> Will do!

Minor:

In section 3.3, I'm confused about the StartTLSWait timer. Is the timer started after the TCP connection is established (what the draft says) or after a StartTLS message is sent? If the latter, is the timer started even if a StartTLS message has already been received?

DRL> The StartTLSWait timer is started after the StartTLS message is sent, you are right there is an error in the draft, and once the StartTLS exchange is made the procedures to belong are those relating to TLS handshake. This implies that a StartTLS sent in reply to the peer’s StartTLS does not start the timer. It will be corrected.

Be goode,

--

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez
Telefonica I+D
http://people.tid.es/diego.lopez/" class="" rel="nofollow">http://people.tid.es/diego.lopez/

e-mail: [e-mail]
Tel:    [phone]
Mobile: [phone]
----------------------------------

---

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição