Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Achim Kraus]

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 the
packet it receives so that it elicits a genuine response from the peer.
Then the attacker captures the response and rewrites the source address.

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 more, it will have anyway troubles, with or
without CID.)

> With this, if the attacker can observe two dropped packets (or cause
them to be dropped somehow).  The first probably has to precede a quiet
period that is long enough to complete the process; the latter needs to
contain a probe response.  If those conditions can be met, then the
attack can place itself on-path.

"With this" and a "setup, where both peer's addresses will change
dynamically", 

In my experience, one peer uses a fixed ip-address, while the other one
uses a temporary/dynamic assigned one. Yes, the RFC supports that both
peers are using CID. FMPOV, that's more about that the CID principals
maybe used for both directions (with the risk you point), than that
there are real worlds use-cases on a "both sides dynamic".

> Without a probe on the original path, the attacker doesn't have to
provide a better route than the original.  Adding that probe means that
the attacker has to provide a faster and more consistent service, which
looks more like a net gain than an attack.

I see, that in cases, where both sides uses cid and dynamic addresse,
there maybe that manipulation. But, I can't see the attack. Maybe I
oversee something. If the "on path attacker" is installed and that
attacker changes the source of the traffic again in order to attack an
other victim peer, the probe will again protect the victim's new source
from being DDoS'ed.
So, please be more explizit, what the resulting attack would look like?

best regards
Achim Kraus


Am 05.05.21 um 04:45 schrieb Martin Thomson:

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 will probe toward the attacker.  The 
attacker needs to rewrite the source address on the packet it receives so that 
it elicits a genuine response from the peer.  Then the attacker captures the 
response and rewrites the source address.

With this, if the attacker can observe two dropped packets (or cause them to be 
dropped somehow).  The first probably has to precede a quiet period that is 
long enough to complete the process; the latter needs to contain a probe 
response.  If those conditions can be met, then the attack can place itself 
on-path.

Without a probe on the original path, the attacker doesn't have to provide a 
better route than the original.  Adding that probe means that the attacker has 
to provide a faster and more consistent service, which looks more like a net 
gain than an attack.

On Wed, May 5, 2021, at 01:49, Martin Duke wrote:

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 little bit -- although this is very hard to reason about.


Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that the 
attacker needs to be able to
* observe the packets sent by DTLS endpoints in both directions, and


I would argue it needs to only observe from the client (the one
allegedly changing address) to server.


* replay the packets in such a way that they arrive faster than the original 
packets send by the DTLS endpoints, and


This is the hardest part. The most plausible way is to purchase a
higher SLA from the service provider than the victim traffic.


* re-write both source and destination IP address to appear like a NAT for both 
endpoints.


No, it just needs to rewrite the source address of client->server packets.

Your second and third capabilities would actually defeat the "probe the
original address" countermeasure provided in the draft.

So yes, if the "attacker" is actually a router providing a superior
route to the host, there's nothing you can do.

But the required capabilities are the same for (1) pretending there is
a NAT rebinding where there isn't, and (2) pretending there isn't one
where there is. In both cases, one has to sit between NAT and server,
observe packets, rewrite source IPs, and beat the original 

Re: [TLS] SNI as authorization token?

[Benjamin Kaduk]

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 for something
else, I can relay the tentative suggestion to remove the whole appendix as well.

-Ben

On Wed, May 05, 2021 at 12:57:03PM +1000, Martin Thomson 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 an effective defense against a 
> motivated attacker, but people deploy it anyway.  If the IETF were to 
> recommend that, then it would have to come with stronger safeguards than 
> "maybe ECH will make this secure one day".
> 
> On Wed, May 5, 2021, at 09:30, Rob Sayre wrote:
> > 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-dprive-xfr-over-tls-11*appendix-A.3__;Iw!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2xk_4gN1g$
> > >  
> > > it seems to suggest that a TLS server might only choose to allow 
> > > connections that
> > > include a specific (secret-ish) SNI value.  Given that the "as above" 
> > > listed "con"
> > > seems to indicate that there are no relevant implementations of this 
> > > functionality,
> > > I plan to push back on its inclusion in the document; a PSK mode (with 
> > > cert,
> > > per RFC 8773) would seem to be universally superior.
> > > 
> > > Am I correct to do so?  Do we know of any cases where the SNI value is 
> > > being
> > > (ab)used as an authorization token in this manner?
> > 
> > It certainly happens with subdomains. I'd recommend removing that 
> > entire appendix, though. It seems like generic TLS / DoS advice that 
> > doesn't really belong in the document.
> > 
> > thanks,
> > Rob
> >  
> > ___
> > TLS mailing list
> > TLS@ietf.org 
> > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$
> >  
> > 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ay4HBe8M-L8oJtejnDhdK4oRwRyfeHdsZ7fbNfWtTZR-Jzifm-McY2wG6e-TtQ$
>  

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Daniel Migault]

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:

> 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 <
> logana...@gmail.com> wrote:
> >> On Fri, Jan 22, 2021 at 7:30 AM Daniel Migault 
> wrote:
> >> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner  wrote:
> >> >>
> >> >>
> >> >> Please note the comment about Section 3 suggests changing server
> behavior from SHOULD NOT to a MUST NOT.
> >> >>
> >> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker <
> nore...@ietf.org> wrote:
> >> >> >
> >> >> > Reviewer: Daniel Migault
> >> >> > Review result: Ready with Nits
> >> >> >
> >> >> > Hi,
> >> >> >
> >> >> >
> >> >> > I reviewed this document as part of the IoT Directorate's ongoing
> effort to
> >> >> > review all IETF documents being processed by the IESG.  These
> comments were
> >> >> > written primarily for the benefit of the Security Area Directors.
> Document
> >> >> > authors, document editors, and WG chairs should treat these
> comments just like
> >> >> > any other IETF Last Call comments.
> >> >> >
> >> >> > Review Results: Ready with Nits
> >> >> >
> >> >> > Please find my comments below.
> >> >> >
> >> >> > Yours,
> >> >> > Daniel
> >> >> >
> >> >> >
> >> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
> >> >> >  draft-ietf-tls-md5-sha1-deprecate-04
> >> >> > [...]
> >> >> >
> >> >> > 1.  Introduction
> >> >> >
> >> >> >   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
> >> >> >   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
> >> >> >   insecure, subject to collision attacks [Wang].  In 2011,
> [RFC6151]
> >> >> >   detailed the security considerations, including collision
> attacks for
> >> >> >   MD5.  NIST formally deprecated use of SHA-1 in 2011
> >> >> >   [NISTSP800-131A-R2] and disallowed its use for digital
> signatures at
> >> >> >   the end of 2013, based on both the Wang, et. al, attack and the
> >> >> >   potential for brute-force attack.  In 2016, researchers from
> INRIA
> >> >> >   identified a new class of transcript collision attacks on TLS
> (and
> >> >> >   other protocols) that rely on efficient collision-finding
> algorithms
> >> >> >   on the underlying hash constructions [Transcript-Collision].
> >> >> >   Further, in 2017, researchers from Google and CWI Amsterdam
> >> >> >   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
> >> >> >   This document updates [RFC5246] and [RFC7525] in such a way that
> MD5
> >> >> >   and SHA-1 MUST NOT be used for digital signatures.  However, this
> >> >> >   document does not deprecate SHA-1 in HMAC for record protection.
> >> >> >
> >> >> > 
> >> >> > RFC6194 may be mentioned as a reference for
> >> >> > not deprecating HMAC-SHA-1 as well as an
> >> >> > additional reference to [NISTSP800-131A-R2].
> >> >>
> >> >> Are asking for something like this:
> >> >>
> >> >> OLD:
> >> >>
> >> >>   In 2011, [RFC6151] detailed the security considerations,
> >> >>   including collision attacks for MD5.
> >> >>
> >> >> NEW:
> >> >>
> >> >>   In 2011, [RFC6151] [RFC6194] detailed the security considerations,
> >> >>   including collision attacks for MD5 and SHA-1, respectively.
> >> >>
> >> >> > Reading the text the situation of HMAC with
> >> >> > MD5 is unclear. Since we specify that SHA-1
> >> >> > is not deprecated for HMAC we may specify
> >> >> > the status for HMAC with MD5. Given RFC6151 I
> >> >> > hope the reason is that MD5 and HMAC-MD5 has
> >> >> > already been deprecated but I have not found
> >> >> > this. Maybe that would worth mentioning it
> >> >> > is deprecated already.
> >> >> >
> >> >> > 
> >> >>
> >> >> Are you asking for something like this:
> >> >>
> >> >> OLD:
> >> >>
> >> >>   However, this document does not deprecate SHA-1 in HMAC
> >> >>   for record protection.
> >> >>
> >> >>   However, this  document does not deprecate MD-5 or SHA-1 HMAC
> >> >>   for record protection.
> >> >
> >> > 
> >> > maybe we could add these are still considered as secured at the time
> of writing.  It is also tempting to add that given we deprecate sha1 and
> md5 in the signature, it is tempting to suggest to use unless necessary
> hmac-sha256.  I have commented the PR12
> >> > 
>
> 
>
> I think we address or will address this one in this to-be updated PR:
> https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/12/files
>
> In fact, I plan to submit updates to the PR for all of the changes so we
> can look at them in one place.
>
> 
>
> >> >> <
> >> >> > [...]
> >> >> >
> >> >> > 2.  Signature 

Re: [TLS] SNI as authorization token?

[Martin Thomson]

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 an effective defense against a 
motivated attacker, but people deploy it anyway.  If the IETF were to recommend 
that, then it would have to come with stronger safeguards than "maybe ECH will 
make this secure one day".

On Wed, May 5, 2021, at 09:30, Rob Sayre wrote:
> 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 choose to allow 
> > connections that
> > include a specific (secret-ish) SNI value.  Given that the "as above" 
> > listed "con"
> > seems to indicate that there are no relevant implementations of this 
> > functionality,
> > I plan to push back on its inclusion in the document; a PSK mode (with cert,
> > per RFC 8773) would seem to be universally superior.
> > 
> > Am I correct to do so?  Do we know of any cases where the SNI value is being
> > (ab)used as an authorization token in this manner?
> 
> It certainly happens with subdomains. I'd recommend removing that 
> entire appendix, though. It seems like generic TLS / DoS advice that 
> doesn't really belong in the document.
> 
> thanks,
> Rob
>  
> ___
> TLS mailing list
> TLS@ietf.org 
> https://www.ietf.org/mailman/listinfo/tls
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

[Martin Thomson]

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 IDs, so we can rely on the content type being 
encrypted.  That means multiplexing constraints don't apply (they probably 
wouldn't anyway as this makes no sense for use with ICE).

Finally, I think that the flexible size of the cookie is not necessary.  Pick a 
fixed size.  Unlike the handshake cookie, there is no reason for this to be 
stateless.  (I also wouldn't call it a cookie.)

The comments that Martin Duke currently has on the connection ID regarding path 
validation rules apply more fully here than they do on that draft.  Perhaps we 
could fix them here.

On Wed, May 5, 2021, at 04:12, Russ Housley wrote:
> 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
>with that CID, the receiver MUST NOT update its view of the peer's IP
>address and port number with the source specified in the UDP datagram
>before cryptographically validating the enclosed record(s) but
>instead perform a return routability check.
> 
> I agree that the return routability check should be performed before 
> updating the peer's IP address and port number, but I the part about 
> "before cryptographically validating the enclosed record" seems to open 
> up some opportunities for trouble.
> 
> Russ
> 
> 
> > On May 3, 2021, at 11:44 AM, Sean Turner  wrote:
> > 
> > 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 WG item by posting a message to the TLS list by 2359 UTC 24 
> > May 2021.  Please include any additional information that is helpful in 
> > understanding your position.
> > 
> > NOTES:
> > 
> > 1) We are re-running this WG adoption now that DTLS 1.3 [1] and Connection 
> > Identifiers for DTLS 1.2 [2] is done.
> > 2) Here is a link to the original WG adoption call [3].
> > 
> > Thanks,
> > Chris, Joe, and Sean
> > 
> > [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/
> > [2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
> > [3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/
> > ___
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Martin Thomson]

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 will probe toward the attacker.  The 
attacker needs to rewrite the source address on the packet it receives so that 
it elicits a genuine response from the peer.  Then the attacker captures the 
response and rewrites the source address.

With this, if the attacker can observe two dropped packets (or cause them to be 
dropped somehow).  The first probably has to precede a quiet period that is 
long enough to complete the process; the latter needs to contain a probe 
response.  If those conditions can be met, then the attack can place itself 
on-path.

Without a probe on the original path, the attacker doesn't have to provide a 
better route than the original.  Adding that probe means that the attacker has 
to provide a faster and more consistent service, which looks more like a net 
gain than an attack.

On Wed, May 5, 2021, at 01:49, Martin Duke wrote:
> 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 little bit -- although this is very hard to reason about.
> 
> >Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that 
> >the attacker needs to be able to
> >* observe the packets sent by DTLS endpoints in both directions, and
> 
> I would argue it needs to only observe from the client (the one 
> allegedly changing address) to server.
> 
> >* replay the packets in such a way that they arrive faster than the original 
> >packets send by the DTLS endpoints, and
> 
> This is the hardest part. The most plausible way is to purchase a 
> higher SLA from the service provider than the victim traffic.
> 
> >* re-write both source and destination IP address to appear like a NAT for 
> >both endpoints.
> 
> No, it just needs to rewrite the source address of client->server packets.
> 
> Your second and third capabilities would actually defeat the "probe the 
> original address" countermeasure provided in the draft.
> 
> So yes, if the "attacker" is actually a router providing a superior 
> route to the host, there's nothing you can do.
> 
> But the required capabilities are the same for (1) pretending there is 
> a NAT rebinding where there isn't, and (2) pretending there isn't one 
> where there is. In both cases, one has to sit between NAT and server, 
> observe packets, rewrite source IPs, and beat the original packet to 
> the server.
> 
> Martin
> 
> On Tue, May 4, 2021 at 6:30 AM Hannes Tschofenig 
>  wrote:
> > 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 (in terms of complexity and 
> > performance). Like elsewhere there is no free lunch.
> > 
> > Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that 
> > the attacker needs to be able to
> > * observe the packets sent by DTLS endpoints in both directions, and
> > * replay the packets in such a way that they arrive faster than the 
> > original packets send by the DTLS endpoints, and
> > * re-write both source and destination IP address to appear like a NAT for 
> > both endpoints.
> > 
> > The last point is needed to ensure that the packet re-routing persists.
> > 
> > IMHO these assumptions hint to an on-path attacker. An on-path attacker 
> > (such as a router) can already today perform a denial of service attack on 
> > DTLS secured communication by dropping all packets.
> > 
> > Ciao
> > Hannes
> > 
> > -Original Message-
> > From: Martin Duke via Datatracker 
> > Sent: Tuesday, April 20, 2021 9:47 PM
> > To: The IESG 
> > Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; 
> > tls@ietf.org; Joseph Salowey ; j...@salowey.net
> > Subject: Martin Duke's No Objection on 
> > draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
> > 
> > Martin Duke has entered the following ballot position for
> > draft-ietf-tls-dtls-connection-id-11: No Objection
> > 
> > When responding, please keep the subject line intact and reply to all email 
> > addresses included in the To and CC lines. (Feel free to cut this 
> > introductory paragraph, however.)
> > 
> > 
> > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about DISCUSS and COMMENT positions.
> > 
> > 
> > The document, along with other ballot positions, can be found here:
> > 

Re: [TLS] SNI as authorization token?

[Rob Sayre]

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 choose to allow
> connections that
> include a specific (secret-ish) SNI value.  Given that the "as above"
> listed "con"
> seems to indicate that there are no relevant implementations of this
> functionality,
> I plan to push back on its inclusion in the document; a PSK mode (with
> cert,
> per RFC 8773) would seem to be universally superior.
>
> Am I correct to do so?  Do we know of any cases where the SNI value is
> being
> (ab)used as an authorization token in this manner?
>

It certainly happens with subdomains. I'd recommend removing that entire
appendix, though. It seems like generic TLS / DoS advice that doesn't
really belong in the document.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] SNI as authorization token?

[Benjamin Kaduk]

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 value.  Given that the "as above" listed 
"con"
seems to indicate that there are no relevant implementations of this 
functionality,
I plan to push back on its inclusion in the document; a PSK mode (with cert,
per RFC 8773) would seem to be universally superior.

Am I correct to do so?  Do we know of any cases where the SNI value is being
(ab)used as an authorization token in this manner?

Thanks,

Ben

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

[Russ Housley]

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
   with that CID, the receiver MUST NOT update its view of the peer's IP
   address and port number with the source specified in the UDP datagram
   before cryptographically validating the enclosed record(s) but
   instead perform a return routability check.

I agree that the return routability check should be performed before updating 
the peer's IP address and port number, but I the part about "before 
cryptographically validating the enclosed record" seems to open up some 
opportunities for trouble.

Russ


> On May 3, 2021, at 11:44 AM, Sean Turner  wrote:
> 
> 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 WG item by posting a message to the TLS list by 2359 UTC 24 May 
> 2021.  Please include any additional information that is helpful in 
> understanding your position.
> 
> NOTES:
> 
> 1) We are re-running this WG adoption now that DTLS 1.3 [1] and Connection 
> Identifiers for DTLS 1.2 [2] is done.
> 2) Here is a link to the original WG adoption call [3].
> 
> Thanks,
> Chris, Joe, and Sean
> 
> [1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/
> [2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
> [3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

[Salz, Rich]

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

Re: [TLS] 2nd WGLC for Delegated Credentials for TLS

[Sean Turner]

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, 
> 
> Thanks for the response and I apologize for my delayed response. However I 
> still have two major concerns regarding the current proposed text:
> 
> Mentioning keyless as the only solution complementary to DC still seems to me 
> technically inaccurate. With KeylessSSL, the key server  receives a hash 
> based on randoms and ECDH parameters. The hash used in TLS 1.3 is different 
> than in TLS 1.2 - when hashes are involved in the signature scheme - so 
> Keyless would not work in this case - at least as far as I understand - and 
> significant changes are need to make it work in TLS 1.3.
> It seems to me technically more accurate to mention the effort performed on 
> TLS 1.3 with draft-mglt-lurk-tls13 that is working in a TLS 1.3 context. On 
> the other hand, not mentioning it seems to me misleading. I also think it is 
> misleading to not mention an effort that addresses the signing oracle 
> security vulnerabilities associated to keylessSSL, leading to the impression 
> that such attacks are inherent to the key server architecture - with a 
> dedicated section 7.6. I understand, though, that  draft-mglt-lurk-tls13 is 
> not a commercial product and still an ongoing effort. 
> So far - unless I am missing them - I have not seen any technical 
> justification for not mentioning that justify the single mention of 
> keylessSSL and temptative of (non technical) procedural explanations do not 
> seem valid ( see in line ).  

This is addressed later in the email.

> Another concern I have - at least my understanding of it - is that DC is 
> subject to downgrade attacks. Typically the TLS operator chooses the 
> signature used by the DC to authenticate the server and this signature scheme 
> can be weaker than the signature scheme provided by the CA. This prevents a 
> content owner to enforce a (strong) level of authentication and - in the 
> future - the use of deprecated/weak signature schemes. The threat model here 
> is on the content owner perspective to ensure its website is strongly 
> authenticated. The fact that the client can remove weak signature schemes 
> does not seem sufficient as nothing seems to force the client to only use 
> strong authentication with SignatureSchemeList potentially appearing in 
> clear. The threat model you seem to refer to is the client to choose a strong 
> authentication, but I think that is a bit different. 

This is addressed later in the email.

> Please see my additional comments inline.
> 
> Yours, 
> Daniel
> 
> 
> On Wed, Aug 19, 2020 at 10:31 PM Nick Sullivan 
>  wrote:
> Daniel,
> 
> Thank you for your thorough review. We've attempted to address these comments 
> in the latest version on Github and are preparing to submit a -10. Answers 
> inline below for these comments.
> 
> Hannes, thank you for your comment as well.
> 
> The changes are tracked here:
> https://github.com/tlswg/tls-subcerts/pull/80
> 
> On Mon, Jun 29, 2020 at 5:48 PM Daniel Migault 
>  wrote:
> Hi, 
> 
> The draft has a number of nits and errors. Among others: 
> 
> The related work section mentions KEYLESS and subcert being complementary 
> that is KEYLESS can perform the operations associated to the DC and/or those 
> associated to the cert key. I do not think that is correct. KEYLESS does not 
> support TLS 1.3 while DC only works with TLS 1.3. The LURK extension for TLS 
> 1.3 [draft-mglt-lurk-tls13] should be mentioned instead. As LURK was 
> mentioned during the adoption period and until version 05 that should not 
> cause any issues. 
> 
> Technologies only available for TLS 1.2 may be mentioned in the related work 
> section.  [draft-mglt-lurk-tls12] should be mentioned similarly to KEYLESS as 
> it addresses the security concerns of KEYLESS. 
> 
> There are other places where the extensions is mentioned together with TLS 
> 1.2 that needs to be updated.  
> 
> I also think that test vectors would be good as well as a link to a formal 
> verification publication (if available).
> 
> Please see all my comments inline, I hope they help.
> 
> Yours, 
> Daniel
> 
> 
> 
>  Delegated Credentials for TLS
>draft-ietf-tls-subcerts-09
> 
> [...]
> 
> 1.  Introduction
> 
>Typically, a TLS server uses a certificate provided by some entity
>other than the operator of the server (a "Certification Authority" or
>CA) [RFC8446] [RFC5280].  This organizational separation makes the
>TLS server operator dependent on the CA for some aspects of its
>operations, for example:
> 
>*  Whenever the server operator wants to deploy a new certificate, it
>   has to interact with the CA...
> 
>*  The server operator can only use 

Re: [TLS] Iotdir last call review of draft-ietf-tls-md5-sha1-deprecate-04

[Sean Turner]

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 Migault  wrote:
>> > On Tue, Oct 27, 2020 at 11:34 PM Sean Turner  wrote:
>> >>
>> >>
>> >> Please note the comment about Section 3 suggests changing server behavior 
>> >> from SHOULD NOT to a MUST NOT.
>> >>
>> >> > On Oct 27, 2020, at 10:19, Daniel Migault via Datatracker 
>> >> >  wrote:
>> >> >
>> >> > Reviewer: Daniel Migault
>> >> > Review result: Ready with Nits
>> >> >
>> >> > Hi,
>> >> >
>> >> >
>> >> > I reviewed this document as part of the IoT Directorate's ongoing 
>> >> > effort to
>> >> > review all IETF documents being processed by the IESG.  These comments 
>> >> > were
>> >> > written primarily for the benefit of the Security Area Directors.  
>> >> > Document
>> >> > authors, document editors, and WG chairs should treat these comments 
>> >> > just like
>> >> > any other IETF Last Call comments.
>> >> >
>> >> > Review Results: Ready with Nits
>> >> >
>> >> > Please find my comments below.
>> >> >
>> >> > Yours,
>> >> > Daniel
>> >> >
>> >> >
>> >> > Deprecating MD5 and SHA-1 signature hashes in TLS 1.2
>> >> >  draft-ietf-tls-md5-sha1-deprecate-04
>> >> > [...]
>> >> >
>> >> > 1.  Introduction
>> >> >
>> >> >   The usage of MD5 and SHA-1 for signature hashing in TLS 1.2 is
>> >> >   specified in [RFC5246].  MD5 and SHA-1 have been proven to be
>> >> >   insecure, subject to collision attacks [Wang].  In 2011, [RFC6151]
>> >> >   detailed the security considerations, including collision attacks for
>> >> >   MD5.  NIST formally deprecated use of SHA-1 in 2011
>> >> >   [NISTSP800-131A-R2] and disallowed its use for digital signatures at
>> >> >   the end of 2013, based on both the Wang, et. al, attack and the
>> >> >   potential for brute-force attack.  In 2016, researchers from INRIA
>> >> >   identified a new class of transcript collision attacks on TLS (and
>> >> >   other protocols) that rely on efficient collision-finding algorithms
>> >> >   on the underlying hash constructions [Transcript-Collision].
>> >> >   Further, in 2017, researchers from Google and CWI Amsterdam
>> >> >   [SHA-1-Collision] proved SHA-1 collision attacks were practical.
>> >> >   This document updates [RFC5246] and [RFC7525] in such a way that MD5
>> >> >   and SHA-1 MUST NOT be used for digital signatures.  However, this
>> >> >   document does not deprecate SHA-1 in HMAC for record protection.
>> >> >
>> >> > 
>> >> > RFC6194 may be mentioned as a reference for
>> >> > not deprecating HMAC-SHA-1 as well as an
>> >> > additional reference to [NISTSP800-131A-R2].
>> >>
>> >> Are asking for something like this:
>> >>
>> >> OLD:
>> >>
>> >>   In 2011, [RFC6151] detailed the security considerations,
>> >>   including collision attacks for MD5.
>> >>
>> >> NEW:
>> >>
>> >>   In 2011, [RFC6151] [RFC6194] detailed the security considerations,
>> >>   including collision attacks for MD5 and SHA-1, respectively.
>> >>
>> >> > Reading the text the situation of HMAC with
>> >> > MD5 is unclear. Since we specify that SHA-1
>> >> > is not deprecated for HMAC we may specify
>> >> > the status for HMAC with MD5. Given RFC6151 I
>> >> > hope the reason is that MD5 and HMAC-MD5 has
>> >> > already been deprecated but I have not found
>> >> > this. Maybe that would worth mentioning it
>> >> > is deprecated already.
>> >> >
>> >> > 
>> >>
>> >> Are you asking for something like this:
>> >>
>> >> OLD:
>> >>
>> >>   However, this document does not deprecate SHA-1 in HMAC
>> >>   for record protection.
>> >>
>> >>   However, this  document does not deprecate MD-5 or SHA-1 HMAC
>> >>   for record protection.
>> >
>> > 
>> > maybe we could add these are still considered as secured at the time of 
>> > writing.  It is also tempting to add that given we deprecate sha1 and md5 
>> > in the signature, it is tempting to suggest to use unless necessary 
>> > hmac-sha256.  I have commented the PR12
>> > 



I think we address or will address this one in this to-be updated PR:
https://github.com/tlswg/draft-ietf-tls-md5-sha1-deprecate/pull/12/files

In fact, I plan to submit updates to the PR for all of the changes so we can 
look at them in one place.



>> >> <
>> >> > [...]
>> >> >
>> >> > 2.  Signature Algorithms
>> >> >
>> >> >   Clients MUST NOT include MD5 and SHA-1 in the signature_algorithms
>> >> >   extension.  If a client does not send a signature_algorithms
>> >> >   extension, then the server MUST abort the handshake and send a
>> >> >   handshake_failure alert, except when digital signatures are not used
>> >> >   (for example, when using PSK ciphers).
>> >> >
>> >> > 
>> >> > It seems to me that the server behavior might
>> >> > be defined as well. In our case this could be
>> >> > something around the lines 

Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Martin Duke]

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
little bit -- although this is very hard to reason about.

>Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that
the attacker needs to be able to
>* observe the packets sent by DTLS endpoints in both directions, and

I would argue it needs to only observe from the client (the one allegedly
changing address) to server.

>* replay the packets in such a way that they arrive faster than the
original packets send by the DTLS endpoints, and

This is the hardest part. The most plausible way is to purchase a higher
SLA from the service provider than the victim traffic.

>* re-write both source and destination IP address to appear like a NAT for
both endpoints.

No, it just needs to rewrite the source address of client->server packets.

Your second and third capabilities would actually defeat the "probe the
original address" countermeasure provided in the draft.

So yes, if the "attacker" is actually a router providing a superior route
to the host, there's nothing you can do.

But the required capabilities are the same for (1) pretending there is a
NAT rebinding where there isn't, and (2) pretending there isn't one where
there is. In both cases, one has to sit between NAT and server, observe
packets, rewrite source IPs, and beat the original packet to the server.

Martin

On Tue, May 4, 2021 at 6:30 AM Hannes Tschofenig 
wrote:

> 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 (in terms of complexity and
> performance). Like elsewhere there is no free lunch.
>
> Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that
> the attacker needs to be able to
> * observe the packets sent by DTLS endpoints in both directions, and
> * replay the packets in such a way that they arrive faster than the
> original packets send by the DTLS endpoints, and
> * re-write both source and destination IP address to appear like a NAT for
> both endpoints.
>
> The last point is needed to ensure that the packet re-routing persists.
>
> IMHO these assumptions hint to an on-path attacker. An on-path attacker
> (such as a router) can already today perform a denial of service attack on
> DTLS secured communication by dropping all packets.
>
> Ciao
> Hannes
>
> -Original Message-
> From: Martin Duke via Datatracker 
> Sent: Tuesday, April 20, 2021 9:47 PM
> To: The IESG 
> Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org;
> tls@ietf.org; Joseph Salowey ; j...@salowey.net
> Subject: Martin Duke's No Objection on
> draft-ietf-tls-dtls-connection-id-11: (with COMMENT)
>
> Martin Duke has entered the following ballot position for
> draft-ietf-tls-dtls-connection-id-11: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
>
>
>
> --
> COMMENT:
> --
>
> Thanks for this document.
>
> Section 9.3.3 of quic-transport, which deals with basically the same
> security model, also requires the receiving endpoint to probe the original
> address, not just the new one, to address a somewhat more difficult attack.
> It would be good to at least RECOMMEND this behavior for DTLS applications,
> and/or (repeat/informatively reference) the logic there.
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium. Thank you.
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: (with COMMENT)

[Hannes Tschofenig]

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 (in terms of complexity and 
performance). Like elsewhere there is no free lunch.

Reading through Section 9.3.3 "Off-Path Packet Forwarding", I noticed that the 
attacker needs to be able to
* observe the packets sent by DTLS endpoints in both directions, and
* replay the packets in such a way that they arrive faster than the original 
packets send by the DTLS endpoints, and
* re-write both source and destination IP address to appear like a NAT for both 
endpoints.

The last point is needed to ensure that the packet re-routing persists.

IMHO these assumptions hint to an on-path attacker. An on-path attacker (such 
as a router) can already today perform a denial of service attack on DTLS 
secured communication by dropping all packets.

Ciao
Hannes

-Original Message-
From: Martin Duke via Datatracker 
Sent: Tuesday, April 20, 2021 9:47 PM
To: The IESG 
Cc: draft-ietf-tls-dtls-connection...@ietf.org; tls-cha...@ietf.org; 
tls@ietf.org; Joseph Salowey ; j...@salowey.net
Subject: Martin Duke's No Objection on draft-ietf-tls-dtls-connection-id-11: 
(with COMMENT)

Martin Duke has entered the following ballot position for
draft-ietf-tls-dtls-connection-id-11: No Objection

When responding, please keep the subject line intact and reply to all email 
addresses included in the To and CC lines. (Feel free to cut this introductory 
paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/



--
COMMENT:
--

Thanks for this document.

Section 9.3.3 of quic-transport, which deals with basically the same security 
model, also requires the receiving endpoint to probe the original address, not 
just the new one, to address a somewhat more difficult attack. It would be good 
to at least RECOMMEND this behavior for DTLS applications, and/or 
(repeat/informatively reference) the logic there.



IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

[Simon Bernard]

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 
WG item by posting a message to the TLS list by 2359 UTC 24 May 2021.  Please 
include any additional information that is helpful in understanding your position.

NOTES:

1) We are re-running this WG adoption now that DTLS 1.3 [1] and Connection 
Identifiers for DTLS 1.2 [2] is done.
2) Here is a link to the original WG adoption call [3].

Thanks,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/
[2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
[3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WG adoption call for draft-tschofenig-tls-dtls-rrc: redux

[Achim Kraus]

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 Routability Check for 
DTLS 1.2 and DTLS 1.3”. Please state whether you support adoption of this draft as a 
WG item by posting a message to the TLS list by 2359 UTC 24 May 2021.  Please 
include any additional information that is helpful in understanding your position.

NOTES:

1) We are re-running this WG adoption now that DTLS 1.3 [1] and Connection 
Identifiers for DTLS 1.2 [2] is done.
2) Here is a link to the original WG adoption call [3].

Thanks,
Chris, Joe, and Sean

[1] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls13/
[2] https://datatracker.ietf.org/doc/draft-ietf-tls-dtls-connection-id/
[3] https://mailarchive.ietf.org/arch/msg/tls/IJYqpTmSHsCkiMaUPt_AltvKbe8/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls