Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

On Wed, Jun 20, 2018 at 7:15 AM, Paul Wouters  wrote:

> On Tue, 19 Jun 2018, Eric Rescorla wrote:
>
> Yes, that's technically true, but the question is whether it's in fact
>> practical for people to do that.
>>
>
> I already responded before that yes I think it is practical.
>

Perhaps I have misunderstood you, but that's not what I have been getting
out of this conversation.


>In most deployment scenario's, the IKE client has an expectation that
>>it is connecting, using a split-network setup, to a specific
>>organisation or enterprise.  A recommended policy would be to only
>>accept INTERNAL_DNSSEC_TA directives from that organization's DNS
>>names.  However, this might not be possible in all deployment
>>scenarios, such as one where the IKE server is handing out a number
>>of domains that are not within one parent domain.
>>
>> Is that text wrong? If not, I suspect we're just quibbling about "common".
>>
>
> I can clarify the text if you tell me what is bothering you.


I thought I had made clear what was bothering me, so I suppose we must be
talking past each other. I read this text as saying that there are
important cases where in fact the client will not have any reasonable  way
of knowing which domains to accept from the server, which, it seems to me,
contradicts the claim above that it's practical. You obviously think i'm
wrong, so how should I be reading this text?

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

On Tue, Jun 19, 2018 at 9:38 PM, Paul Wouters  wrote:

> On Tue, 19 Jun 2018, Eric Rescorla wrote:
>
> I'm asking if a common scenario will be that users of enterprise
>> VPNs who implement this feature will end up in a situation where the
>> VPN can impose TAs for any domain.
>>
>
> I explained before that I think "for any domain" can be strictly limited
> on the client side, either by preconfiguration or by confirmation on the
> VPN client side.
>

Yes, that's technically true, but the question is whether it's in fact
practical for people to do that. I'm sorry to repeat myself, but once
again the document clearly states that this can happen:

   In most deployment scenario's, the IKE client has an expectation that
   it is connecting, using a split-network setup, to a specific
   organisation or enterprise.  A recommended policy would be to only
   accept INTERNAL_DNSSEC_TA directives from that organization's DNS
   names.  However, this might not be possible in all deployment
   scenarios, such as one where the IKE server is handing out a number
   of domains that are not within one parent domain.

Is that text wrong? If not, I suspect we're just quibbling about "common".

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

On Tue, Jun 19, 2018 at 4:01 PM, Nico Williams 
wrote:

> On Tue, Jun 19, 2018 at 03:51:55PM -0700, Eric Rescorla wrote:
> > On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams 
> wrote:
> > > On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote:
> > > > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams <
> n...@cryptonector.com> wrote:
> > > > > The I-D should say that clients MUST allow local configuration of
> what
> > > > > domains to accept trust anchors for, and SHOULD allow local policy
> to
> > > > > list . as a domain for which to accept trust anchors.
> > > >
> > > > The ID can say that, but as a practical matter, any enterprise that
> has
> > > > a reasonable number of internal domains is just going to tell people
> > > > to configure their client to accept any domain name.
> > >
> > > And what's the problem with that?
> > >
> > > If it's your own device you might balk, so get your employer to provide
> > > you with theirs.  Or just accept it as part of the employment deal.
> >
> > Again, right now I'm just trying to establish the facts of the matter.
> > Do you agree this is going to be a common scenario?
>
> I don't know what the antecedent of "this" in your question.  If you
> mean that BYODs will have to accept policies users don't want, well,
> that's pretty much true anyways (e.g., you have to accept proxy
> configurations that can and _will_ MITM you).
>

I'm asking if a common scenario will be that users of enterprise
VPNs who implement this feature will end up in a situation where the
VPN can impose TAs for any domain.

As a followup question, I claim that that's not presently true with
existing VPNs. In some cases, the VPN requires you to install
a new trust anchor in order to accept its cert, but that's not an
inherently necessary practice. Separately, an enterprise may
require you to accept an MITM cert, but these are conceptually
distinct. Do you disagree with that?


Are you objecting to the I-D altogether -- objecting to the feature it
> adds -- or asking what the I-D should say about your concern?
>

Again, right now I'm trying to establish the facts of the matter. I'd prefer
to do that prior to discussing what is good or bad.

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

On Tue, Jun 19, 2018 at 3:46 PM, Nico Williams 
wrote:

> On Tue, Jun 19, 2018 at 12:26:10PM -0700, Eric Rescorla wrote:
> > On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams 
> > wrote:
> > > The I-D should say that clients MUST allow local configuration of what
> > > domains to accept trust anchors for, and SHOULD allow local policy to
> > > list . as a domain for which to accept trust anchors.
> > >
> > > This local configuration should be per-SG.
> > >
> >
> > The ID can say that, but as a practical matter, any enterprise that has
> > a reasonable number of internal domains is just going to tell people
> > to configure their client to accept any domain name.
>
> And what's the problem with that?
>
> If it's your own device you might balk, so get your employer to provide
> you with theirs.  Or just accept it as part of the employment deal.
>

Again, right now I'm just trying to establish the facts of the matter. Do
you agree
this is going to be a common scenario?

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

On Tue, Jun 19, 2018 at 1:00 PM, Paul Wouters  wrote:

> On Tue, 19 Jun 2018, Eric Rescorla wrote:
>
> The ID can say that, but as a practical matter, any enterprise that has
>> a reasonable number of internal domains is just going to tell people
>> to configure their client to accept any domain name.
>>
>
> Which is the equivalent of an enterprise that requires you to accept the
> TLS middleware box and its additional webpki CAs. Except we made it more
> restrained to prevent abuse.
>

I'd prefer to establish the facts of the matter before we debate what
ought to happen.

My contention here is that as a practical matter, many clients will be
required
to accept any domain name that the VPN server asserts is internal. As far
as I can tell, this is what the document itself says:

   In most deployment scenario's, the IKE client has an expectation that
   it is connecting, using a split-network setup, to a specific
   organisation or enterprise.  A recommended policy would be to only
   accept INTERNAL_DNSSEC_TA directives from that organization's DNS
   names.  However, this might not be possible in all deployment
   scenarios, such as one where the IKE server is handing out a number
   of domains that are not within one parent domain.

What am I misunderstanding?


All that is needed is to be able to authenticate the VPN server itself.
>>
>
> This draft has nothing to do with authentication of the VPN server. That
> is all done in IKE, possibly with certificates, but nothing related to
> DNS whatsoever. This draft is about using a split-DNS setup where the
> VPN client can keep using its own validating DNSSEC capable recursive
> server, while allowing a cryptographic acception for mutually agreed
> enterprise domains while still supporting DNSSEC for those enterprise
> domains to protect against inside attackers.
>

Yes, I appreciate that point. I was responding to Nico's comment that
"Generally the client must already have a trust anchor for the
SG to begin with. " And it's not correct that in order to have a VPN
gateway, you need to give it a full TA.

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

On Tue, Jun 19, 2018 at 11:34 AM, Nico Williams 
wrote:

> On Tue, Jun 19, 2018 at 10:13:47AM -0700, Eric Rescorla wrote:
> > I don't think that going point-by-point is getting us very far, so I'm
> > going to try to restate what i think the situation is, from the top.
> >
> > 1. In the current design, many clients (those whose enterprises have any
> > significant number of domains) are just going to have to accept whatever
> > domains the VPN server claims should be treated as internal, and to
> accept
> > the trust anchors the VPN server claims
>
> The I-D should say that clients MUST allow local configuration of what
> domains to accept trust anchors for, and SHOULD allow local policy to
> list . as a domain for which to accept trust anchors.
>
> This local configuration should be per-SG.
>

The ID can say that, but as a practical matter, any enterprise that has
a reasonable number of internal domains is just going to tell people
to configure their client to accept any domain name.


> 2. Because the current design also allows those trust anchors to sign TLSA
> > records, any TLS client which accepts those TLSA records is subject to
> MITM
> > by the VPN server
>
> And SSHFP.  And anything else that might be security-relevent (all of
> DNS, really).
>

Well, different parts of DNS are differently security relevant. For
instance,
the IP-address mapping usually isn't that big a deal because the network
attacker can reroute you anyway.
This definitely merits a Security Considerations note even if this

]

> property were actually the point of this protocol.
>
> > 3. Even if enterprise doesn't intend to run a MITM proxy, this means that
> > any compromise of the VPN server automatically makes it an MITM proxy for
> > the Internet as a whole, because the person who compromises it can simply
> > reconfigure it to advertise any domain of its choice as internal, as well
> > as the corresponding keys and TLSA records.
>
> Sure, but it's not like clients will be choosing to connect to any VPN
> servers.  Generally the client must already have a trust anchor for the
> SG to begin with.


Why? That trust anchor doesn't need to allow the creation of arbitrary
WebPKI certs. All that is needed is to be able to authenticate the
VPN server itself.


Painting this as a security threat to the entire
> Internet is going a bit too far.
>

Why?

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

I don't think that going point-by-point is getting us very far, so I'm
going to try to restate what i think the situation is, from the top.

1. In the current design, many clients (those whose enterprises have any
significant number of domains) are just going to have to accept whatever
domains the VPN server claims should be treated as internal, and to accept
the trust anchors the VPN server claims
2. Because the current design also allows those trust anchors to sign TLSA
records, any TLS client which accepts those TLSA records is subject to MITM
by the VPN server
3. Even if enterprise doesn't intend to run a MITM proxy, this means that
any compromise of the VPN server automatically makes it an MITM proxy for
the Internet as a whole, because the person who compromises it can simply
reconfigure it to advertise any domain of its choice as internal, as well
as the corresponding keys and TLSA records.

What, if any, of the above do you disagree with?

-Ekr


On Tue, Jun 19, 2018 at 9:40 AM, Paul Wouters  wrote:

> On Tue, 19 Jun 2018, Eric Rescorla wrote:
>
>   Yes. You are the Enterprise customer. It's a feature.
>>
>> Not all enterprises who use VPNs want to run a MITM proxy.
>>
>
> So only specify INTERNAL_DNS_DOMAIN with "internal.example.com"
> and all TA's outside that domain would not be accepted by the client.
>
> The basic problem here is that the security properties of DNS are
>> radically different from those of the WebPKI (which is why we
>> routinely rely on HTTPS in cases where DNS is untrustworthy).
>> So, it's totally unexpected that allowing the VPN operator to
>> inject a new DNS trust anchor would allow them to attack HTTPS
>> connections. The problem with this design is that it ties those
>> properties together. This is a problem for the users but also for
>> the enterprise because it takes something which might have
>> been offline signed and makes it online.
>>
>
> Local policy gives clients the chance to only allow preconfigured
> domain(s) to be accepted for redirection over the VPN, with or
> without trust anchors. If the network operator is smart, they have
> only one internal-only zone in use. And the client accepting that
> trust anchor is not a problem. In the case of the network insisting
> you need to accept dozens of trust anchors, then yes the network
> administrator makes it hard or impossible for their users to engage
> in anything other then blind trust of their enterprise devices.
> (but to be fair, you are in that situation already when you take
>  that enterprise pre-installed laptop)
>
>   Client
>>   implementations can limit these domains, eg using VPN profiles
>>   that the user has to agree to. There is not much more we can do
>>   at the protocol leven, than say the two things we already say:
>>
>>   1) If not split-view, do not accept any DNS trust anchors
>>
>>   This prevents third party VPN providers from injecting rogue trust
>>   anchors. Note that in this case you already _are_ giving all your
>>   traffic including DNS to the VPN server. (but hey, we have DOH)
>>
>>   2) Don't accept trust anchors for anything not specifically
>>  split-redirected into the VPN infrastructure
>>
>>   So in my redhat case, I would either allow "redhat.com" or
>>   "internal.redhat.com" to be redirected through my VPN profile
>>   and not anything else. (well, actually some reverse zone parts too)
>>
>>
>> There are actually a number of oither things you could do:
>>
>> - Totally forbid the use of TLSA signed by non-default trust anchors
>>
>
> The IKE/IPsec protocol should not modify the DNS protocol. The fact
> that control of a certain (sub)domain is transfered via a private
> view reachable via IPsec is a feature, not a bug. That would also break
> the use of TLSA records in those private/internal views.
>
> Practically speaking, in my setup, the unbound daemon cannot tell the
> difference between trust anchors loaded via IKE/IPsec or via another
> method.
>
> - Make the use of TLSA signed by non-default trust anchors a separate
>> protocol option with those trust anchors defined separately.
>>
>
> That goes against the goal of the protocol. The goal _is_ to place a
> certain (internal only) domain fully under control of the network of
> the VPN server. Including all security features and trust anchors within
> that zone.
>
> I imagine there are other choices.
>>
>
> This protocol extension is explicitely to add or a move a subdomain in
> the public DNS view to a private DNS view, after the user has given
> permission for this. Any sugge

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

For reference, here is my original review.

Rich version of this review at:
https://mozphab-ietf.devsvcdev.mozaws.net/D3046


The security considerations seem to omit a fairly serious potential
attack. Consider the case in which the client supplies this payload
and the server provides resolvers and DNSSEC anchors for some domain
it does not actually control, such as www.example.com. It then
provides a bogus IP address (of its own) and a TLSA(2)  or TLSA(3)
record asserting its own key pair. In this case, if the client
supports DANE, then you have at least potentially circumvented the
PKI. This is far more serious than a bogus IP.  The most likely
defense against this is for the client to filter the domains for which
it accepts anchor overrides. However, even if you do that, this still
introduces a weakness: if you are using straight DNSSEC, then signing
can be offline, but because the TA is not signed by an offline key,
compromise of the VPN endpoint means that you can forge DNSSEC
records.




COMMENTS
>
>   2.  Background
>
>  Split DNS is a common configuration for enterprise VPN deployments,
>  in which only one or a few private DNS domains are accessible and
>  resolvable via an IPsec based VPN connection.

I see the "only" binding to one, but isn't also generally the case
that they are only accessible via the VPN connection.


>  o  Digest Type (0 or 1 octet) - DS algorithm value from the IANA
> Delegation Signer (DS) Resource Record (RR) Type Digest Algorithms
> Registry.
>
>  o  Digest Data (0 or more octets) - The DNSKEY digest as specified in
> [RFC4034] Section 5.1 in presentation format.

I'm having a little trouble reading this. Is the reason these would be
0 because you are using the empty format?


>  o  Digest Data (0 or more octets) - The DNSKEY digest as specified in
> [RFC4034] Section 5.1 in presentation format.
>
>   5.  Split DNS Usage Guidelines
>
>  If a CFG_REPLY payload contains no INTERNAL_DNS_DOMAIN attributes,

The rules in this section are kind of hard to follow. I'm not sure
what the best way to restructure them are, but perhaps:  (1) If the
domain list is empty, you can use the internal servers for anything
(2) If the list is non-empty, you MUST use the internal servers for
any entries not prohibited by local policy, including total limits ,
and should accept 1918 addresses fore those domains and SHOULD NOT use
the internal servers for anything else.-


>  servers.
>
>  If the initiator host is configured to block DNS answers containing
>  IP addresses from special IP address ranges such as those of
>  [RFC1918], the initiator SHOULD allow the DNS domains listed in the
>  INTERNAL_DNS_DOMAIN attributes to contain those Special IP addresses.

I would rewrite this with the SHOULD first,, i..e, "SHOULD allow, even
if" because you want this SHOULD to apply even if you aren't
configured this way.


>  no guarantee of being answered.  For example, if the
>  INTERNAL_DNS_DOMAIN attribute specifies "example.com", then
>  "example.com", "www.example.com" and "mail.eng.example.com" MUST be
>  resolved using the internal DNS resolver(s), but "anotherexample.com"
>  and "ample.com" SHOULD NOT be resolved using the internal resolver
>  and SHOULD use the system's external DNS resolver(s).

This paragraph seems to to some extent duplicate the paragraph
starting with "For each INTERNAL_DNS_DOMAIN..."


On Tue, Jun 19, 2018 at 8:44 AM, Eric Rescorla  wrote:

>
>
> On Tue, Jun 19, 2018 at 8:26 AM, Paul Wouters  wrote:
>
>> On Mon, 18 Jun 2018, Eric Rescorla wrote:
>>
>> Right but the problem is that accepting the TA for a given domain allows
>>> the IPsec endpoint to act as a TLS endpoint for that domain
>>> (assuming that the TLS client supports DANE).
>>>
>>
>> Yes. You are the Enterprise customer. It's a feature.
>
>
> Not all enterprises who use VPNs want to run a MITM proxy.
>
> The basic problem here is that the security properties of DNS are
> radically different from those of the WebPKI (which is why we
> routinely rely on HTTPS in cases where DNS is untrustworthy).
> So, it's totally unexpected that allowing the VPN operator to
> inject a new DNS trust anchor would allow them to attack HTTPS
> connections. The problem with this design is that it ties those
> properties together. This is a problem for the users but also for
> the enterprise because it takes something which might have
> been offline signed and makes it online.
>
>
> Client
>> implementations can limit these domains, eg using VPN profiles
>> that the user has to agree to. There is not much more we can do
>

Re: [IPsec] draft-pauly-ipsecme-split-dns

[Eric Rescorla]

On Tue, Jun 19, 2018 at 8:26 AM, Paul Wouters  wrote:

> On Mon, 18 Jun 2018, Eric Rescorla wrote:
>
> Right but the problem is that accepting the TA for a given domain allows
>> the IPsec endpoint to act as a TLS endpoint for that domain
>> (assuming that the TLS client supports DANE).
>>
>
> Yes. You are the Enterprise customer. It's a feature.


Not all enterprises who use VPNs want to run a MITM proxy.

The basic problem here is that the security properties of DNS are
radically different from those of the WebPKI (which is why we
routinely rely on HTTPS in cases where DNS is untrustworthy).
So, it's totally unexpected that allowing the VPN operator to
inject a new DNS trust anchor would allow them to attack HTTPS
connections. The problem with this design is that it ties those
properties together. This is a problem for the users but also for
the enterprise because it takes something which might have
been offline signed and makes it online.


Client
> implementations can limit these domains, eg using VPN profiles
> that the user has to agree to. There is not much more we can do
> at the protocol leven, than say the two things we already say:
>



> 1) If not split-view, do not accept any DNS trust anchors
>
> This prevents third party VPN providers from injecting rogue trust
> anchors. Note that in this case you already _are_ giving all your
> traffic including DNS to the VPN server. (but hey, we have DOH)
>
> 2) Don't accept trust anchors for anything not specifically
>split-redirected into the VPN infrastructure
>
> So in my redhat case, I would either allow "redhat.com" or
> "internal.redhat.com" to be redirected through my VPN profile
> and not anything else. (well, actually some reverse zone parts too)
>

There are actually a number of oither things you could do:

- Totally forbid the use of TLSA signed by non-default trust anchors
- Make the use of TLSA signed by non-default trust anchors a separate
protocol option with those trust anchors defined separately.

I imagine there are other choices.



> Yes, but it's not clear to me that clients can adequately determine which
>> domains
>> are internal -- they just get that information with some VPN config they
>> got
>> from their VPN provider. The text in the document says as much:
>>
>
> Yes. And that is the same DNS problem in general when connecting to a
> network and running your own recursive server. You usually get only one
> domain via DHCP, but universities tend to have dozens, and they demand
> you give them all your DNS queries so they can screw with internal only
> domains for you on the fly. You just have to drop DNSSEC to let them do
> that. That is a situation that needs fixing, and at least if you connec
> to those networks using a VPN, this document is that fix. It allows the
> network to send more than one DNS domain, and let's the client decide
> whether or not to accept it. Where yes, most clients will do this based
> on trusting their administrator of the VPN they are connecting to. Others
> could have VPN software that lets them (de)select the ones they would
> not accept.
>

Trust isn't a monolithic thing. It's one thing to trust the administrator
to route
your packets and quite another to trust them to MITM TLS. Again, this is
why it's mostly safe to use HTTPS on networks owned by other people.


Note that without this document, the only way for VPN clients to get
> functional DNS beyond the 1 hardcoded domain, is to give the VPN all
> your DNS queries, which allows even more manipulation (especially with
> an installed Enterprise CA cert, now they can override gmail.com)
>

I'm not saying this document is bad. I'm saying it should exclude TLSA.


> So it seems to me that the likely consequence of this function is that a
>> lot of
>> clients will be accepting what amounts to MITM certificates (again,
>> assuming
>> that they support DANE) as part of their VPN config.
>>
>
> Not doing this makes the situation even worse. Do you have a proposal
> that would make it better? I cannot think of one.
>

Why does it make the situation worse? Again, what's the use case why
it's needed to have the VPN install a new WebPKI trust anchor.


>
> Also, part of your concerns could be mitigated by CT as well for the
> TLS cases. I assume if browsers require CT, that internal-only domains
> also need to get some kind of CT logging (redacted or not) and that
> would also prevent a rogue gmail.com TLSA from being accidentally
> accepted by the user at the IKE/VPN first as 'internal domain' and
> then additionally at the TLS/TLSA layer?
>

Well, the semantics of CT+DANE are totally undefined, but generally,
no, I wouldn't expect things that were TLSA-authorized to be CTed.

[IPsec] AD Review of Document: draft-ietf-ipsecme-eddsa

[Eric Rescorla]

Document: draft-ietf-ipsecme-eddsa-00.txt

   In order to signal within IKE that no hashing needs to be done, we
   define a new value has in the SIGNATURE_HASH_ALGORITHMS notification,
   one that indicates that no hashing is performed.

s/has//


   The pre-hashed versions of Ed25519 and Ed448 (Ed25519ph and Ed448ph
   respectively) SHOULD NOT be used in IKE.


I wonder if this should be a MUST NOT, for two reasons:

1. Allowing the pre-hashed versions allows attacks based on collisions in
the hash function.
2. It means that receivers cannot safely reject pre-hashed versions without
interop problems.

It's also not clear to me how this would even work. They would just use the
OID values from some future document?

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

[Eric Rescorla]

I agree with Russ.

On Mon, Jun 19, 2017 at 8:35 AM, Russ Housley <hous...@vigilsec.com> wrote:

>
> > On Jun 19, 2017, at 11:26 AM, Paul Wouters <p...@nohats.ca> wrote:
> >
> > On Mon, 19 Jun 2017, Eric Rescorla wrote:
> >
> >>  If manual keying is used anyway, AEAD algorithms MUST NOT be used,
> >>  as these algorithms require additional input provided by IKE and
> >>  are compromised if a counter is accidentally re-used, such as when
> >>  a counter overflows, or when a device reboots without remembering
> >>  the previously used counters. As of publication of this document,
> >>  ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encryption
> >>  algorithm suitable for Manual Keying.
> >> It's not AEAD that's the problem here. After all, it's perfectly
> possible to do AEAD
> >> with CBC-HMAC. Rather, it's CTR mode.
> >
> >
> > Hmm, of course we only have CTR based AEAD's :P
> >
> > Ok, NEW NEW last paragraph:
> >
> >   If manual keying is used regardless, Counter Mode AEAD algorithms
> >   MUST NOT be used, as these algorithms require additional input
> >   provided by IKE and are compromised if a counter is accidentally
> >   re-used, such as when a counter overflows, or when a device reboots
> >   without remembering the previously used counters. As of publication
> >   of this document, ENCR_AES_CBC is the only Mandatory-To-Implement
> >   encryption algorithm suitable for Manual Keying.
>
> The Security Considerations in RFC 3686 point out the problems with using
> AES-CTR with static keys, which is what I think you mean by manual in this
> paragraph.  I think you need to delete “AEAD” from the first sentence or
> explain that CCM and GCM encompass counter mode.
>
> Russ
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Ben Campbell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

[Eric Rescorla]

On Mon, Jun 19, 2017 at 7:45 AM, Paul Wouters  wrote:

> On Thu, 23 Mar 2017, Tero Kivinen wrote:
>
> Paul Wouters writes:
>>
>>> -3: I wonder why "... is not to be used..." is not "... MUST NOT be
 used...". But the section goes on to say if you do it anyway, you MUST
 NOT use certain cryptosuites. So, does "... is not to be used..." mean
 "SHOULD NOT"? Or is this one of those "MUST NOT BUT WE KNOW YOU WILL"
 sort of requirements?

>>>
>>> It is indeed. I think a SHOULD NOT would actually be appropriate ?
>>>
>>
>> We do not want to make the implementation of the manual keying MUST
>> NOT, as it is still useful in testing and similar situations, but we
>> do not want anybody using it in any real world use cases. As this
>> document is mostly about the implementation and tries to stay out from
>> the issues about what should be used (as explained in the 2nd
>> paragraph of the section 1.3).
>>
>> On the other hand section 1.3 is really about the use of the manual
>> keying, not about the implementation of manual keying, so that
>> confuses things (we do have some other cases were we say things DES
>> MUST NOT be used).
>>
>> I think the text needs to be clarified about this bit more, especially
>> we do not want to say that ENCR_AES_CBC MUST be used, as there are
>> other algorithms which can also be used (MUST be used would indicate
>> no other algorithm is possible).
>>
>
> Here is a suggestion:
>
> OLD text:
>
> 3.  Manual Keying
>
>Manual Keying is not to be used as it is inherently dangerous.
>Without any keying protocol, it does not offer Perfect Forward
>Secrecy ("PFS") protection.  Deployments tend to never be
>reconfigured with fresh session keys.  It also fails to scale and
>keeping SPI's unique amongst many servers is impractical.  This
>document was written for deploying ESP/AH using IKE ([RFC7296]) and
>assumes that keying happens using IKEv2.
>
>If manual keying is used anyway, ENCR_AES_CBC MUST be used, and
>ENCR_AES_CCM, ENCR_AES_GCM and ENCR_CHACHA20_POLY1305 MUST NOT be
>used as these algorithms require IKE.
>
> NEW text:
>
> 3.  Manual Keying
>
> Manual Keying SHOULD NOT be used as it is inherently dangerous.
> Without any keying protocol, it does not offer Perfect Forward
> Secrecy ("PFS") protection. Without IKE, another entity needs to
> ensure refreshing of session keys, tracking SPI uniqueness and
> ensuring nonces or IVs are not used more then once. This document
> was written for deploying ESP/AH using IKE ([RFC7296]) and assumes
> that keying happens using IKE version 2 or higher.
>
> If manual keying is used anyway, AEAD algorithms MUST NOT be used,
> as these algorithms require additional input provided by IKE and
> are compromised if a counter is accidentally re-used, such as when
> a counter overflows, or when a device reboots without remembering
> the previously used counters. As of publication of this document,
> ENCR_AES_CBC is the only non-AEAD Mandatory-To-Implement encryption
> algorithm suitable for Manual Keying.


It's not AEAD that's the problem here. After all, it's perfectly possible
to do AEAD
with CBC-HMAC. Rather, it's CTR mode.

-Ekr


>
>
> - Table in section 6:
 I'm boggled by the first entry being labeled "MUST/MUST NOT". I don't
 see
 anything in the text to explain the "MUST" part--did I miss something?

>>>
>>>
>>> First paragraph under the table:
>>>
>>> AUTH_NONE has been downgraded from MAY in RFC7321 to MUST NOT.  The
>>> only reason NULL is acceptable is when authenticated encryption
>>> algorithms are selected from Section 5.  In all other cases, NULL
>>> MUST NOT be selected.
>>>
>>
>> It does not make it easier that there is typo in that paragraph, and
>> it talks about NULL, when it should be talking about AUTH_NONE...
>>
>
> Queued up (NULL -> AUTH_NONE)
>
> Paul
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Mirja Kuehlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

It seems like most of the issues are resolved here, except for that of
muxing
IKE and non-IKE protocols on the same port (especially 443). My
understanding
is that (although we may not like it) it's nevertheless a common practice,
and
yet we can't levy the requirement that no other protocol start with
IKETCP,
so it seems like what we need is a warning note and potentially a request
to reserve
this string for some set of common protocols (HTTP,...?).

Mirja, would that work for you?

-Ekr


On Wed, May 3, 2017 at 6:11 AM, Spencer Dawkins at IETF <
spencerdawkins.i...@gmail.com> wrote:

>
>
> On May 3, 2017 05:54, "Mirja Kühlewind"  wrote:
>
> I didn't propose to obsolete RFC3947 in this document. I guess you can
> also file an error for this if you don't want to take any further actions.
> However, for updating the IANA registry, I would say the right action is to
> do this simply by IESG approval for UDP then.
>
>
> Fwiw, that would work for me.
>
> Spencer
>
>
>
> Mirja
>
>
>
> On 03.05.2017 11:12, Tero Kivinen wrote:
>
>> Mirja Kuehlewind (IETF) writes:
>>
>>> my thinking was that the main problem is that 3947 was not obsoleted
>>> and I’m assuming we need a document to fix that.
>>>
>>
>> This is partly issue, but it is not issue we need to solve here, as
>> this document is not something that should obsolete 3947.
>>
>> Also 3947 only defines extension for the IKEv1 (RFC2409) and that is
>> already obsoleted, so effectively RFC3947 is already obsoleted, as
>> there is no way to implement 3947 without implementing obsoleted
>> protocol...
>>
>> This issue is not not important enough to require RFC now.
>>
>> In this case that document could/should also fix the IANA entry for
>>> the UDP port. However, I’m actually not sure what the right
>>> processing would be to fix this forgotten obsolete… maybe other ADs
>>> know better…?
>>>
>>
>> For now I would just leave it as it is, but fix the references in the
>> IANA registry so that document will not be referenced, especially as
>> the original IANA reference was not to the correct RFC in the first
>> place.
>>
>> Otherwise if you don’t want to do this, I don’t think it’s a good
>>> idea to merge kind of unrelated fixes into this spec. We can also
>>> fix that by using the IESG approval process (see RFC5226). I think
>>> that’s the better option!
>>>
>>
>> That is true, but as this document already modifies the TCP/4500
>> reference, fixing the UDP/4500 reference at the same time is not
>> completely unrelated fix.
>>
>> Obsoleting RFC3947 would be unrelated fix.
>>
>>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

On Thu, Apr 27, 2017 at 7:21 AM, Mirja Kühlewind <i...@kuehlewind.net>
wrote:

> See below.
>
> On 27.04.2017 16:10, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind <i...@kuehlewind.net
>> <mailto:i...@kuehlewind.net>> wrote:
>>
>> Hi Ekr, hi all,
>>
>> (not sure anymore which email best to reply to but I'm using this one
>> now
>> to partly also reply to others).
>>
>> See below.
>>
>> On 27.04.2017 14 <tel:27.04.2017%2014>:51, Eric Rescorla wrote:
>>
>>
>>
>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <
>> i...@kuehlewind.net
>> <mailto:i...@kuehlewind.net>
>> <mailto:i...@kuehlewind.net <mailto:i...@kuehlewind.net>>> wrote:
>>
>> I do see the problem you have and I understand why you
>> selected the
>> solution you have but that does contradict quite a bit the
>> idea
>> of the
>> port registry and I don't think it's a safe and future prove
>> solution.
>> Even if people use this approach, I'm concern to publish it
>> in an
>> Standards Track RFC, but I guess that's a discussion the IESG
>> would need
>> to have.
>>
>>
>> Mirja,
>>
>> I agree that this kind of port squatting is regrettable, but I
>> also don't
>> think it really
>> helps to not publish RFCs that document widely used protocols
>> because we
>> are sad they port-squatted.
>>
>> I proposed a way to deal with this in an earlier e-mail. Would
>> that be
>> satisfactory
>> to you. To retransmit, we add the following
>>
>> "Note: While port 4500 is the reserved port for this protocol,
>> some
>> existing
>> implementations
>> also use port 443. The Stream Prefix provides some mitigation
>> against
>> cross-protocol
>> attacks in this case, however, the use of port 443 is NOT
>> RECOMMENDED"
>>
>> We could do something similar for port 80.
>>
>> Would that work?
>>
>>
>> This already is good but I think it's not enough. As Tero noted the
>> working group thought that they rather specify a generic scheme which
>> I
>> find problematic. Currently the drafts says:
>>
>> "This document leaves the selection of TCP ports up to
>>implementations.  It is suggested to use TCP port 4500, which is
>>allocated for IPsec NAT Traversal."
>>
>> Which sounds to me like an invitation to squat on any open port
>> regardless what the port is supposed to be used for (hoping that the
>> magic number would avoid any collision). I don't think that a good
>> thing
>> to right in an RFC.
>>
>>
>> Hmm... Maybe I don't understand your overall theory here. It seems like
>> having
>> reserved ports for protocols but letting people run them on any port they
>> want
>> to is kind of common practice. See, for instance:
>> https://tools.ietf.org/html/rfc7230#section-2.7.1
>>
>> "  If the host identifier is provided as an IP address, the origin
>>server is the listener (if any) on the indicated TCP port at that IP
>>address. If host is a registered name, the registered name is an
>>indirect identifier for use with a name resolution service, such as
>>DNS, to find an address for that origin server. If the port
>>subcomponent is empty or not given, TCP port 80 (the reserved port
>>for WWW services) is the default."
>>
>
> This doesn't say you can/should use any port you want (it says you can use
> another port than 80) but you should till avoid to use any other port that
> runs a different TCP service.
>

Well, that may be part of your background assumptions, but the document
doesn't say that. It just tells you how to use a different port and is
silent on
what port you should use.

-Ekr


> Mirja
>
>
>
>> -Ekr
>>
>>
>>
>> Now given the text you propose above, I actually assume that the text
>> I
>> just cited will be removed but the whole document is written with this
>> assumption and therefore there are a couple more places where wording
>> probably needs to change.
>>
>> I do understand well the problem and that 443 is used in practic

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

On Thu, Apr 27, 2017 at 6:42 AM, Mirja Kühlewind <i...@kuehlewind.net>
wrote:

> Hi Ekr, hi all,
>
> (not sure anymore which email best to reply to but I'm using this one now
> to partly also reply to others).
>
> See below.
>
> On 27.04.2017 14:51, Eric Rescorla wrote:
>
>>
>>
>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <i...@kuehlewind.net
>> <mailto:i...@kuehlewind.net>> wrote:
>>
>> I do see the problem you have and I understand why you selected the
>> solution you have but that does contradict quite a bit the idea of the
>> port registry and I don't think it's a safe and future prove solution.
>> Even if people use this approach, I'm concern to publish it in an
>> Standards Track RFC, but I guess that's a discussion the IESG would
>> need
>> to have.
>>
>>
>> Mirja,
>>
>> I agree that this kind of port squatting is regrettable, but I also don't
>> think it really
>> helps to not publish RFCs that document widely used protocols because we
>> are sad they port-squatted.
>>
>> I proposed a way to deal with this in an earlier e-mail. Would that be
>> satisfactory
>> to you. To retransmit, we add the following
>>
>> "Note: While port 4500 is the reserved port for this protocol, some
>> existing
>> implementations
>> also use port 443. The Stream Prefix provides some mitigation against
>> cross-protocol
>> attacks in this case, however, the use of port 443 is NOT RECOMMENDED"
>>
>> We could do something similar for port 80.
>>
>> Would that work?
>>
>
> This already is good but I think it's not enough. As Tero noted the
> working group thought that they rather specify a generic scheme which I
> find problematic. Currently the drafts says:
>
> "This document leaves the selection of TCP ports up to
>implementations.  It is suggested to use TCP port 4500, which is
>allocated for IPsec NAT Traversal."
>
> Which sounds to me like an invitation to squat on any open port regardless
> what the port is supposed to be used for (hoping that the magic number
> would avoid any collision). I don't think that a good thing to right in an
> RFC.
>

Hmm... Maybe I don't understand your overall theory here. It seems like
having
reserved ports for protocols but letting people run them on any port they
want
to is kind of common practice. See, for instance:
https://tools.ietf.org/html/rfc7230#section-2.7.1

"  If the host identifier is provided as an IP address, the origin
   server is the listener (if any) on the indicated TCP port at that IP
   address. If host is a registered name, the registered name is an
   indirect identifier for use with a name resolution service, such as
   DNS, to find an address for that origin server. If the port
   subcomponent is empty or not given, TCP port 80 (the reserved port
   for WWW services) is the default."

-Ekr



> Now given the text you propose above, I actually assume that the text I
> just cited will be removed but the whole document is written with this
> assumption and therefore there are a couple more places where wording
> probably needs to change.
>
> I do understand well the problem and that 443 is used in practice.
> However, to match reality I would rather like to see a document that
> specifies the approach of encapsulating in TLS/TCP on port 443 that is used
> today and pure TCP encapsulation for use with port 4500 only. Again i think
> that's where your proposed text is heading to but I think it needs more
> changes; in this case it would also make sense to add the TLS part back in
> the main document for 443 only.
>
> Further, I have one more question: The document is written in a way that
> allows the implementation of multiple services on the used port. Is that
> actually done in reality? If we could restrict the use of this
> encapsulation with servers that only are IKE servers (at least for the used
> port), you would actually not need the magic number anymore. I guess you
> can still have the magic number if you really want it because that makes it
> easier to distinguish valid IKE/IPSec traffic from other random traffic
> that might be send to this port but the other service running on this port
> (on other servers) does not need to know about the magic number because it
> is supposed to never see any IKe/IPSec TCP-encapsulated traffic.
>
> Does that make sense?
>
> Mirja
>
>
>
>
>> -Ekr
>>
>>
>>
>>
>> Mirja
>>
>>
>>
>> We can soften the references in the appendix to the fact that
>> other
>> ports may, in fact

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

On Thu, Apr 27, 2017 at 6:46 AM, Mirja Kühlewind <i...@kuehlewind.net>
wrote:

> One more side comment on the magic number: actually the magic number makes
> it easy for network operator to identify IKE/IPSec traffic on any port and
> block all packets that below to a flow that started with this pattern in
> the first payload packet. So if you really think you need a magic number,
> you should probably always encrypt it.
>
>
My impression was that the point of this was not to evade future operators
who are trying to block IKE, but merely to deal with the problem of
over-aggressive
middleboxes which currently block IKE, mostly accidentally. Certainly
that's how
we think of things over in WebRTC land.

-Ekr


> On 27.04.2017 15:42, Mirja Kühlewind wrote:
>
>> Hi Ekr, hi all,
>>
>> (not sure anymore which email best to reply to but I'm using this one now
>> to
>> partly also reply to others).
>>
>> See below.
>>
>> On 27.04.2017 14:51, Eric Rescorla wrote:
>>
>>>
>>>
>>> On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind <i...@kuehlewind.net
>>> <mailto:i...@kuehlewind.net>> wrote:
>>>
>>> I do see the problem you have and I understand why you selected the
>>> solution you have but that does contradict quite a bit the idea of
>>> the
>>> port registry and I don't think it's a safe and future prove
>>> solution.
>>> Even if people use this approach, I'm concern to publish it in an
>>> Standards Track RFC, but I guess that's a discussion the IESG would
>>> need
>>> to have.
>>>
>>>
>>> Mirja,
>>>
>>> I agree that this kind of port squatting is regrettable, but I also don't
>>> think it really
>>> helps to not publish RFCs that document widely used protocols because we
>>> are sad they port-squatted.
>>>
>>> I proposed a way to deal with this in an earlier e-mail. Would that be
>>> satisfactory
>>> to you. To retransmit, we add the following
>>>
>>> "Note: While port 4500 is the reserved port for this protocol, some
>>> existing
>>> implementations
>>> also use port 443. The Stream Prefix provides some mitigation against
>>> cross-protocol
>>> attacks in this case, however, the use of port 443 is NOT RECOMMENDED"
>>>
>>> We could do something similar for port 80.
>>>
>>> Would that work?
>>>
>>
>> This already is good but I think it's not enough. As Tero noted the
>> working
>> group thought that they rather specify a generic scheme which I find
>> problematic. Currently the drafts says:
>>
>> "This document leaves the selection of TCP ports up to
>> implementations.  It is suggested to use TCP port 4500, which is
>> allocated for IPsec NAT Traversal."
>>
>> Which sounds to me like an invitation to squat on any open port regardless
>> what the port is supposed to be used for (hoping that the magic number
>> would
>> avoid any collision). I don't think that a good thing to right in an RFC.
>>
>> Now given the text you propose above, I actually assume that the text I
>> just
>> cited will be removed but the whole document is written with this
>> assumption
>> and therefore there are a couple more places where wording probably needs
>> to
>> change.
>>
>> I do understand well the problem and that 443 is used in practice.
>> However,
>> to match reality I would rather like to see a document that specifies the
>> approach of encapsulating in TLS/TCP on port 443 that is used today and
>> pure
>> TCP encapsulation for use with port 4500 only. Again i think that's where
>> your proposed text is heading to but I think it needs more changes; in
>> this
>> case it would also make sense to add the TLS part back in the main
>> document
>> for 443 only.
>>
>> Further, I have one more question: The document is written in a way that
>> allows the implementation of multiple services on the used port. Is that
>> actually done in reality? If we could restrict the use of this
>> encapsulation
>> with servers that only are IKE servers (at least for the used port), you
>> would actually not need the magic number anymore. I guess you can still
>> have
>> the magic number if you really want it because that makes it easier to
>> distinguish valid IKE/IPSec traffic from other random traffic that might
>> be
>> send to this port but the other service running on this port (on 

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

On Thu, Apr 27, 2017 at 6:00 AM, Eric Rescorla <e...@rtfm.com> wrote:

>
>
> On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly <tpa...@apple.com> wrote:
>
>>
>> On Apr 26, 2017, at 12:51 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>
>> AFAICT there are two separate issues:
>>
>> - The use of 4500, which, as Tero says, we can just update the registry
>> to point to this document for.
>> - The use of 443, which seems more complicated
>>
>> WRT 443, I would assert the following facts:
>>
>> - It's not awesome that people use 443 (though understandable because of
>> overly-aggressive firewalls)
>> - People aren't going to stop using 443 (because it goes through NATs
>> well)
>>
>> Generally, I think it's more useful for documents to reflect reality,
>> even if we don't like that reality,
>> and 443 only appears in the appendix, so that seems fairly innocuous to
>> me. Perhaps we can
>> leave the 443 in the appendix with some note like:
>>
>> "Note: While port 4500 is the reserved port for this protocol, some
>> existing implementations
>> also use port 443. The Stream Prefix provides some mitigation against
>> cross-protocol
>> attacks in this case, however, the use of port 443 is NOT RECOMMENDED"
>>
>>
>> What would people think about that?
>>
>>
>> That sounds good to me. I think we may want to mention that the Stream
>> Prefix is used to distinguish from any other protocols running on port
>> 4500, etc, not really specifically to 443.
>>
>
> Good point.
>
>
> Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
>> wiggle room
>> to specify ALPN here? Or maybe a longer prefix?
>>
>>
>> The document's text regarding ALPN is in section 4:
>>
>> "Although some framing protocols do support negotiating inner protocols,
>> the stream prefix should always be used in order for implementations to be
>> as generic as possible and not rely on other framing protocols on top of
>> TCP."
>>
>> The idea is that we don't want to use TLS as a wrapper whenever possible.
>> An implementation on an IKE server may be behind a proxy or another process
>> that's terminating the TLS or raw TCP, and passing the inner stream along.
>> In that case, we wanted a standard way to put IKE and ESP in a stream, not
>> relying on an outer protocol's details.
>>
>
> I get that, but it is a bit unfortunate to be relying on this inband
> signaling.
>

Replying to myself (and in light of Benoit's comments).

The advantage of ALPN is that it would let outgoing firewall devices do
some kind
of filtering even for the TLS traffic (which of course will not be possible
if you
use non-NULL ciphers which you will have to for 1.3).

-Ekr


>
>
>> I'm perfectly open to using another prefix value; if you have a
>> suggestion for a longer value, that would be great!
>>
>
> I think I'd probably ask MT or mnot, but my instinct would be to use some
> randomly chosen string
> that started with IKETCP. E.g., IKETCP + 8ish random bytes. This just
> reduces the chance of
> any kind of accidental collision. I don't think it's a dealbreaker.
>
> -Ekr
>
>
>
>
>> Thanks,
>> Tommy
>>
>>
>> -Ekr
>>
>>
>> On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen <kivi...@iki.fi> wrote:
>>
>>> Tommy Pauly writes:
>>> > > 
>>> --
>>> > > DISCUSS:
>>> > > 
>>> --
>>> > >
>>> > > This draft suggests that ports that are assigned to other services
>>> can
>>> > > simply be used. This is not okay. If a port is assigned to a certain
>>> > > service, this service and/or the respective RFC defines how this
>>> port is
>>> > > used. Simply changing the specified behavior by requiring a check
>>> for a
>>> > > magic number cannot be done without updating the RFC that the port
>>> > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well
>>> as
>>> > > the IANA registry would need to be updated.
>>> >
>>> > At this point, the only portion of the document that mentions a port
>>> > other than 500 and 4500 is the appendix. We recommend that 4500 is
>>> > used as the port for TCP encapsulation. The IANA registry for
>>> > 4500/tcp is already a

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

On Wed, Apr 26, 2017 at 2:29 PM, Tommy Pauly <tpa...@apple.com> wrote:

>
> On Apr 26, 2017, at 12:51 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
> AFAICT there are two separate issues:
>
> - The use of 4500, which, as Tero says, we can just update the registry to
> point to this document for.
> - The use of 443, which seems more complicated
>
> WRT 443, I would assert the following facts:
>
> - It's not awesome that people use 443 (though understandable because of
> overly-aggressive firewalls)
> - People aren't going to stop using 443 (because it goes through NATs well)
>
> Generally, I think it's more useful for documents to reflect reality, even
> if we don't like that reality,
> and 443 only appears in the appendix, so that seems fairly innocuous to
> me. Perhaps we can
> leave the 443 in the appendix with some note like:
>
> "Note: While port 4500 is the reserved port for this protocol, some
> existing implementations
> also use port 443. The Stream Prefix provides some mitigation against
> cross-protocol
> attacks in this case, however, the use of port 443 is NOT RECOMMENDED"
>
>
> What would people think about that?
>
>
> That sounds good to me. I think we may want to mention that the Stream
> Prefix is used to distinguish from any other protocols running on port
> 4500, etc, not really specifically to 443.
>

Good point.


Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
> wiggle room
> to specify ALPN here? Or maybe a longer prefix?
>
>
> The document's text regarding ALPN is in section 4:
>
> "Although some framing protocols do support negotiating inner protocols,
> the stream prefix should always be used in order for implementations to be
> as generic as possible and not rely on other framing protocols on top of
> TCP."
>
> The idea is that we don't want to use TLS as a wrapper whenever possible.
> An implementation on an IKE server may be behind a proxy or another process
> that's terminating the TLS or raw TCP, and passing the inner stream along.
> In that case, we wanted a standard way to put IKE and ESP in a stream, not
> relying on an outer protocol's details.
>

I get that, but it is a bit unfortunate to be relying on this inband
signaling.



> I'm perfectly open to using another prefix value; if you have a suggestion
> for a longer value, that would be great!
>

I think I'd probably ask MT or mnot, but my instinct would be to use some
randomly chosen string
that started with IKETCP. E.g., IKETCP + 8ish random bytes. This just
reduces the chance of
any kind of accidental collision. I don't think it's a dealbreaker.

-Ekr




> Thanks,
> Tommy
>
>
> -Ekr
>
>
> On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen <kivi...@iki.fi> wrote:
>
>> Tommy Pauly writes:
>> > > 
>> --
>> > > DISCUSS:
>> > > 
>> --
>> > >
>> > > This draft suggests that ports that are assigned to other services can
>> > > simply be used. This is not okay. If a port is assigned to a certain
>> > > service, this service and/or the respective RFC defines how this port
>> is
>> > > used. Simply changing the specified behavior by requiring a check for
>> a
>> > > magic number cannot be done without updating the RFC that the port
>> > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
>> > > the IANA registry would need to be updated.
>> >
>> > At this point, the only portion of the document that mentions a port
>> > other than 500 and 4500 is the appendix. We recommend that 4500 is
>> > used as the port for TCP encapsulation. The IANA registry for
>> > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
>> > that document does not explain how TCP is to be used, so the
>> > reference should be updated to point to the document on TCP
>> > encapsulation.
>>
>> I already explained this in long email to the Joe and Paul, but
>> noticed that those emails did not go to to the IESG, so this is mostly
>> cut & paste of my previous email. This does not cover anything about
>> using any other ports, but covers the case about the IANA allocations
>> for TCP/4500 and UPD/4500.
>>
>> --
>> Paul Wouters writes:
>> > On Tue, 25 Apr 2017, Joe Touch wrote:
>> > > Every bit pattern, including those using magic numbers, is already
>> > 

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

On Thu, Apr 27, 2017 at 1:32 AM, Mirja Kühlewind 
wrote:
>
> I do see the problem you have and I understand why you selected the
> solution you have but that does contradict quite a bit the idea of the port
> registry and I don't think it's a safe and future prove solution. Even if
> people use this approach, I'm concern to publish it in an Standards Track
> RFC, but I guess that's a discussion the IESG would need to have.


Mirja,

I agree that this kind of port squatting is regrettable, but I also don't
think it really
helps to not publish RFCs that document widely used protocols because we
are sad they port-squatted.

I proposed a way to deal with this in an earlier e-mail. Would that be
satisfactory
to you. To retransmit, we add the following

"Note: While port 4500 is the reserved port for this protocol, some
existing implementations
also use port 443. The Stream Prefix provides some mitigation against
cross-protocol
attacks in this case, however, the use of port 443 is NOT RECOMMENDED"

We could do something similar for port 80.

Would that work?

-Ekr


>
>
> Mirja
>
>
>
>> We can soften the references in the appendix to the fact that other ports
>> may, in fact, be used. As for the configuration, it should state 4500 as
>> the default, but allow peers to configure something else out-of-band if
>> they want to modify behavior (which is standard even in UDP implementations
>> of IKE).
>>
>>
>>> Further, as also mentioned in the tsv-art review (Thanks Wes!), this
>>> draft does not sufficiently handle the case of TCP in TCP encapsulation.
>>> Here a copy of the tsv-art review:
>>>
>>> Reviewer: Wesley Eddy
>>> Review result: On the Right Track
>>>
>>> This document is clear and well-written.  It can easily be implemented
>>> based on the description.
>>>
>>> There are a few additional issues that should be considered with
>>> advice to implementers in Section 12 on performance considerations:
>>> 1) Invisibility of packet loss - Inner protocols that require packet
>>> losses as a signal of congestion (e.g. TCP) will have a challenge due
>>> to not being able to see any packet losses since the outer TCP will
>>> repair them (unless sending into a full outer TCP socket buffer shows
>>> up back to the inner TCP as a packet loss?).
>>>
>>
>> Yes, this is definitely true. We try to capture that with the line: "This
>> will make loss-
>>recovery of the inner TCP traffic less reactive and more prone to
>>spurious retransmission timeouts."
>>
>> However, this can certainly be expanded upon.
>>
>> 2) Nesting of ECN -  Inner TCP connections will not be able to use
>>> effectively ECN on the portion of the path covered by the outer TCP
>>> connection.
>>>
>>
>> Generally, IPsec tunnels will apply RFC 6040 for translating ECN markings
>> between inner/outer packets. Since TCP encapsulation places the inner IP
>> packets in a stream, there isn't a direct mapping.
>>
>> An implementation could try to roughly map, but it may be best to suggest
>> that the ECN markings for inner and outer packets be left separate. What is
>> your opinion?
>>
>> 3) Impact of congestion response on aggregate - The general "TCP in
>>> TCP" problem is mentioned, and is mostly appropriate for a single
>>> flow.  If an aggregate of flows is sharing the same outer TCP
>>> connection, there may be additional concerns about how the congestion
>>> response behavior impacts an aggregate of flows, since it may cause a
>>> shared delay spike even to low-rate flows rather than distributing
>>> losses proportional to per-flow throughput.
>>>
>>
>> Indeed. We can add further comments to that effect.
>>
>> 4) Additional potential for bufferbloat - Since TCP does not bound
>>> latency, some applications in the IPsec-protected aggregate could
>>> drive latency of the shared connection up and impact the aggregate of
>>> flows that may include real-time applications.  The socket buffer for
>>> the outer TCP connection might need to be limited in size to ensure
>>> some bounds?
>>>
>>
>> We can add a comment to suggest that the buffering should be limited on
>> the outer connection if possible.
>>
>>
>>> Not addressing these could lead to poor experiences in deployment, if
>>> implementations make wrong assumptions or fail to consider them.
>>>
>>
>> I do think all of these concerns go back to the overall recommendation of
>> "use direct ESP or UDP Encapsulation whenever possible". Anything to help
>> back up that point is great!
>>
>> Thanks,
>> Tommy
>>
>>>
>>> In the security considerations section, there are several RFCs on
>>> mechanisms to increase robustness to RST attacks and SYN floods that
>>> could be mentioned if it's worthwhile.
>>>
>>>
>>>
>>>
>>> ___
>>> IPsec mailing list
>>> IPsec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ipsec
>>>
>>
>>
> ___
> IPsec mailing list
> IPsec@ietf.org
> 

Re: [IPsec] Mirja Kühlewind's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS)

[Eric Rescorla]

AFAICT there are two separate issues:

- The use of 4500, which, as Tero says, we can just update the registry to
point to this document for.
- The use of 443, which seems more complicated

WRT 443, I would assert the following facts:

- It's not awesome that people use 443 (though understandable because of
overly-aggressive firewalls)
- People aren't going to stop using 443 (because it goes through NATs well)

Generally, I think it's more useful for documents to reflect reality, even
if we don't like that reality,
and 443 only appears in the appendix, so that seems fairly innocuous to me.
Perhaps we can
leave the 443 in the appendix with some note like:

"Note: While port 4500 is the reserved port for this protocol, some
existing implementations
also use port 443. The Stream Prefix provides some mitigation against
cross-protocol
attacks in this case, however, the use of port 443 is NOT RECOMMENDED"

What would people think about that?

Tommy, Tero, the stream prefix doesn't seem totally ideal. Would there be
wiggle room
to specify ALPN here? Or maybe a longer prefix?

-Ekr


On Wed, Apr 26, 2017 at 3:46 AM, Tero Kivinen  wrote:

> Tommy Pauly writes:
> > > --
> > > DISCUSS:
> > > --
> > >
> > > This draft suggests that ports that are assigned to other services can
> > > simply be used. This is not okay. If a port is assigned to a certain
> > > service, this service and/or the respective RFC defines how this port
> is
> > > used. Simply changing the specified behavior by requiring a check for a
> > > magic number cannot be done without updating the RFC that the port
> > > assignment belongs to. Also for the use of 4500/tcp RFC3948 as well as
> > > the IANA registry would need to be updated.
> >
> > At this point, the only portion of the document that mentions a port
> > other than 500 and 4500 is the appendix. We recommend that 4500 is
> > used as the port for TCP encapsulation. The IANA registry for
> > 4500/tcp is already assigned to IPSec NAT Traversal in RFC 3947;
> > that document does not explain how TCP is to be used, so the
> > reference should be updated to point to the document on TCP
> > encapsulation.
>
> I already explained this in long email to the Joe and Paul, but
> noticed that those emails did not go to to the IESG, so this is mostly
> cut & paste of my previous email. This does not cover anything about
> using any other ports, but covers the case about the IANA allocations
> for TCP/4500 and UPD/4500.
>
> --
> Paul Wouters writes:
> > On Tue, 25 Apr 2017, Joe Touch wrote:
> > > Every bit pattern, including those using magic numbers, is already
> > > owned and under the control of each assigned port. It is not
> > > appropriate for any new service to hijack that pattern as having a
> > > different meaning UNLESS explicitly updating the service on
> > > that port.
> > >
> > > A simple summary of what needs to change, in 2119-language:
> > >
> > >- this approach MUST NOT be described as applying to any
> > >  assigned number unless also updating the associated RFC
> >
> > So it should add an Updates: RFC-3947
>
> Not really. It does not update RFC3947 as it does not change the
> obsoleted protocol defined in the RFC3947. It does define way to
> extend things in IKE in similar way than RFC3948 (UDPENCAPS) does. On
> the other hand RFC3947 should have been obsoleted when we obsoleted
> IKEv1, as that document only defines how to do IKEv1 NAT traversal
> negotiation, and the IKEv2 NAT traversal negotation is described in
> main IKEv2 RFC (RFC7296).
>
> > It's a little weird. 3947 reserved TCP 4500, but did not specify how
> > to actually use TCP at all. It seems it was mostly preventatively
> > reserved.
>
> The reason RFC3947 reserved TCP/4500 was that it updated both TCP/4500
> and UDP/4500 references from individual user to the RFC3947, so that
> IETF will have change control over the ports. I.e., those ports were
> allocated before RFC3947 came out, and they were used for several
> different non-interoperable versions of the NAT traversals, which then
> evolved to the standard version we define in RFC3947. We decided to
> reassign both TCP and UDP port 4500 to RFC3947 so it would be clear
> for what use they will be used. Also we commonly reserve both TCP and
> UDP ports for same number just in case someone defines a way to run
> the protocol over other transport protocol in the future...
>
> RFC3947 does not define anything over TCP/4500. Actually RFC3947 does
> not define anything over the UDP/4500 either, it is the RFC3948 that
> does that. The RFC3947 just says, we use the format defined in the
> RFC3948 over the UDP/4500, but is silent about the TCP/4500.
>
> RFC3947 is efficiently obsoleted, as it only defines the way to do NAT
> traversal on IKEv1, and IKEv1 

Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Wed, Apr 26, 2017 at 8:13 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> On Wed, Apr 26, 2017 at 11:05 AM, Eric Rescorla <e...@rtfm.com> wrote:
> >
> >
> > On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty
> > <kathleen.moriarty.i...@gmail.com> wrote:
> >>
> >> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell <b...@nostrum.com> wrote:
> >> >
> >> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty
> >> >> <kathleen.moriarty.i...@gmail.com> wrote:
> >> >>
> >> >> Thanks for the quick response Paul, a few questions...
> >> >>
> >> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters <p...@nohats.ca>
> wrote:
> >> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> >> >>>
> >> >>>>> IIUC, the entire point of having the stream prefix is to allow the
> >> >>>>> TCP
> >> >>>>> responder to demux between this protocol, and some other protocol
> >> >>>>> that
> >> >>>>> would normally run on that port. Saying it MUST close the TCP
> >> >>>>> session
> >> >>>>> seems to completely remove that value. I assume people meant to
> >> >>>>> allow the
> >> >>>>> respondent to delegate a stream out to some other protocol handler
> >> >>>>> if the
> >> >>>>> prefix is not present?
> >> >>>>>
> >> >>>>
> >> >>>> I believe that this is because there is presumed to be no other
> >> >>>> service operating on the listening port (assuming a VPN
> >> >>>> concentrator),
> >> >>>> but that's not explicitly stated either.
> >> >>>
> >> >>>
> >> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer
> one
> >> >>> of
> >> >>> the other kinds of SSL VPNs or as the administration interface or
> >> >>> user interface.
> >> >>
> >> >> OK, sounds like I didn't help here, so the editors should propose
> text
> >> >> to address this gap.
> >> >
> >> > I think we are on the right track here, pending proposed text.
> >> >
> >> >>
> >> >>>
> >> >>>>> -- 2nd to last paragraph: "This document leaves the selection of
> TCP
> >> >>>>> ports up to implementations."
> >> >>>>> I suspect "configurable local policy" would make more sense.
> Leaving
> >> >>>>> it
> >> >>>>> up to "implementations" leaves open the chance of different
> >> >>>>> implementations making non-intersecting port choices, which
> doesn't
> >> >>>>> help
> >> >>>>> interoperability.
> >> >>>>
> >> >>>>
> >> >>>> This may go more into unexplained assumptions... the clients
> >> >>>> authorized to connect to the server would need to know the correct
> >> >>>> port to establish a session and would be given that information
> >> >>>> specific to the implementation.  With this assumption, the above
> >> >>>> should be fine... but editors/AD/WG, please correct me if I am
> wrong.
> >> >>>
> >> >>>
> >> >>> I am pretty sure what is meant is "configuration" and not
> >> >>> "implementation".
> >> >>
> >> >> Is that in response to me being wrong in my assumption or the draft
> >> >> should say configuration (I think it's the latter, but important to
> >> >> check)?
> >> >
> >> > We are probably splitting hairs on the meaning of “implementation” vs
> >> > “configuration”. (and maybe “deployment”). I was thinking of
> >> > “implementation” as being what developers do, and
> “configuring/deploying” as
> >> > what operators do. But I am aware that operators sometimes talk about
> >> > “implementing” a system.
> >> >
> >> > So my point was that I assume for purposes of interoperability that a
> >> > general purpose client or server would allow the port to be ch

Re: [IPsec] Ben Campbell's Discuss on draft-ietf-ipsecme-tcp-encaps-09: (with DISCUSS and COMMENT)

[Eric Rescorla]

On Wed, Apr 26, 2017 at 6:57 AM, Kathleen Moriarty <
kathleen.moriarty.i...@gmail.com> wrote:

> On Tue, Apr 25, 2017 at 11:54 PM, Ben Campbell  wrote:
> >
> >> On Apr 25, 2017, at 9:38 PM, Kathleen Moriarty <
> kathleen.moriarty.i...@gmail.com> wrote:
> >>
> >> Thanks for the quick response Paul, a few questions...
> >>
> >> On Tue, Apr 25, 2017 at 10:18 PM, Paul Wouters  wrote:
> >>> On Tue, 25 Apr 2017, Kathleen Moriarty wrote:
> >>>
> > IIUC, the entire point of having the stream prefix is to allow the
> TCP
> > responder to demux between this protocol, and some other protocol
> that
> > would normally run on that port. Saying it MUST close the TCP session
> > seems to completely remove that value. I assume people meant to
> allow the
> > respondent to delegate a stream out to some other protocol handler
> if the
> > prefix is not present?
> >
> 
>  I believe that this is because there is presumed to be no other
>  service operating on the listening port (assuming a VPN concentrator),
>  but that's not explicitly stated either.
> >>>
> >>>
> >>> Vendors tend to run TLS on the IKE/IPsec machine, either to offer one
> of
> >>> the other kinds of SSL VPNs or as the administration interface or
> >>> user interface.
> >>
> >> OK, sounds like I didn't help here, so the editors should propose text
> >> to address this gap.
> >
> > I think we are on the right track here, pending proposed text.
> >
> >>
> >>>
> > -- 2nd to last paragraph: "This document leaves the selection of TCP
> > ports up to implementations."
> > I suspect "configurable local policy" would make more sense. Leaving
> it
> > up to "implementations" leaves open the chance of different
> > implementations making non-intersecting port choices, which doesn't
> help
> > interoperability.
> 
> 
>  This may go more into unexplained assumptions... the clients
>  authorized to connect to the server would need to know the correct
>  port to establish a session and would be given that information
>  specific to the implementation.  With this assumption, the above
>  should be fine... but editors/AD/WG, please correct me if I am wrong.
> >>>
> >>>
> >>> I am pretty sure what is meant is "configuration" and not
> "implementation".
> >>
> >> Is that in response to me being wrong in my assumption or the draft
> >> should say configuration (I think it's the latter, but important to
> >> check)?
> >
> > We are probably splitting hairs on the meaning of “implementation” vs
> “configuration”. (and maybe “deployment”). I was thinking of
> “implementation” as being what developers do, and “configuring/deploying”
> as what operators do. But I am aware that operators sometimes talk about
> “implementing” a system.
> >
> > So my point was that I assume for purposes of interoperability that a
> general purpose client or server would allow the port to be changed in the
> field.
> >
> >>
> >>>
> > -4, first paragraph: What is the expected behavior from a peers that
> do
> > not support this spec when they receive a TCP stream with the magic
> > number on a port for some other protocol?
> 
> 
>  Maybe listing assumptions up front in the draft would help _IF_ the
>  assumption is that the listening server is a VPN concentrator that
>  wouldn't be listening for other services.
> >>>
> >>>
> >>> Support for TCP would be based on preconfiguration, so the client knows
> >>> this out-of-band. It cannot be discovered during negotiation, because
> >>> it is assumed the regular UDP ports are blocked, which is the only
> >>> reason to attempt TCP to begin with.
> >>
> >> I read the draft with this assumption in mind (see above), but this
> >> should be clarified in the document to address this question from Ben.
> >
> > Imagine a misconfigured client opening a connection to an web server on
> port 80, expecting to find a VPN service. What happens? I think that a
> consequence of the design approach to allow this to run over ports assigned
> to other protocols is that you need to consider that sort of thing.
> >
> >>>
> > - Appendix A: Doesn't the use of the NULL cipher invalidate one of
> the
> > primary reasons to use TLS? (Namely to obscure the fact that this is
> not
> > HTTP, or whatever other protocol is assigned to the port?)
> 
> 
>  Editors/AD correct me if I am wrong, but...
>  No, if TLS is used with a NULL cipher, it'll pass inspection of a
>  middle box validating the protocol.  This doesn't need to use the
>  cipher as it's negotiating the IPsec connection.
> >>>
> >>>
> >>> right, TLS happens to use encryption to get out, but it is not the
> >>> encryption of the actual IKE/IPsec protocols, which keep using their
> >>> own channel negotiations.
> >>
> >> I think clarifying this further in the draft would be helpful.
> >
> > I agree, because I’m still confused :-)
> >
> 

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Eric Rescorla]

This LGTM

On Wed, Mar 29, 2017 at 11:07 AM, Daniel Migault <
daniel.miga...@ericsson.com> wrote:

> I am planning to add this reference.Let me know if you prefer another
> reference.
>
> Rizzo, J. and T. Duong. "Here come the xor ninjas", 2011. 
> http://netifera.com/research/beast/beast_DRAFT_0621.pdf.
>
>
> Thanks for the feed back.
>
> Yours,
> Daniel
>
> On Wed, Mar 29, 2017 at 10:54 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>> I think Yoav's suggestion to cite BEAST as evidence that predictable IVs
>> are bad is a good plan.
>>
>> -Ekr
>>
>>
>> On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault <
>> daniel.miga...@ericsson.com> wrote:
>>
>>> Hi Eric,
>>>
>>> Thank you  for the review and comments. Do you have any preference on
>>> what we should cite for the chosen clear text attack?: Our local version
>>> currently refers to Security Consideration of RFC3602.
>>>
>>> The sentence in the terminology section mentioning that IV are usually
>>> unpredictable has been removed. Thanks for catching that.
>>>
>>> Yours,
>>> Daniel
>>>
>>> On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla <e...@rtfm.com> wrote:
>>>
>>>>
>>>>
>>>> On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
>>>>
>>>>>
>>>>> On 19 Mar 2017, at 19:30, Eric Rescorla <e...@rtfm.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <ynir.i...@gmail.com> wrot
>>>>> e:
>>>>>
>>>>>>
>>>>>> On 19 Mar 2017, at 16:55, Eric Rescorla <e...@rtfm.com> wrote:
>>>>>>
>>>>>> Overall:
>>>>>> I notice that you are using a construction different from that used
>>>>>> in TLS 1.3, which doesn't directly repeat nonces across associations.
>>>>>>
>>>>>> I didn't see an answer to this.
>>>>>
>>>>>
>>>>> Nonces are specified as 64-bit IV (usually counter and we are forcing
>>>>> it to be a counter) plus 32-bit salt in RFC 4106.  We saw no reason to
>>>>> change that.
>>>>>
>>>>
>>>> OK. This has a somewhat lower margin of safety than the TLS 1.3
>>>> construction, but it should be OK.
>>>>
>>>>
>>>> S 2.
>>>>>>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>>>>>>requires the IV to be unpredictable.  Deriving it directly from the
>>>>>>packet counter as described below is insecure.
>>>>>>
>>>>>> Can you provide a cite for this?
>>>>>>
>>>>>>
>>>>>> Even RFC 3602 requires that the IV be randomly generated (and for
>>>>>> good measure requires that it be unpredictable)
>>>>>>
>>>>>
>>>>> That's just a cite to a requirement, not to it being insecure. Do you
>>>>> have a citation to the relevant threat?
>>>>>
>>>>>
>>>>> We could cite BEAST. Of course BEAST depends on HTTPS, so it’s not
>>>>> really applicable - it’s harder to manipulate the first 16 bytes of the IP
>>>>> header - but these have been the recommendations for using CBC in both 
>>>>> RFCs
>>>>> and NIST documentations for years before BEAST.
>>>>>
>>>>
>>>> Sure. I just think claims like this should have a citation.
>>>>
>>>>
>>>> -Ekr
>>>>
>>>>
>>>>> In any case, note that there are
>>>>>> straightforward algorithms for deriving a CBC IV from a counter
>>>>>> (e.g., run AES in counter mode with a different key). That structure
>>>>>> would actually be suitable for GCM as well (and would address
>>>>>> my point above).
>>>>>>
>>>>>>
>>>>>> If each implementation generates a random key and uses this to
>>>>>> generate the IVs this is fine, but you still have to transmit the IV.  If
>>>>>> we derive an “IV key” from the keying material, then we don’t have to
>>>>>> transmit the IV.
>>>>>>
>>>>>
>>>>> You generate the IV from the

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Eric Rescorla]

I think Yoav's suggestion to cite BEAST as evidence that predictable IVs
are bad is a good plan.

-Ekr


On Wed, Mar 29, 2017 at 10:52 AM, Daniel Migault <
daniel.miga...@ericsson.com> wrote:

> Hi Eric,
>
> Thank you  for the review and comments. Do you have any preference on what
> we should cite for the chosen clear text attack?: Our local version
> currently refers to Security Consideration of RFC3602.
>
> The sentence in the terminology section mentioning that IV are usually
> unpredictable has been removed. Thanks for catching that.
>
> Yours,
> Daniel
>
> On Sun, Mar 19, 2017 at 2:05 PM, Eric Rescorla <e...@rtfm.com> wrote:
>
>>
>>
>> On Sun, Mar 19, 2017 at 11:52 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
>>
>>>
>>> On 19 Mar 2017, at 19:30, Eric Rescorla <e...@rtfm.com> wrote:
>>>
>>>
>>>
>>> On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <ynir.i...@gmail.com> wrote:
>>>
>>>>
>>>> On 19 Mar 2017, at 16:55, Eric Rescorla <e...@rtfm.com> wrote:
>>>>
>>>> Overall:
>>>> I notice that you are using a construction different from that used
>>>> in TLS 1.3, which doesn't directly repeat nonces across associations.
>>>>
>>>> I didn't see an answer to this.
>>>
>>>
>>> Nonces are specified as 64-bit IV (usually counter and we are forcing it
>>> to be a counter) plus 32-bit salt in RFC 4106.  We saw no reason to change
>>> that.
>>>
>>
>> OK. This has a somewhat lower margin of safety than the TLS 1.3
>> construction, but it should be OK.
>>
>>
>> S 2.
>>>>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>>>>requires the IV to be unpredictable.  Deriving it directly from the
>>>>packet counter as described below is insecure.
>>>>
>>>> Can you provide a cite for this?
>>>>
>>>>
>>>> Even RFC 3602 requires that the IV be randomly generated (and for good
>>>> measure requires that it be unpredictable)
>>>>
>>>
>>> That's just a cite to a requirement, not to it being insecure. Do you
>>> have a citation to the relevant threat?
>>>
>>>
>>> We could cite BEAST. Of course BEAST depends on HTTPS, so it’s not
>>> really applicable - it’s harder to manipulate the first 16 bytes of the IP
>>> header - but these have been the recommendations for using CBC in both RFCs
>>> and NIST documentations for years before BEAST.
>>>
>>
>> Sure. I just think claims like this should have a citation.
>>
>>
>> -Ekr
>>
>>
>>> In any case, note that there are
>>>> straightforward algorithms for deriving a CBC IV from a counter
>>>> (e.g., run AES in counter mode with a different key). That structure
>>>> would actually be suitable for GCM as well (and would address
>>>> my point above).
>>>>
>>>>
>>>> If each implementation generates a random key and uses this to generate
>>>> the IVs this is fine, but you still have to transmit the IV.  If we derive
>>>> an “IV key” from the keying material, then we don’t have to transmit the
>>>> IV.
>>>>
>>>
>>> You generate the IV from the sequence number, so you don't need to
>>> transmit the IV.
>>> That gives you an unpredictable IV without the per-packet overhead.
>>>
>>>
>>> We did bring this idea up at a WG meeting. This was not well-received
>>>> for three reasons: (1) it’s unnecessarily complicated. (2) The world is
>>>> going to AEAD. AES-CBC is the past, and (3) The perception was that saving
>>>> 8 bytes per packet was important mostly for IoT, and they don’t care about
>>>> CBC.
>>>>
>>>
>>> Sure, that's reasonable. I'm merely observing that there are designs
>>> which work for CBC.
>>>
>>>
>>> S 3.
>>>>o  IV: Initialization Vector.  Although security requirements vary,
>>>>   the common usage of this term implies that the value is
>>>>   unpredictable.
>>>>
>>>> I don't think that this is true at all. I've frequently heard of a
>>>> zero IV. It's also odd in that your IV is in fact predictable.
>>>>
>>>>
>>>> S 5.
>>>> I'm a bit surprised that you are deciding to have duplicate
>>>> code points for every algorithm rather than some sort of IKE
>>>> negotiation payload. I see that the WG is currently defining
>>>> other extensions where you take that approach.
>>>>
>>>>
>>>> See slide #7 of https://www.ietf.org/procee
>>>> dings/96/slides/slides-96-ipsecme-0.pdf
>>>>
>>>> The problem is that IKEv2 has strict rules about unexpected attributes
>>>> in the substructures of the SA payload. The sense of the room was to go
>>>> with new identifiers.
>>>>
>>>
>>> OK. Well, I agree it's ultimately a WG decision, but it doesn't seem
>>> very elegant.
>>>
>>>
>>> I was in the rough on this at first, but it was shown that every
>>> alternate negotiation mechanism had unwanted consequences.
>>>
>>> Yoav
>>>
>>>
>>
>> ___
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec
>>
>>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Eric Rescorla]

Thanks for the explanation...

-Ekr


On Sun, Mar 19, 2017 at 11:45 AM, Tommy Pauly <tpa...@apple.com> wrote:

> Some servers may support that, but some may not. These sessions are often
> used for VPN access, and we've seen cases in which a particular
> user/certificate combination is only allowed to be connected
> once-at-a-time. That makes switching more complicated. Also, since the
> recommendation is to try sending the UDP first packet at least twice, the
> amount of time required for the user to wait before the fallback would kick
> in is only on the order of a few RTT.
>
> I think if these session were more likely to be used for user-interactive,
> short-lived connections, I'd see more value in a nuanced racing algorithm.
> However, we often see IKE brought up in the background and stay associated
> for a very long time, making the protocol that wins the race more
> important, and the time to wait to establish slightly less important.
>
> Thanks,
> Tommy
>
> > On Mar 19, 2017, at 11:40 AM, Eric Rescorla <e...@rtfm.com> wrote:
> >
> > I haven't fully thought this through, but if yu can switch-hit between
> TCP
> > and UDP,
> > why can't you just race the setup between TCP and UDP and then if you
> start
> > getting packets on UDP, cut over to that.
> >
> > Maybe I'm just too influenced by ICE :)
> >
> > -Ekr
> >
> >
> > On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly <tpa...@apple.com> wrote:
> >
> >>
> >> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <e...@rtfm.com> wrote:
> >>
> >>
> >>
> >> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <ynir.i...@gmail.com> wrote:
> >>
> >>> Hi, Eric.
> >>>
> >>> On 19 Mar 2017, at 4:04, Eric Rescorla <e...@rtfm.com> wrote:
> >>>
> >>> [Now with the right address]
> >>>
> >>> I just finished reading this document. Some comments below.
> >>>
> >>>
> >>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
> >>>   sentinel value to indicate that a packet is IKE rather than ESP.
> >>>   Given that in S 3 graf 2 you have a SHOULD-level requirement
> >>>   to use typical UDP payload lengths, why not instead explicitly
> >>>   limit lengths to 15 bits and use the top bit to indicate IKE versus
> >>>   ESP. This would be slightly more efficient and seems simpler.
> >>>   I suppose that the counterargument is that IKE over UDP behaves
> >>>   differently, but in terms of implementation, that doesn't seem like
> >>>  much of an argument.
> >>>
> >>>
> >>> Another counter-argument is that we sometimes need the entire
> theoretical
> >>> length of a UDP packet. The IKE_AUTH messages typically carry a
> certificate
> >>> chain and sometimes even a CRL. And there is no way to split a
> certificate
> >>> chain over several messages. With remote access VPN you also get a CFG
> >>> payload with configuration information that can also encode an
> unbounded
> >>> amount of data. So I would not want to constrain the certificate chains
> >>> that we are able to send any more than the IP packet length already
> does
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Eric Rescorla]

I haven't fully thought this through, but if yu can switch-hit between TCP
and UDP,
why can't you just race the setup between TCP and UDP and then if you start
getting packets on UDP, cut over to that.

Maybe I'm just too influenced by ICE :)

-Ekr


On Sun, Mar 19, 2017 at 11:25 AM, Tommy Pauly <tpa...@apple.com> wrote:

>
> On Mar 19, 2017, at 6:47 AM, Eric Rescorla <e...@rtfm.com> wrote:
>
>
>
> On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <ynir.i...@gmail.com> wrote:
>
>> Hi, Eric.
>>
>> On 19 Mar 2017, at 4:04, Eric Rescorla <e...@rtfm.com> wrote:
>>
>> [Now with the right address]
>>
>> I just finished reading this document. Some comments below.
>>
>>
>> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>>sentinel value to indicate that a packet is IKE rather than ESP.
>>Given that in S 3 graf 2 you have a SHOULD-level requirement
>>to use typical UDP payload lengths, why not instead explicitly
>>limit lengths to 15 bits and use the top bit to indicate IKE versus
>>ESP. This would be slightly more efficient and seems simpler.
>>I suppose that the counterargument is that IKE over UDP behaves
>>differently, but in terms of implementation, that doesn't seem like
>>   much of an argument.
>>
>>
>> Another counter-argument is that we sometimes need the entire theoretical
>> length of a UDP packet. The IKE_AUTH messages typically carry a certificate
>> chain and sometimes even a CRL. And there is no way to split a certificate
>> chain over several messages. With remote access VPN you also get a CFG
>> payload with configuration information that can also encode an unbounded
>> amount of data. So I would not want to constrain the certificate chains
>> that we are able to send any more than the IP packet length already does.
>>
>
> OK.
>
>
>
> Early on there was a proposal to increase the length field to 4 bytes to
>> do away with these IKE limitations, but that was rejected.
>>
>> - If you're going to have a framing disambiguator, why not choose
>>   one that has higher entropy. If there is a protocol with a random
>>   start, then you are going to get some collisions with 2^48 bits.
>>
>>
>> I don’t think anyone plans to implement this on any port other than 443.
>> And on that port we’re worrying about exactly one protocol and it doesn’t
>> start with “IKETCP"
>>
>
> Fair enough.
>
>
>> - It seems like IKE associations can span TCP connections (S 6)
>>   so why not instead of doing UDP first then TCP, do happy eyeballs.
>>
>>
>> I don’t think it’s necessary to prescribe for or against this, but that
>> is what we do, and I think that is what Apple intends to do.
>>
>
> Right, but the text here actively discourages this.
> https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1
>
> "   to reduce connection setup delays. It is recommended that theinitial
> message over UDP is retransmitted at least once before falling back to TCP,
> unless the Initiator knows beforehand that the   network is likely to block
> UDP."
>
>
> There's a tradeoff here between the Happy Eyeballs approach and the
> long-term benefits of choosing one option. I'm definitely a big proponent
> of Happy Eyeballs between address families, interfaces, and protocol
> options in general. However, these IKE connections will often be long-lived
> and tunnel a large amount of traffic used for many different applications.
> Since we view tunneling over UDP as so much preferable to tunneling over
> TCP, we want to weight the race more heavily in UDP's favor. The draft does
> not specifically say that attempts over UDP are ceased once the TCP attempt
> has begun, so there is room to keep 'racing' at this point. The main point
> we wanted to get across is that UDP should be given a fair shot, since it
> should be the preference.
>
> Note that a Happy Eyeballs approach should always have one option be
> attempted first anyhow, since simultaneous racing just adds extra load to
> the network and servers.
>
> Thanks,
> Tommy
>
>
> " when TLS is used on the TCP connection, both the TCP Originator and TCP
>> Responder SHOULD allow the NULL cipher to be selected for performance
>> reasons."
>>
>> This seems like you are going to have some problems with TLS 1.3
>>
>> - If you are going to use TLS, shouldn't you be using ALPN?
>>
>>
>> The idea of using TLS (rather than just IKE on port 443) is to get past
>> firewalls and IDP that examine the TCP traf

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Eric Rescorla]

On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <ynir.i...@gmail.com> wrote:

>
> On 19 Mar 2017, at 16:55, Eric Rescorla <e...@rtfm.com> wrote:
>
> Overall:
> I notice that you are using a construction different from that used
> in TLS 1.3, which doesn't directly repeat nonces across associations.
>
> I didn't see an answer to this.


>
> S 2.
>This document does not consider AES-CBC ([RFC3602])as AES-CBC
>requires the IV to be unpredictable.  Deriving it directly from the
>packet counter as described below is insecure.
>
> Can you provide a cite for this?
>
>
> Even RFC 3602 requires that the IV be randomly generated (and for good
> measure requires that it be unpredictable)
>

That's just a cite to a requirement, not to it being insecure. Do you have
a citation to the relevant threat?


> In any case, note that there are
> straightforward algorithms for deriving a CBC IV from a counter
> (e.g., run AES in counter mode with a different key). That structure
> would actually be suitable for GCM as well (and would address
> my point above).
>
>
> If each implementation generates a random key and uses this to generate
> the IVs this is fine, but you still have to transmit the IV.  If we derive
> an “IV key” from the keying material, then we don’t have to transmit the
> IV.
>

You generate the IV from the sequence number, so you don't need to transmit
the IV.
That gives you an unpredictable IV without the per-packet overhead.


We did bring this idea up at a WG meeting. This was not well-received for
> three reasons: (1) it’s unnecessarily complicated. (2) The world is going
> to AEAD. AES-CBC is the past, and (3) The perception was that saving 8
> bytes per packet was important mostly for IoT, and they don’t care about
> CBC.
>

Sure, that's reasonable. I'm merely observing that there are designs which
work for CBC.


S 3.
>o  IV: Initialization Vector.  Although security requirements vary,
>   the common usage of this term implies that the value is
>   unpredictable.
>
> I don't think that this is true at all. I've frequently heard of a
> zero IV. It's also odd in that your IV is in fact predictable.
>
>
> S 5.
> I'm a bit surprised that you are deciding to have duplicate
> code points for every algorithm rather than some sort of IKE
> negotiation payload. I see that the WG is currently defining
> other extensions where you take that approach.
>
>
> See slide #7 of https://www.ietf.org/proceedings/96/slides/slides-
> 96-ipsecme-0.pdf
>
> The problem is that IKEv2 has strict rules about unexpected attributes in
> the substructures of the SA payload. The sense of the room was to go with
> new identifiers.
>

OK. Well, I agree it's ultimately a WG decision, but it doesn't seem very
elegant.

-Ekr


>
> Yoav
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

[Eric Rescorla]

Overall:
I notice that you are using a construction different from that used
in TLS 1.3, which doesn't directly repeat nonces across associations.

S 2.
   This document does not consider AES-CBC ([RFC3602])as AES-CBC
   requires the IV to be unpredictable.  Deriving it directly from the
   packet counter as described below is insecure.

Can you provide a cite for this? In any case, note that there are
straightforward algorithms for deriving a CBC IV from a counter
(e.g., run AES in counter mode with a different key). That structure
would actually be suitable for GCM as well (and would address
my point above).


S 3.
   o  IV: Initialization Vector.  Although security requirements vary,
  the common usage of this term implies that the value is
  unpredictable.

I don't think that this is true at all. I've frequently heard of a
zero IV. It's also odd in that your IV is in fact predictable.


S 5.
I'm a bit surprised that you are deciding to have duplicate
code points for every algorithm rather than some sort of IKE
negotiation payload. I see that the WG is currently defining
other extensions where you take that approach.


-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Eric Rescorla]

On Sat, Mar 18, 2017 at 11:29 PM, Yoav Nir <ynir.i...@gmail.com> wrote:

> Hi, Eric.
>
> On 19 Mar 2017, at 4:04, Eric Rescorla <e...@rtfm.com> wrote:
>
> [Now with the right address]
>
> I just finished reading this document. Some comments below.
>
>
> - You have a uniform 16 bit length field followed by a 4 byte all-zeros
>sentinel value to indicate that a packet is IKE rather than ESP.
>Given that in S 3 graf 2 you have a SHOULD-level requirement
>to use typical UDP payload lengths, why not instead explicitly
>limit lengths to 15 bits and use the top bit to indicate IKE versus
>ESP. This would be slightly more efficient and seems simpler.
>I suppose that the counterargument is that IKE over UDP behaves
>differently, but in terms of implementation, that doesn't seem like
>   much of an argument.
>
>
> Another counter-argument is that we sometimes need the entire theoretical
> length of a UDP packet. The IKE_AUTH messages typically carry a certificate
> chain and sometimes even a CRL. And there is no way to split a certificate
> chain over several messages. With remote access VPN you also get a CFG
> payload with configuration information that can also encode an unbounded
> amount of data. So I would not want to constrain the certificate chains
> that we are able to send any more than the IP packet length already does.
>

OK.



Early on there was a proposal to increase the length field to 4 bytes to do
> away with these IKE limitations, but that was rejected.
>
> - If you're going to have a framing disambiguator, why not choose
>   one that has higher entropy. If there is a protocol with a random
>   start, then you are going to get some collisions with 2^48 bits.
>
>
> I don’t think anyone plans to implement this on any port other than 443.
> And on that port we’re worrying about exactly one protocol and it doesn’t
> start with “IKETCP"
>

Fair enough.


> - It seems like IKE associations can span TCP connections (S 6)
>   so why not instead of doing UDP first then TCP, do happy eyeballs.
>
>
> I don’t think it’s necessary to prescribe for or against this, but that is
> what we do, and I think that is what Apple intends to do.
>

Right, but the text here actively discourages this.
https://tools.ietf.org/html/draft-ietf-ipsecme-tcp-encaps-09#section-5.1

"   to reduce connection setup delays. It is recommended that theinitial
message over UDP is retransmitted at least once before falling back to TCP,
unless the Initiator knows beforehand that the   network is likely to block
UDP."


" when TLS is used on the TCP connection, both the TCP Originator and TCP
> Responder SHOULD allow the NULL cipher to be selected for performance
> reasons."
>
> This seems like you are going to have some problems with TLS 1.3
>
> - If you are going to use TLS, shouldn't you be using ALPN?
>
>
> The idea of using TLS (rather than just IKE on port 443) is to get past
> firewalls and IDP that examine the TCP traffic to determine that it “really
> looks like HTTPS”. There was some discussion about whether this was a good
> idea or whether we should in such a case either give up or standardize some
> kind of SSL-VPN. There was no consensus to go with SSL-VPN in either this
> group or any other (there was a bar bof a few IETFs ago)
>

OK. You're still going to have a problem with 1.3...

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

[IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

[Eric Rescorla]

[Now with the right address]

I just finished reading this document. Some comments below.


- You have a uniform 16 bit length field followed by a 4 byte all-zeros
   sentinel value to indicate that a packet is IKE rather than ESP.
   Given that in S 3 graf 2 you have a SHOULD-level requirement
   to use typical UDP payload lengths, why not instead explicitly
   limit lengths to 15 bits and use the top bit to indicate IKE versus
   ESP. This would be slightly more efficient and seems simpler.
   I suppose that the counterargument is that IKE over UDP behaves
   differently, but in terms of implementation, that doesn't seem like
  much of an argument.

- If you're going to have a framing disambiguator, why not choose
  one that has higher entropy. If there is a protocol with a random
  start, then you are going to get some collisions with 2^48 bits.

- It seems like IKE associations can span TCP connections (S 6)
  so why not instead of doing UDP first then TCP, do happy eyeballs.

" when TLS is used on the TCP connection, both the TCP Originator and TCP
Responder SHOULD allow the NULL cipher to be selected for performance
reasons."

This seems like you are going to have some problems with TLS 1.3

- If you are going to use TLS, shouldn't you be using ALPN?

Feel free to tell me that these ideas have been considered and rejected. :)

-Ekr
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Re: [IPsec] Comments on draft-ietf-ipsecme-rfc4307bis

[Eric Rescorla]

I would use "complementary" rather than corresponding.

-Ekr


On Wed, Feb 15, 2017 at 9:10 AM, Yoav Nir  wrote:

> One correction
>
> On 15 Feb 2017, at 19:05, Paul Wouters  wrote:
>
> Nit: You need only one of the public values and the complementary
> private value from the other side.
>
>
> Right.
>
>
>
>
> Instead of this:
>
>exchange provides keys for the session.  If an attacker can retrieve
>one of the private numbers (a, or b) with the corresponding public
> values (g***a**,* or g***b*),
>then the attacker can compute the secret and the keys used and
>
>
> I suggest this:
>
>exchange provides keys for the session.  If an attacker can retrieve
>one of the private numbers (a or b) with the corresponding public
> values (g***b* or g***a*),
>
>then the attacker can compute the secret and the keys used and
>
>
> This way it’s more corresponding (and without the comma)
>
> Yoav
>
>
>
___
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec