Re: [tcpm] Looking for advice on a draft from the PCE working group

[Joe Touch <[e-mail]>]

On 7/1/2014 7:45 AM, Diego R. Lopez wrote:
> On 30 Jun 2014, at 18:28 , Joe Touch <[e-mail]> wrote:
>>>
>>> We are not proposing to use STARTTLS because, after discussing the
>>> different options for doing so in PCEP, we believe including it would
>>> translate into a change of the PCEP protocol:
>>> (1) against the original commitment of not changing it
>>> (2) would translate into a much longer adoption by implementations
>>
>> I don't understand or agree with either position. STARTTLS does not change the protocol; it precedes it.
>>
>> The complex mechanism below is, IMO, much less likely to be successfuly adopted than STARTTLS, which is widely used.
>
> As far as I know (RFC 2595, RFC 3207, RFC 4217, RFC 6120, RFC 2830,
> RFC 4642)

RFC4217 doesn't appear to use STARTTLS.
RFC6120 just refers completely back to RFC2595.

Section 2.1 of RFC2830 is a good example of performing STARTTLS in a 
non-plaintext command/response protocol (LDAP), and how simple it can 
and should be.

I now see your concern, but RFC2830 provides a great example of a very 
simple way to extend a protocol to address this issue. This further 
ensures that the security state (secure vs. not) is integrated within 
the protocol, so the protocol itself can disable commands if needed when 
security isn't available.

FWIW, Section 7 of RFC2595 gives a good summary of reasons why using a 
separate security port should be discouraged.

Joe


> STARTTLS is directly applicable to communication protocols
> based on plain-text command/response protocols. PCEP does not follow
> this model, so STARTTLS should become a new message or an object in the
> Open message. Both options imply changes in the PCEP protocol that look
> more complex than the suggested mechanism (or a dedicated port, if you
> pay attention to the discussion shared in the original message by Qin)


>
> Be goode,
>
>>
>> Joe
>>
>>>
>>> Be goode,
>>>
>>> On 28 Jun 2014, at 06:35 , Joe Touch <[e-mail]> wrote:
>>>
>>>> Hi,
>>>>
>>>> On 6/24/2014 4:03 AM, Qin Wu wrote:
>>>>> Hi, Joe:
>>>>> Sorry for late reply.
>>>>>
>>>>> Authors have been discussing a mechanism to enable secure PCEP via
>>>>> TLS without making changes to the current PCEP protocol or state
>>>>> machine.
>>>>>
>>>>> Since having a separate port has been discouraged, we suggest the
>>>> ? following approach based on discovery mechanisms or configuration and
>>>>> initial transport security assessment by the peer.
>>>>>
>>>>> 1) A PCE (given a combination of IP address and port) only supports
>>>>> one type of connection, either TLS or not.
>>>>
>>>> I'm not sure why that needs to be the case, given STARTTLS.
>>>>
>>>>> Note that a different IP
>>>>> address SHOULD be used for supporting both and will be considered as
>>>>> different PCEs.
>>>>
>>>> I don't quite understand this. Different IP addresses should be different PCEs anyway. If you want to support both encrypted and non-encrypted, why not use the existing TLS mechanism for that - STARTTLS?
>>>>
>>>>> 2) The PCC MAY discover whether the PCE is willing to connect,
>>>>> requires TLS or not via any of the discovery mechanisms.
>>>>
>>>> That seems reasonable, but doesn't answer why a PCE needs to support only one type of connection. The discovery could indicate "either" and let the client decide, e.g., if both are supported (again, via STARTTLS)
>>>>
>>>>> 3) When connecting to a PCE that enforces TLS, the PCC MUST start a
>>>>> TLS connection prior to any exchange of PCEP messages.
>>>>
>>>> Isn't that already what happens if TLS-only is used?
>>>>
>>>>> Any PCEP message
>>>>> received out of an appropriate TLS context will be rejected by the PCE
>>>>> with a PCErr (Error-Type=1, Error-value=3, TLV identifying the need for
>>>>> TLS) message. [Existing error message, new TLV]
>>>>
>>>> If non-TLS connections are rejected, then there shouldn't be any such messages seen AFAICT. I.e., that would be a TLS port that is configured to not support STARTTLS.
>>>>
>>>>> 4) If a PCC attempts to start a TLS connection with a PCE without
>>>>> success, it MAY attempt a further connection attempt without TLS on a
>>>>> different IP address if known, though that could imply a security
>>>>> degradation.
>>>>
>>>> I don't understand why a different address would be considered degraded access to the same PCE. That seems like a different PCE, as noted above.
>>>>
>>>> If you want to support degraded (non-secure) access, why not just support STARTTLS?
>>>>
>>>>> Several flows become possible this way, and discovery can be used to
>>>> simplify them but it is not essential for them to work. Let's consider them
>>>>>
>>>>> * With discovery (or config)
>>>>> 1.- PCC learn via discovery that the desired PCE require TLS.
>>>>> 2.- PCC initiates TCP connection and TLS handshake
>>>>> 3.- PCEP exchange within TLS context
>>>>
>>>> Makes sense.
>>>>
>>>>> ---
>>>>> 1.- PCC learn via discovery that the desired PCE does not use TLS.
>>>>> 2.- PCC initiates TCP connection
>>>>> 3.- PCEP exchange over TCP
>>>>
>>>> Makes sense.
>>>>
>>>>> * Without discovery - PCE requiring TLS
>>>>> 1.- PCC initiates TCP connection and TLS handshake
>>>>
>>>> Wouldn't the TLS handshake here fail? Why would the rest of the exchange occur?
>>>>
>>>>> 2.- PCEP exchange within TLS context
>>>>> ---
>>>>> 1.- PCC initiates TCP connection and attempts a PCEP OPEN message
>>>>> 2.- PCE rejects the message with a PCErr message (Error-Type=1, Error-value=3, TLV identifying the need for TLS(optionally))
>>>>> 3.- PCC initiates TCP connection and TLS handshake
>>>>> 4.- PCEP exchange within TLS context
>>>>
>>>> (see issue above)
>>>>
>>>>> * Without discovery - PCE not requiring TLS
>>>>> 1.- PCC initiates TCP connection
>>>>> 2.- PCEP exchange over TCP
>>>>> ---
>>>>> 1.- PCC initiates TCP connection and TLS handshake
>>>>
>>>> Why is this even attempted?
>>>>
>>>>> 2.- No TLS context established with PCE or error message received
>>>>> (optionally)
>>>>> 3.- PCC initiates TCP connection
>>>>> 4.- PCEP exchange over TCP
>>>>>
>>>>> What do you think of this approach?
>>>>>
>>>>> Also we like to point a related discussion happened on UTA mailing list:
>>>>> http://www.ietf.org/mail-archive/web/uta/current/msg00423.html
>>>>
>>>> Those points were raised on the TSVWG list too, but fail to address the key issue - insecure ports are insecure. Regardless of how many ports we allocate, it's no longer clear we should continue to deploy new insecure services on the Internet.
>>>>
>>>> Joe
>>>>
>>>>>
>>>>> Regards,
>>>>> Authors
>>>>> -----邮件原件-----
>>>>> 发件人: Joe Touch [mailto:[e-mail]]
>>>>> 发送时间: 2014年3月13日 23:58
>>>>> 收件人: Qin Wu; Diego R. Lopez; [e-mail]
>>>>> 抄送: [e-mail]
>>>>> 主题: Re: [tcpm] Looking for advice on a draft from the PCE working group
>>>>>
>>>>> Hi, Qin,
>>>>>
>>>>> On 3/13/2014 3:35 AM, Qin Wu wrote:
>>>>>> Hi, Joe:
>>>>>>
>>>>>> It is still not clear to me when we choose the same port and when we
>>>>>> choose the different port if we apply TLS to different protocols,
>>>>>
>>>>> It's simple to determine:
>>>>>
>>>>>       - if you designed your service before STARTTLS, then you needed
>>>>>       a separate port
>>>>>
>>>>>       - if you are designing your port now, you don't
>>>>>
>>>>>> Take SMTP, POP3,IMAP as examples:
>>>>> ...
>>>>>> It looks to me when we apply SSL to SMTP,POP3,IMAP, then SMTP, POP3
>>>>>> and IMAP with SSL support(i.e.,SMTPS,POP3S,IMAPS)
>>>>>>
>>>>>> Will usually choose the different ports.
>>>>>>
>>>>>> The same rule above is also applied to HTTP when we apply SSL to
>>>>>> HTTP(i.e., HTTPS).
>>>>>
>>>>> All of the above are good examples of the first part of the rule.
>>>>>
>>>>> Note that we have other assignments that now would be declined, because we've learned to do better. E.g., there would not be a POP2 or POP3 because we would expect POP to indicate the protocol version in-band. We also no longer assign multiple names for the same service, as was done for http/www, nor do we now assign multiple ports for the same service (80, 8080), nor do we now assign ports for development purposes  (http-dev).
>>>>>
>>>>> We've learned to do better.
>>>>>
>>>>> Joe
>>>>>
>>>
>>>
>>> --
>>> "Esta vez no fallaremos, Doctor Infierno"
>>>
>>> Dr Diego R. Lopez
>>> Telefonica I+D
>>> http://people.tid.es/diego.lopez/
>>>
>>> e-mail: [e-mail]
>>> Tel:    [phone]
>>> Mobile: [phone]
>>> -----------------------------------------
>>>
>>>
>>> ________________________________
>>>
>>> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
>>> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
>>> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>>> _______________________________________________
>>> tcpm mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/tcpm
>>>
>
>
> --
> "Esta vez no fallaremos, Doctor Infierno"
>
> Dr Diego R. Lopez
> Telefonica I+D
> http://people.tid.es/diego.lopez/
>
> e-mail: [e-mail]
> Tel:    [phone]
> Mobile: [phone]
> -----------------------------------------
>
>
> ________________________________
>
> Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
> This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at:
> http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>