On Fri, 3 Jul 2015, Yoav Nir wrote:
Seems like a limitation of DNS security. DNSSEC can authenticate that “mallory
claimed that mallory.example.com is at 8.8.8.8”, but DNSSEC does nothing to
tell me whether the claim is true. Ordinarily you gain nothing by pointing your
DNS name at a wrong IP
> On Jul 3, 2015, at 5:07 PM, Paul Wouters wrote:
>
> The problem is two different keys in two different domains in combination
> with traffic hijacking.
>
> If I steal your 8.8.8.8 route, and trick you into looking up and doing IKE to
> my domain google.nohats.ca with A record 8.8.8.8, you s
The reverse failed. It is only useful in private cloud deployments lacking
other types of authentication for publishing pubkeys (ldap, Kerberos , etc)
Sent from my iPhone
> On Jul 2, 2015, at 19:01, Yoav Nir wrote:
>
>
>> On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni wrote:
>>
>> On Thu, Jul
See my previously sent email. There is still a problem. I can explain more once
I have a real keyboard
Sent from my iPhone
> On Jul 2, 2015, at 17:29, Yoav Nir wrote:
>
>
>> On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni wrote:
>>
>> On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote:
>
>
> Host to host IPsec is very rare.
But that's what we are trying to change :)
>
> But regardless, let’s assume that the local address is 198.51.100.2. So the
> quintuple for the connection would be (UDP, 198.51.100.2:704, 192.0.2.5:53)
>
I don't think you want a tunnel per netflow, and
The problem is two different keys in two different domains in combination with
traffic hijacking.
If I steal your 8.8.8.8 route, and trick you into looking up and doing IKE to
my domain google.nohats.ca with A record 8.8.8.8, you start encrypting all
google DNS to me. That is, your applications
On Fri, Jul 03, 2015 at 01:01:43AM +0300, Yoav Nir wrote:
> > Mallory can often trigger DNS lookups for her own domain, which
> > can return IP addresses that collide with Alice's domain. How
> > is that handled?
>
> RFC 4025 and Wikipedia suggest mapping the IPSECKEY record to the address
> thr
> On Jul 3, 2015, at 12:28 AM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote:
>
>>> The hard part is the transport-mode use-case.
>>
>> If the SPD entries are specific and pre-configured, the same reasoning as
>> for VPNs applies. Things change if you want
On Thu, Jul 02, 2015 at 11:29:45PM +0300, Yoav Nir wrote:
> > The hard part is the transport-mode use-case.
>
> If the SPD entries are specific and pre-configured, the same reasoning as
> for VPNs applies. Things change if you want the SPD and PAD to be dynamic,
> such as reading them from DNS.
> On Jul 2, 2015, at 10:40 PM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote:
>
>>> At the end of the day though, IPSEC needs to apply policy to
>>> application traffic presented to the kernel (almost universally)
>>> via the socket API. The socket API giv
On Thu, Jul 02, 2015 at 10:09:46PM +0300, Yoav Nir wrote:
> > At the end of the day though, IPSEC needs to apply policy to
> > application traffic presented to the kernel (almost universally)
> > via the socket API. The socket API gives the kernel a transport
> > endpoint UDP/192.0.2.5/53, how is
> On Jul 2, 2015, at 9:22 PM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote:
>
>>> Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5
>>> supercedes or displaces Alices.
>>
>> Ah, I see the source of my confusion.
>>
>> I never think of a P
On Thu, Jul 02, 2015 at 09:02:03PM +0300, Yoav Nir wrote:
> > Alice's keys are ignored once Mallory's PAD entry for 192.0.2.5
> > supercedes or displaces Alices.
>
> Ah, I see the source of my confusion.
>
> I never think of a PAD as a table indexed by IP address. The "key" for
> the PAD is a
> On Jul 2, 2015, at 8:08 PM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote:
>
Not sure I follow. Mallory publishes
- mallory.example.com IN A 192.0.2.5
- mallory.example.com IN TLSA
>
> Mallory publishes her own TLSA record for keys
On Thu, Jul 02, 2015 at 08:04:37PM +0300, Yoav Nir wrote:
> >> Not sure I follow. Mallory publishes
> >> - mallory.example.com IN A 192.0.2.5
> >> - mallory.example.com IN TLSA
Mallory publishes her own TLSA record for keys she possesses.
> >> But there's also
> >> - alice.example.com I
> On Jul 2, 2015, at 6:48 PM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote:
>
>>> What prevents IP address hijacking (mallory.example publishes
>>> alice.example's IP address and now mallory's IPSEC keys are used
>>> to encrypt traffic to alice)?
>>
>> No
On Thu, Jul 02, 2015 at 06:40:45PM +0300, Yoav Nir wrote:
> > What prevents IP address hijacking (mallory.example publishes
> > alice.example's IP address and now mallory's IPSEC keys are used
> > to encrypt traffic to alice)?
>
> Not sure I follow. Mallory publishes
> - mallory.example.com IN
> On Jul 2, 2015, at 6:03 PM, Viktor Dukhovni wrote:
>
> On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir wrote:
>
>> The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
>> address and a DANE record. The DANE record can be used to identify the
>> certificate or raw public
On Thu, Jul 02, 2015 at 11:09:02AM -0400, Paul Wouters wrote:
> On Thu, 2 Jul 2015, Viktor Dukhovni wrote:
>
> >>The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
> >>address and a DANE record. The DANE record can be used to identify the
> >>certificate or raw public key us
On Thu, 2 Jul 2015, Viktor Dukhovni wrote:
The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
address and a DANE record. The DANE record can be used to identify the
certificate or raw public key used in IKE.
What prevents IP address hijacking (mallory.example publishes
al
On Thu, Jul 02, 2015 at 05:13:01PM +0300, Yoav Nir wrote:
> The IPsec entity will resolve this FQDN with DNSSEC, yielding both an IP
> address and a DANE record. The DANE record can be used to identify the
> certificate or raw public key used in IKE.
What prevents IP address hijacking (mallory.ex
Hi
I see that our milestones still contain a DANE with IPsec document, although
the WG has not yet discussed or adopted such a document.
There is one proposed document (draft-osterweil-dane-ipsec). That one ties DANE
to opportunistic encryption. While interesting, I think we need a far more
ba
22 matches
Mail list logo
