BTW: A MUST with an otherwise clause, is to me, a SHOULD.
It is not an otherwise clause. It is a MUST and you MAY also do this.
(Also, what's a non-default option. Either it can be negotiated, so it's
on by default, or it won't be negotiated, so it's really off.)
Don’t think protocol,
Is the second paragraph of Sec 4 not sufficient? It says “If deployment
considerations are a concern, the protocol MAY specify TLS 1.2 as an
additional, non-default option.”
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le.
Special thanks to Valery Smyslov for the shepherd's write-up including the WG
consensus ***but it lacks*** the justification of the intended status.
It updated 9325 which is a BCP, so this must also be BCP.
Other thanks to Scott Rose, the DNS directorate reviewer, please consider this
int-dir revi
Worth clarifying throughout that protocols *which use TLS* must use TLS 1.3 (or
later). This document isn't (I believe) attempting to mandate that all
protocols use TLS in all contexts.
I believe the editor’s copy already has made this change sufficiently.
Section 5, the "small changes" are small
* If *all* participants in an interaction MUST support TLS 1.3, then there is
no
reason to support anything else. Unless of course, you expect some
participants to violate that MUST, in which case, a document is being
dishonest.
You are not counting a non-updated deployed base (which su
But, MUST do TLS 1.3 implies (to me), do *NOT* (refuse to) do TLS 1.2.
The only way to allow (MAY) TLS 1.2, is for TLS 1.3 to be SHOULD.
People who believe that have not read the draft, or forgotten something. It’s
pretty clear, appearing in the very next paragraph aftrer the MUST TLS 1.3
p
The document tries to be careful about trying to move vendors to TLS 1.3, while
still recognizing that deployment issues may force the addition of TLS 1.2. If
a vendor is on TLS 1.0/1.1 this document doesn’t apply.
I am concerned that if we water this down more, just so some vendors can claim
c
TL;DR. All good ideas, changes incorporated. I am about to submit a -11 that
addresses feedback from:
Deb's, Med (again; my git mistake), Mike Bishop, Eric Vynke's, and Scott
Rose.
Section 6, para 3, sentence 1: All Finite Field DH? Or all except those using
ephemeral FFDH specified in R
Thanks for this quick work. I think the 'most' got lost in all the edits.
Otherwise, I think it looks great.
Of course, the one point that was the DISCUSS. Sigh. New one coming I guess.
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an emai
In this TLS1.3 "MUST" discussion, I don't understand what an:
"additional, non-default option"
It means that the configuration file or however the settings are managed, does
not turn in on by default.
* How does a client know if there were deployment considerations on the server?
In many case
I'm all for telling everyone to do TLS 1.3.
I do not think this document is helpful.
I think it might be actually harmful.
I cannot convince you otherwise, so I doubt I will respond more. I am sure your
view is in the rough.
smime.p7s
Description: S/MIME cryptographic signature
__
I'm told (by an AD) that uta-require-tls13 is supposed to apply to all ends of
a new protocol.
Shrug.
Anyway, it's much easier to make an RFC a performance specification (a trade
term about RFPs) when the document doesn't depend upon some parties just
ignoring the MUSTs.
It would be
> 1. How do I cite the CABFORUM WebPKI set of anchors.
> Does it have a clear name? (Because it's not identical on all
> platforms/browsers/libraries).
I am pretty sure that there isn't one. Instead, each trust store operator
(e.g., browser vendor) is supposed to interpret the CA/B guidelines an
> * "When the API allows it, clients SHOULD specify just the minimum version
they want."
> I struggled with this phrasing and attempting to reconcile it with the
> broader goal of requiring TLS1.3. What is really meant here, and could
> it be more clearly stated?
To answer the second question, ye
Thank you for the careful reading!
> NIT: Should the enumeration of the known deficiencies of TLS 1.2 be contained
> in the Introduction? The same considerations are described in Section 6, and
> their summation in the Introduction seems to be superfluous.
I'm happy to move item #1 from the intr
I’ve been following the thread (mainly Geoff and EKR), and I think I have it
narrowed down to the following.
* Now the assertion in the draft that: "Cryptographically-relevant quantum
computers, once available, will have a huge impact on TLS traffic." is true,
for what its worth, but its r
Thanks Rich - this would address my review comments
Thanks for the review and conversation thread. I’ll post a new version and
have the WG take a look.
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
This version removes the duplication in Section 1 (as it's in Section 6). It
also revises some of the wording in Section 3 to make clear it is not a
detailed threat analysis. These were done in response to Geoff's DNSDIR review.
The "diff url" is helpful. Please post if you disagree with the ch
I think there might have been a misunderstanding of my comment.
I’m not questioning whether the discussed topics are related to updating RFC
9325—I agree that they provide important rationale for the changes. My point is
that the abstract and introduction should clearly state that these topics (
Looks good to me!
Great, thanks for taking the time to review and explain what I didn’t get.
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
All fine.
Thanks! New draft coming.
___
Uta mailing list -- uta@ietf.org
To unsubscribe send an email to uta-le...@ietf.org
201 - 221 of 221 matches
Mail list logo
