Re: [Uta] Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with DISCUSS and COMMENT)

[Peter Saint-Andre <[e-mail]>]

We're getting there. :-) See below.

On 7/19/22 9:14 AM, Rob Wilton (rwilton) wrote:
> Hi Peter,
> 
> More inline ...
> 
>> -----Original Message-----
>> From: Peter Saint-Andre <[e-mail]>
>> Sent: 19 July 2022 14:59
>> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
>> Cc: [e-mail]; [e-mail]; [e-mail];
>> [e-mail]
>> Subject: Re: Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with
>> DISCUSS and COMMENT)
>>
>> Hi Rob, more follow-up inline.
>>
>> On 7/19/22 3:42 AM, Rob Wilton (rwilton) wrote:
>>> Hi Peter,
>>>
>>> Thanks for the further information.  I'm not sure whether we have quite
>> met in the middle yet, some further comments below.
>>>
>>>
>>>> -----Original Message-----
>>>> From: Peter Saint-Andre <[e-mail]>
>>>> Sent: 18 July 2022 18:56
>>>> To: Rob Wilton (rwilton) <[e-mail]>; The IESG <[e-mail]>
>>>> Cc: [e-mail]; [e-mail]; [e-mail];
>>>> [e-mail]
>>>> Subject: Re: Robert Wilton's Discuss on draft-ietf-uta-rfc7525bis-09: (with
>>>> DISCUSS and COMMENT)
>>>>
>>>> Hi Rob, I'm circling back to an earlier point in the thread to cover all
>>>> of the issues. (Thomas and I just discussed these topics, but Yaron was
>>>> not able to join our call because of illness.)
>>>>
>>>> On 7/14/22 9:06 AM, Peter Saint-Andre wrote:
>>>>> Hi Robert, thanks for the review. Comments inline.
>>>>>
>>>>> On 7/14/22 3:37 AM, Robert Wilton via Datatracker wrote:
>>>>>> Robert Wilton has entered the following ballot position for
>>>>>> draft-ietf-uta-rfc7525bis-09: Discuss
>>>>>>
>>
>> <snip/>
>>
>>>>>> (2)
>>>>>>               *  New protocol designs that embed TLS mechanisms SHOULD
>>>>>> use only TLS
>>>>>>                  1.3 and SHOULD NOT use TLS 1.2; for instance, QUIC
>>>>>> [RFC9001]) took
>>>>>>                  this approach.  As a result, implementations of such
>>>>>> newly-
>>>>>>                  developed protocols SHOULD support TLS 1.3 only with no
>>>>>>                  negotiation of earlier versions.
>>>>>>
>>>>>> Why is this only a SHOULD and not a MUST?  If a new protocol (rather
>>>>>> than an
>>>>>> updated version of an existing protocol) was being designed why would
>>>>>> it be
>>>>>> reasonable to design it to support TLS 1.2?  If you want to keep these
>> as
>>>>>> SHOULD rather than MUSTs then please can the document specify
>> under
>>>> what
>>>>>> circumstances it would be reasonable for a new protocol design to use
>>>>>> TLS 1.2.
>>>>>
>>>>> Although personally I'm open to MUST here, I'd like to discuss that with
>>>>> my co-authors (one of whom is offline this week).
>>>>
>>>> Unfortunately Yaron was not able to join our call, but Thomas and I
>>>> discussed it and we think there could be two different cases:
>>>>
>>>> (a) new security-focused protocols such as QUIC
>>>>
>>>> (b) new application protocols (say, for real-time collaboration)
>>>>
>>>> For (a), it definitely makes sense to use TLS 1.3 only (as noted in the
>>>> current text, QUIC uses the TLS handshake protocol with a different
>>>> record layer).
>>>
>>> Okay.  But I still note that the text for this is still only SHOULD rather than
>> MUST.  I can live with this, even though I still believe that MUST would be
>> better.
>>
>> The confusion arises from the fact that this bit of text is making
>> recommendations for two kinds of protocols: secure transport protocols
>> like QUIC and application protocols like IMAP. Their layering with TLS
>> is quite different. I think we probably want to say MUST 1.3 for the
>> former and SHOULD 1.3 for the latter, which would clear up your next
>> point...
> 
> Okay.  I'll leave it to the authors discretion, but I would suggest that it may be worth adding a sentence to indicate under what circumstances the SHOULD applies here.  I.e., you could add a sentence to your rationale to help justify when a new protocol might choose to use TLS 1.2 rather than TLS 1.3.

Here is the provisional text I just checked into GitHub, see 
https://github.com/yaronf/I-D/pull/464/files

###

* New transport protocols that integrate the TLS/DTLS handshake protocol 
and/or record layer MUST use only TLS/DTLS 1.3 (for instance, QUIC 
{{RFC9001}}) took this approach) and new application protocols that 
employ TLS/DTLS for channel or session encryption MUST use TLS/DTLS 1.2 
and/or 1.3.  Implementations would then adhere to the TLS/DTLS version 
used by the relevant protocol.

   Rationale: Although secure deployment of TLS 1.3 is easier and less 
error-prone than TLS 1.2 because of the need to follow the 
recommendations provided in this document for secure deployment of TLS 
1.2, development of new transport protocols is significantly more 
complex than simply re-using the existing support for TLS/DTLS in 
underlying libraries or operating systems as is usually done in 
application protocols.

###

>>>> For (b), we see reasons why it might make sense to build on top of both
>>>> TLS 1.2 and TLS 1.3 at the present time: for instance, implementations
>>>> might want to "cast a wide net" in terms of underlying library or
>>>> operating support and thus avoid the significant effort involved in
>>>> building a secure transport protocol such as QUIC. Naturally, this
>>>> advice will probably change in 7525ter a few years from now.
>>>
>>> Yes, I can see why it *might* make sense and implementations *might*
>> want to cast a wide net, which is why I think that SHOULD is better than
>> MUST.  I.e., SHOULD means that implementations must support TLS 1.2
>> unless they have a good reason not to, whereas MUST means that they are
>> required to deploy TLS 1.2 even in scenarios where they know that all clients
>> support TLS 1.3, and don't want to pay the additional administration
>> overhead of safely deploying and maintaining TLS 1.2 ...
>>>
>>> However, I think that I've stated my opinion, and if you want to keep it as a
>> MUST, I will acquiesce and remove my blocking discuss on this point.
>>
>> Would the change suggested above address your concerns?
> 
> Not sure.  Although the placing of my comment above wasn't particularly clear, it was intended to be related to the "Implementations MUST support TLS 1.2" statement.
> 
> So, consider NETCONF, a network management protocols for configuring network devices and retrieving operational data, there is a new draft to allow NETCONF to run over TLS 1.3.  NETCONF effectively runs in a closed management domain where a single entity (the operator) has control over all NETCONF servers (i.e., network devices) and all management clients and controllers.  In this scenario, if all clients and devices support TLS 1.3 then I would think that it is easier/simpler for them to just deploy TLS 1.3, but that would seem to conflict with the "Implementations must support TLS 1.2" statement.
> 
> But it is possible that I'm misunderstanding this section/text. Perhaps the disagreement (or my confusion) is that I interpret "Implementations MUST support TLS 1.2" to mean that deployments MUST allow clients to use TLS 1.2 (e.g., if I setup an IMAP server, I have to allow TLS 1.2 clients), whereas the constraint is only mean to be on the software itself.  I.e., my IMAP server code must be capable of supporting TLS 1.2, but it can be deployed to only negotiate TLS 1.3?

Well, implementation != deployment and we've tried to be careful about 
that distinction in the document. Administrators who deploy live 
services using a software or hardware implementation are of course free 
to (and often encouraged to) do so in the most secure manner possible 
for feasible for them. Thus a service isn't forced to offer TLS 1.2 if 
they want to offer 1.3 only, but we're saying that the implementation 
needs to support both of these recommended versions.

>>>>>> (3)
>>>>>>                                                               When TLS-only
>>>>>>          communication is available for a certain protocol, it MUST be used
>>>>>>          by implementations and MUST be configured by
>>>> administrators.  When
>>>>>>          a protocol only supports dynamic upgrade, implementations MUST
>>>>>>          provide a strict local policy (a policy that forbids use of
>>>>>>          plaintext in the absence of a negotiated TLS channel) and
>>>>>>          administrators MUST use this policy.
>>>>>>
>>>>>> The MUSTs feel too strong here, since there are surely deployments
>> and
>>>>>> streams
>>>>>> of data where encryption, whilst beneficial, isn't an absolute
>>>>>> requirement?
>>>>>>
>>>>>> In addition "MUST be used by implementations and MUST be
>> configured
>>>> by
>>>>>> administrators" also seem to conflict, i.e., if the implementation
>>>>>> must use it
>>>>>> then why would an administrator have to enable it?
>>>>>
>>>>> I believe this is a duplicate of an issue that other folks have already
>>>>> raised:
>>>>>
>>>>> https://github.com/yaronf/I-D/issues/437
>>>>
>>>> At https://github.com/yaronf/I-D/pull/461 I'm proposing the following
>> text:
>>>>
>>>> ###
>>>>
>>>> When TLS-only communication is available for a certain protocol, it MUST
>>>> be supported by implementations and MUST be configured by
>> administrators
>>>> in preference to a dynamic upgrade method. When a protocol only
>> supports
>>>> dynamic upgrade, implementations MUST provide a way for
>> administrators
>>>> to set a strict local policy that forbids use of plaintext in the
>>>> absence of a negotiated TLS channel, and administrators MUST use this
>>>> policy.
>>>
>>> I appreciate that the context of this text is the upgrade case (which makes
>> sense), but I'm still able to read this text as casting a wider net than hopefully
>> intended.  I.e., I'm still concerned that someone could quote this text to say
>> that unencrypted comms is strictly not allowed anywhere, whenever a TLS
>> version of the protocol exists, and whilst I entirely agree that using TLS is
>> appropriate in the vast majority of places, I'm not convinced that is
>> everywhere.
>>
>> If people want to run unencrypted communications, that's their business,
>> but this document is about how best to use TLS once you've chosen to do
>> so, not about whether to use TLS in the first place.
> 
> Okay.
> 
> 
>>
>>> Hence, I wonder whether we could restructure the first sentence to ensure
>> that it's scope if focused purely on the upgrade scenario.  I.e., I suggest
>> something like the following for the first sentence:
>>>
>>> "When a protocol defines both a dynamic upgrade method and a separate
>> TLS-only channel, then the separate TLS-only channel MUST be supported by
>> implementations and MUST be configured by administrators to be used in
>> preference to the dynamic upgrade method."
>>
>> That's what we were trying to say, so your phrasing seems fine to me.
>> However, I feel that "channel" could be confusing and would prefer
>> "method" in both cases.
> 
> Sure.

Great. Updated text at https://github.com/yaronf/I-D/pull/461/files as 
follows:

###

* Many existing application protocols were designed before the use of 
TLS became common. These protocols typically support TLS in one of two 
ways: either via a separate port for TLS-only communication (e.g., port 
443 for HTTPS) or via a method for dynamically upgrading a channel from 
unencrypted to TLS-protected (e.g., STARTTLS, which is used in protocols 
such as IMAP and XMPP). Regardless of the mechanism for protecting the 
communication channel (TLS-only port or dynamic upgrade), what matters 
is the end state of the channel. When a protocol defines both a dynamic 
upgrade method and a separate TLS-only method, then the separate 
TLS-only method MUST be supported by implementations and MUST be 
configured by administrators to be used in preference to the dynamic 
upgrade method.  When a protocol supports only a dynamic upgrade, 
implementations MUST provide a way for administrators to set a strict 
local policy that forbids use of plaintext in the absence of a 
negotiated TLS channel, and administrators MUST use this policy.

###

Peter