On Wed, Nov 17, 2021, at 16:10, Ryan Sleevi wrote:
> I think I would disagree with this claim. Application-layer signals are
> one way to solve this problem, but they are not a necessary condition.
Sure. I was maybe imprecise in writing this up; this is a statement I agree
with. I'm more conce
On Tue, Nov 16, 2021 at 7:18 PM Martin Thomson wrote:
> I think that the text on presented identifiers needs work.
>
> There are a few different things at play here:
>
> The identities we use are not always as specific as the identity used in
> application protocols. On the web, we use origins,
I think that the text on presented identifiers needs work.
There are a few different things at play here:
The identities we use are not always as specific as the identity used in
application protocols. On the web, we use origins, which is scheme+host+port,
but the reference identity that we us
FWIW, I found nothing in that text to object to...
> On 16 Nov 2021, at 3:14 pm, Salz, Rich
> wrote:
>
> Ryan Sleevi has proposed adding the text below to the security considerations
> section. I’ve posted about this before and had miniscule feedback. Barring
> strong objections, I intend to
Obviously, s/CoAP/TLS BCP/ 😊
Apologies for the lapsus.
On 16/11/2021, 18:23, "Uta" wrote:
Hi all,
We have reviewed all the published RFCs that depend on 7252 [1] and have
reached the conclusion that the updates made in 7252-bis don’t break any
requirement stated in those documents.
Please ha
Ryan Sleevi has proposed adding the text below to the security considerations
section. I’ve posted about this before and had miniscule feedback. Barring
strong objections, I intend to merge this near the end of the week and publish
a new draft containing this and the name-change.
## Multiple P
In https://github.com/richsalz/draft-ietf-uta-rfc6125bis/pull/36
I suggest changing the title to: “On TLS Service Names”
I also added the following to the acknowledgement section. If I left you out,
please let me know.
+In addition to discussion on the mailing list, the following people
+contri
On Sun, Nov 14, 2021 at 08:27:25AM +, John Mattsson wrote:
> I promised to send some information to the list regarding security
> considerations for long connections. I think the (D)TLS 1.3 is lacking
> considerations on this as well so I made an issue for RFC8446bis.
>
> https://github.com/t
Hi all,
We have reviewed all the published RFCs that depend on 7252 [1] and have
reached the conclusion that the updates made in 7252-bis don’t break any
requirement stated in those documents.
Please have a look yourselves, and feel free to forward this to anyone you
think may be a stakeholder
* So, yes, I'd agree there's not much benefit to recommend that a
TLS-1.2-only implementation add supported_versions, or that an operator look
for such an implementation. Any implementation-gated effort is better spent
getting to TLS 1.3.
I agree that if you have supported_versions than y
Apologies, I maybe should have sent this earlier, but Rich Salz’s secdir
reminded me to forward this IETF LC due to the application-focused nature of
this I-D.
Cheers,
spt
> Begin forwarded message:
>
> From: The IESG
> Subject: Last Call: (Guidance
> for External PSK Usage in TLS) to Infor
11 matches
Mail list logo
