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 <stpe...@stpeter.im>
Sent: 18 July 2022 18:56
To: Rob Wilton (rwilton) <rwil...@cisco.com>; The IESG <i...@ietf.org>
Cc: draft-ietf-uta-rfc7525...@ietf.org; uta-cha...@ietf.org; uta@ietf.org;
le...@sunet.se
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...
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?
(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.
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.
Peter
_______________________________________________
Uta mailing list
Uta@ietf.org
https://www.ietf.org/mailman/listinfo/uta
