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

From: Julien Meuric <[email-masked]>
Date: Tue, 1 Dec 2015 18:02:57 +0100

Hi David,

Thanks a lot for this thoughtful review. I hope the authors will be able 
to respond soon.

Please note that the I-D has not been sent to the IESG yet, but is 
expected to after resolving your comments.

Cheers,

Julien

Dec. 01, 2015 - [email-masked]:
> 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.
>
> 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?
>
> 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.
>
>
> 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?
>
>

---

From: DIEGO LOPEZ GARCIA <[email-masked]>
Date: Tue, 8 Dec 2015 15:59:47 +0000

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 <[email-masked]<mailto:[email-masked]>> 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/

e-mail: [email-masked]
Tel:    +34 913 129 041
Mobile: +34 682 051 091
----------------------------------

________________________________

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

---

From: Julien Meuric <[email-masked]>
Date: Wed, 9 Dec 2015 16:36:16 +0100

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 -
[email-masked]:

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
<[email-masked]>
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,

--

Dr Diego R. Lopez

Telefonica I+D

Tel:    +34 913 129 041

Mobile: +34 682 051 091

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