both* the
record heard *and* something else, like the CID. And it may very well
prevent an attack.
Chris P.
[1] https://eprint.iacr.org/2018/634.pdf
[2] https://eprint.iacr.org/2017/1191.pdf
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
#x27;t matter what the
contents of the header are or how long it is, so long as (a) the entire
header is part of the AAD and (b) it correctly encodes the length of the
next ciphertext.
I might be missing something, however. In any case, new definitions are
needed (if they don't alrea
d if, as you say, the
header's content is highly variable. So, I would recommend authenticating
what's on the wire. I don't think it would hurt to authenticate more than
this, e.g., other fields that the sender and receiver need to agree on.
Chris P.
>
> But I'd like to hear Chris weigh in on whether he thinks we should have
> them explicitly in the AD (and whether that should be true in QUIC too).
>
I would need to study the specs in order to provide an intelligent answer
here. Off the hip, it would seem to depend on h
is a branch in your code that depends on a bit
read from the wire, that bit should be authenticated if possible. To your
example, if a decision you're about to make depends on you agreeing with
the peer on the current epoch, the principle says that the epoch had better
be authenticated. Whether i
Greetings,
FYI - this report has been deleted as junk.
Thank you.
RFC Editor/cs
> On Mar 29, 2021, at 9:33 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC2818,
> "HTTP Over TLS".
>
> --
> You may review the report
Greetings,
FYI - this report has been deleted as junk.
Thank you.
RFC Editor/cs
> On Sep 8, 2021, at 5:02 AM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC2246,
> "The TLS Protocol Version 1.0".
>
> --
> You may
Greetings,
We are unable to verify this erratum that the submitter marked as editorial.
Please note that we have changed the “Type” of the following errata
report to “Technical”. As Stream Approver, please review and set the
Status and Type accordingly (see the definitions at
https://www.rf
Greetings,
FYI - this report has been deleted as junk.
Thank you.
RFC Editor/cs
> On Mar 29, 2022, at 3:39 PM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC7507,
> "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
> Downgrade
Greetings,
FYI - this report has been deleted as junk.
Thank you.
RFC Editor/cs
> On Apr 1, 2022, at 8:39 PM, RFC Errata System
> wrote:
>
> The following errata report has been submitted for RFC7507,
> "TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol
> Downgrade
Hi Paul,
We are unable to verify this erratum that the submitter marked as editorial.
Please note that we have changed the “Type” of the following errata report to
“Technical”. As Stream Approver, please review and set the Status and Type
accordingly (see the definitions at
https://www.rfc-ed
H Paul,
We are unable to verify this erratum that the submitter marked as editorial.
Please note that we have changed the “Type” of the following errata
report to “Technical”. As Stream Approver, please review and set the
Status and Type accordingly (see the definitions at
https://www.rfc-edi
I've reviewed the document and endorse its adoption.
It's not worth spending more time on TLS < 1.3, and the draft can help to
improve TLS 1.3 adoption.
It isn't worthwhile to invest additional time in TLS versions earlier than
1.3, and the draft can contribute to enhancing the adoption of TLS 1.
waste. More uses and
details are given in the document.
We would very much appreciate feedback on the mechanism utility and design.
Best,
Chris
Begin forwarded message:
> From: internet-dra...@ietf.org
> Date: April 12, 2018 at 8:07:35 PM PDT
> To: David Schinazi , Christopher Wood
; connections, and the QUIC extension for QUIC/UDP.
>
> Quickly reading the draft:
>
> struct {
> opaque address<32..255>;
> } NetworkAddress;
>
>
> Address is at least 32 octets? Even IPv6 addresses are only 16 octets
> (
I really want the savings on the wire that TLS flags extension provides – and
so I think it’s really good for the future cTLS but I’m not sure when I get to
use it in TLS 1.3 negotiation. It goes in the clientHello message, but how
will I know that the server uses this extension? I envision a
https://datatracker.ietf.org/doc/draft-lvelvindron-tls-md5-sha1-deprecate/
This email starts the call for adoption. It will run until August 7, 2019.
Please indicate whether or not you would like to see this draft adopted.
Best,
Chris, on behalf of the chairs
_
your services.
Note, we currently do not have 0-RTT data support.
Best,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
> On Jun 14, 2017, at 8:02 PM, Benjamin Kaduk wrote:
>
>> On 06/14/2017 01:00 PM, Chris Wood wrote:
>> Hi folks,
>>
>> Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in
>> our platforms. It is not turned on by default. If you’re a m
https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md
https://github.com/tlswg/tlswg-wiki/blob/master/TESTING.md
Or is everyone just spinning up private servers for now?
Thanks,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/ma
HTTPS RRs are managed, and consumed by clients.
Chris
On Tue, 27 Oct 2020 at 20:33, Stephen Farrell
wrote:
>
>
> On 27/10/2020 18:37, Chris Box (BT) wrote:
> > Hi,
> >
> > I would like to test an ECH-enabled client, but am struggling to find a
> > public te
21 matches
Mail list logo
