On Wed, May 5, 2021, at 15:51, Achim Kraus wrote:
> For me, this requires, that cid is used in both directions. If not, the
> "elicits" doesn't work, or? If both parties are using CID in order to
> signal, that the addresses are changing, my feeling is, this scenario is
> not that common. (Even
Hi Martin,
> The attack here is fairly simple: an attacker gets a valid packet and
rewrites the source address (to an address it controls). If that packet
is accepted by the endpoint that receives it, then it will probe toward
the attacker. The attacker needs to rewrite the source address on th
Thanks Martin, Rob.
Funnily enough, my draft ballot position (even before your note) contains:
I'm extremely reluctant to suggest using SNI in this manner (as an
impromptu authorization bearer token, akin to port knocking).
Since you got your replies in while I was taking an interrupt fo
Hi,
Thanks for the update and the followup. To me the only remaining point I am
not sure has been fully addressed is the clarification of 5246, but
otherwise we agree on the content to be written. Please find my comments
inline.
Yours,
Daniel
On Tue, May 4, 2021 at 1:23 PM Sean Turner wrote:
>
I agree with Rob here. Removing the appendix would be best. It's true that
some servers have special names, but that is for operational reasons.
Pretending that something you put on the wire in the clear is a security
mechanism would be dishonest.
This reminds me of port knocking. It's not
What Russ said here is important. However, I don't see any reason that this
record should not be protected.
I also think that we can use a content type outside of the scarce range we have
for TLS record content types. This only makes sense for use with DTLS 1.3 and
DTLS 1.2 with connection ID
I can't claim credit for all of the jankiness in QUIC regarding on-path,
off-path, and friends.
The attack here is fairly simple: an attacker gets a valid packet and rewrites
the source address (to an address it controls). If that packet is accepted by
the endpoint that receives it, then it wi
On Tue, May 4, 2021 at 4:20 PM Benjamin Kaduk wrote:
> Hi all,
>
> I'm reviewing draft-ietf-dprive-xfr-over-tls for this week's IESG
> telechat, and
> in
> https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A.3
> it seems to suggest that a TLS server might only choos
Hi all,
I'm reviewing draft-ietf-dprive-xfr-over-tls for this week's IESG telechat, and
in
https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11#appendix-A.3
it seems to suggest that a TLS server might only choose to allow connections
that
include a specific (secret-ish) SNI va
This document seems fine to me, but the first paragraph of Section 3 needs some
work. This can be sorted out after adoption.
Section 3 begins with:
When a record with CID is received that has the source address of the
enclosing UDP datagram different from the one previously associated
I'm not a strong DTLS expert, but this seems like important work. We should
adopt it. I promise to read and review.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
Hopefully, I haven’t added too much time to the process but I stuck my beak in
to see if I could propose some text to move this along. Apologies in advance:
this is a long email. Once we settle on the text, I can submit PRs.
spt
> On Sep 14, 2020, at 11:11, Daniel Migault wrote:
>
> Hi Nick,
Daniel,
Thanks for your (and the WG’s) patience on this. Responses in line.
spt
> On Apr 9, 2021, at 14:54, Sean Turner wrote:
>> On Jan 22, 2021, at 08:23, Daniel Migault wrote:
>> On Fri, Jan 22, 2021 at 12:13 AM Loganaden Velvindron
>> wrote:
>> On Fri, Jan 22, 2021 at 7:30 AM Daniel Miga
Hannes,
What you might be missing is that Martin Thomson chose what to me is an
unintuitive definition of off-path attacker. On-path means that you a
router that you can drop a packet. An off-path attacker might be an
observer, which can see the packets, or not. I hope that clears things up a
litt
Hi Martin,
The attack described in Section 9.3.3 of
https://tools.ietf.org/html/draft-ietf-quic-transport-34#section-9.3.3 makes a
lot of assumptions about the attacker.
I am not opposed to adding the recommendation but I want to understand it first
since there is also a price to pay for it (i
I support adoption. It should be useful to deal with this issue at DTLS
level.
Le 03/05/2021 à 17:44, Sean Turner a écrit :
Hi!
We would like to re-run the WG adoption call for "Return Routability Check for
DTLS 1.2 and DTLS 1.3”. Please state whether you support adoption of this draft as a
Hello Sean,
Hello List,
FMPOV, that dtls-rrc work is very welcome!
All use-cases, where the northbound-layers don't provide solutions for
that, will benefit from it.
best regards
Achim Kraus
Am 03.05.21 um 17:44 schrieb Sean Turner:
Hi!
We would like to re-run the WG adoption call for "Return
17 matches
Mail list logo
