A new Request for Comments is now available in online RFC libraries.
RFC 8879
Title: TLS Certificate Compression
Author: A. Ghedini,
V. Vasiliev
Status: Standards Track
Stream: IETF
Date:
> >I would suggest the strong, unambiguous statement with explanation
> for
> >why the statement is being made.
>
> Yes.
>
> >There is no need to describe (possible) exceptions.
>
> My opinion is exactly the opposite. Do describe the exceptions, as precisely
> and
On Tue, 1 Dec 2020 at 12:09, Ben Smyth wrote:
> I previously announced a TLS manual, intended to ease readers into the
> most recent specification...I'm far from perfect and I'm sure the
> manuscript houses numerous deficiencies.
>
Speaking of imperfections, I neglected to share a URL for a
>I would suggest the strong, unambiguous statement with explanation for
>why the statement is being made.
Yes.
>There is no need to describe (possible) exceptions.
My opinion is exactly the opposite. Do describe the exceptions, as precisely
and unambiguously as you
> It is incredibly difficult to draw a line so precisely as to where the threat
> to a
> device begins and ends, given the wide range of deployment scenarios. If a
> device can be at all critical (and even if it isn’t), then it should be
> upgraded or
> replaced. Better that this be out there
> On 1 Dec 2020, at 16:21, Salz, Rich wrote:
>
>> And how will the people who can ignore it know that it's OK for them to do
>> so?
>
> Well, frankly, that's not our problem. If someone is going to blindly insist
> on RFC conformance and doesn't recognize the wording that says "might not
>And how will the people who can ignore it know that it's OK for them to do
> so?
Well, frankly, that's not our problem. If someone is going to blindly insist
on RFC conformance and doesn't recognize the wording that says "might not apply
to you" ... well, so be it.
I am more concerned
It is incredibly difficult to draw a line so precisely as to where the threat
to a device begins and ends, given the wide range of deployment scenarios. If
a device can be at all critical (and even if it isn’t), then it should be
upgraded or replaced. Better that this be out there in its
Salz, Rich writes:
>The right thing to do, from a security viewpoint, is DO NOT USE TLS 1.0 OR
>TLS 1.1 If you have special circumstances, then do not follow the RFC (once
>published).
And how will the people who can ignore it know that it's OK for them to do so?
Once it's published, everyone
On 12/1/20, 4:29 AM, "Peter Gutmann" wrote:
Stephen Farrell writes:
>That said, if someone had words to suggest that might garner consensus,
that
>would be good.
I think all it needs is something along the lines of "This BCP applies to
TLS
as used on the public
The right thing to do, from a security viewpoint, is DO NOT USE TLS 1.0 OR TLS
1.1 If you have special circumstances, then do not follow the RFC (once
published).
If not following the RFC makes some people uncomfortable, that’s their bug. We
should not water down our recommendations.
I support the draft and will review.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 12/1/20 4:29 AM, Peter Gutmann wrote:
I think all it needs is something along the lines of "This BCP applies to TLS
as used on the public Internet [Not part of the text but meaning the area that
the IETF creates standards for].
Not specifically relevant to this draft, but: Is it actually
I previously announced a TLS manual, intended to ease readers into the most
recent specification. (At the very least, it helped me get to grips with
the spec!) I've now made the manual available on GitHub:
https://github.com/BenSmyth/tls-tutorial/
I'm far from perfect and I'm sure the
Stephen Farrell writes:
>That said, if someone had words to suggest that might garner consensus, that
>would be good.
I think all it needs is something along the lines of "This BCP applies to TLS
as used on the public Internet [Not part of the text but meaning the area that
the IETF creates
15 matches
Mail list logo
