Re: transaction security in the last mile - DNS

This is a discussion on Re: transaction security in the last mile - DNS ; On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote: > Diffie-Hellman is probably too expensive for key agreement (and the ECC > variants too encumbered by patents). CURVE25519 perhaps? I'm no crypto expert, but to my eyes it ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

Thread: Re: transaction security in the last mile

  1. Re: transaction security in the last mile

    On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote:
    > Diffie-Hellman is probably too expensive for key agreement (and the ECC
    > variants too encumbered by patents).


    CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice.

    Bert

    --
    http://www.PowerDNS.com Open source, database driven DNS Software
    http://netherlabs.nl Open and Closed source services

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  2. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    bert hubert writes:

    > On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote:
    >> Diffie-Hellman is probably too expensive for key agreement (and the ECC
    >> variants too encumbered by patents).

    >
    > CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice.


    d-h is very expensive to set up. it's even a tiny bit worse than tcp. it
    would, as i said at the outset, be important for both stubs and RDNS' to keep
    state. however, since it's application layer state, rather than kernel state,
    it's reasonable to consider it for an RDNS serving millions of stubs. which
    bitswizzler is used in the various one-way transforms inside the D-H is just a
    detail at this stage of the discussion.

    wrt DTLS (http://en.wikipedia.org/wiki/Datagra...Layer_Security or
    http://crypto.stanford.edu/~nagendra...dtls/dtls.html have background
    and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm
    concerned about two elements of that protocol. first, it appears that the
    handshake can be made to fail using spoofed ICMP-Unreach messages, which may
    not be a problem for most protocols, but in our case the fallback is UDP/53
    and so this is a downgrade vector. this is because the first 64 octets of
    the IP payload, which means the UDP headers and the start of the UDP payload,
    do not include the randomized bits (so, DTLS' nonce is not within ICMP's
    nonce). second, and less troubling, DTLS has message secrecy as a goal,
    which is a red herring that will cause huge debates if we try to standardize
    on DTLS for stub/RDNS transactions.

    i'd like it very much if a DTLS expert could show me how the initial handshake
    messages put highly random content into the part of the IP datagram that must
    be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS
    will fallback to UDP/53 on DTLS failure means that some other handshake will
    have to be designed to carry the D-H exchange.
    --
    Paul Vixie

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  3. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    Paul Vixie wrote:
    > [ Moderators note: Post was moderated, either because it was posted by
    > a non-subscriber, or because it was over 20K.
    > With the massive amount of spam, it is easy to miss and therefore
    > delete relevant posts by non-subscribers.
    > Please fix your subscription addresses. ]
    >
    > bert hubert writes:
    >
    >> On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote:
    >>> Diffie-Hellman is probably too expensive for key agreement (and the ECC
    >>> variants too encumbered by patents).

    >> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice.

    >
    > d-h is very expensive to set up. it's even a tiny bit worse than tcp. it
    > would, as i said at the outset, be important for both stubs and RDNS' to keep
    > state. however, since it's application layer state, rather than kernel state,
    > it's reasonable to consider it for an RDNS serving millions of stubs. which
    > bitswizzler is used in the various one-way transforms inside the D-H is just a
    > detail at this stage of the discussion.
    >
    > wrt DTLS (http://en.wikipedia.org/wiki/Datagra...Layer_Security or
    > http://crypto.stanford.edu/~nagendra...dtls/dtls.html have background
    > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm
    > concerned about two elements of that protocol. first, it appears that the
    > handshake can be made to fail using spoofed ICMP-Unreach messages, which may
    > not be a problem for most protocols, but in our case the fallback is UDP/53
    > and so this is a downgrade vector.


    Eh? If you're using DTLS you are already on UDP. Do you mean the
    fallback is to plaintext UDP? If so, why?

    > this is because the first 64 octets of
    > the IP payload, which means the UDP headers and the start of the UDP payload,
    > do not include the randomized bits (so, DTLS' nonce is not within ICMP's
    > nonce). second, and less troubling, DTLS has message secrecy as a goal,
    > which is a red herring that will cause huge debates if we try to standardize
    > on DTLS for stub/RDNS transactions.
    >
    > i'd like it very much if a DTLS expert could show me how the initial handshake
    > messages put highly random content into the part of the IP datagram that must
    > be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS
    > will fallback to UDP/53 on DTLS failure means that some other handshake will
    > have to be designed to carry the D-H exchange.



    --
    http://www.apache-ssl.org/ben.html http://www.links.org/

    "There is no limit to what a man can do or how far he can go if he
    doesn't mind who gets the credit." - Robert Woodruff

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  4. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    > > ... i'm concerned about two elements of that protocol. first, it
    > > appears that the handshake can be made to fail using spoofed
    > > ICMP-Unreach messages, which may not be a problem for most protocols,
    > > but in our case the fallback is UDP/53 and so this is a downgrade
    > > vector.

    >
    > Eh? If you're using DTLS you are already on UDP. Do you mean the
    > fallback is to plaintext UDP? If so, why?


    in my deployment scenario, we have hundreds of millions of stubs talking to
    millions of RDNS', and if we require preshared keys we lose, and if we
    require changes to the DHCP lease options we lose, and if we require that a
    stub user know whether to expect a given RDNS to support DTLS or not we
    lose.

    therefore, whatever new stub/RDNS protocol we put in will have to be
    opportunistic, such that if it works it gets used and if it doesn't get
    used then cleartext UDP/53 gets used. therefore, there must not be a
    trivial way to make the protocol negotiation fail, forcing fallback, or
    else we've got ourselves a downgrade attack vector (like in EDNS, though
    please note, i do not regard this as a failing of EDNS.)

    if DTLS can be forced to fail by sending well timed trivially spoofed ICMP,
    then it's no protection over what the stub will fall back to.

    > All of your possible roads appear to me to be susceptible to [MiTM]
    > attacks. If we're going to fix this, let's fix it properly.


    i think hotel-in-the-middle and provider-in-the-middle are inevitable, for
    economic reasons (NXDOMAIN remapping) and technical ones (as told here by
    KRE this morning, involving IPv4 longevity measures.) there's a credible
    "first-meeting" trust model, like in SSH, where the identities and secrets
    of the parties are established at some high cost when they first meet, after
    which any change in those identities or secrets only at some higher cost, by
    which these MiTM "attacks" would be much harder to launch.

    however, i did say that my list was paltry, and if you have a suggestion,
    i'd be grateful to you for sharing it.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  5. Re: transaction security in the last mile

    * Paul Vixie:

    > wrt DTLS (http://en.wikipedia.org/wiki/Datagra...Layer_Security or
    > http://crypto.stanford.edu/~nagendra...dtls/dtls.html have background
    > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm
    > concerned about two elements of that protocol. first, it appears that the
    > handshake can be made to fail using spoofed ICMP-Unreach messages, which may
    > not be a problem for most protocols, but in our case the fallback is UDP/53
    > and so this is a downgrade vector.


    You don't downgrade. There's a place from which you get your DNS
    resolvers, and that place tells you to use the new protocol.

    > second, and less troubling, DTLS has message secrecy as a goal, which
    > is a red herring that will cause huge debates if we try to standardize
    > on DTLS for stub/RDNS transactions.


    Hmm. I fear we may need message secrecy to get clean resolutions (or
    any data at all). However, DTLS also supports the NULL cipher.

    BTW, there's a strange footer at the end of your messages, see
    . I don't know if it
    is intended.

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  6. Re: transaction security in the last mile

    > > wrt DTLS ... first, it appears that the handshake can be made to fail
    > > using spoofed ICMP-Unreach messages, which may not be a problem for
    > > most protocols, but in our case the fallback is UDP/53 and so this is a
    > > downgrade vector.

    >
    > You don't downgrade. There's a place from which you get your DNS
    > resolvers, and that place tells you to use the new protocol.


    in mail to ben laurie cc'ing this list, which the moderators have not yet
    approved, i spake thusly:

    in my deployment scenario, we have hundreds of millions of stubs
    talking to millions of RDNS', and if we require preshared keys we
    lose, and if we require changes to the DHCP lease options we lose,
    and if we require that a stub user know whether to expect a given
    RDNS to support DTLS or not we lose.

    therefore, whatever new stub/RDNS protocol we put in will have to
    be opportunistic, such that if it works it gets used and if it
    doesn't get used then cleartext UDP/53 gets used. therefore, there
    must not be a trivial way to make the protocol negotiation fail,
    forcing fallback, or else we've got ourselves a downgrade attack
    vector (like in EDNS, though please note, i do not regard this as a
    failing of EDNS.)

    if DTLS can be forced to fail by sending well timed trivially
    spoofed ICMP, then it's no protection over what the stub will fall
    back to.

    all forms of the "tells you to use the new protocol" are equally impractical
    due to the extreme size of the installed base, many of which are laptops.
    either static, or DHCP, or rendezvous, there's no way to roll out a new
    stub/RDNS fabric that lacks fallback to UDP/53 for its first 20 years of use.

    but let's turn that around -- do you agree that DTLS is subject to induced
    failure via spoofed ICMP? and, if so, can we work around it by running the
    session setup multiple times with unpredictable delays, and then caching the
    session state for some random period of time of at least several hours?

    because if so, then fallback can't be forced under those circumstances, and
    folks who don't want fallback (like you, florian) can just turn it off.

    > BTW, there's a strange footer at the end of your messages, see
    > . I don't know if it
    > is intended.


    it's not. i'm working on getting rid of that.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  7. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    Paul Vixie wrote:
    > [ Moderators note: Post was moderated, either because it was posted by
    > a non-subscriber, or because it was over 20K.
    > With the massive amount of spam, it is easy to miss and therefore
    > delete relevant posts by non-subscribers.
    > Please fix your subscription addresses. ]
    >
    > bert hubert writes:
    >
    >> On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote:
    >>> Diffie-Hellman is probably too expensive for key agreement (and the ECC
    >>> variants too encumbered by patents).

    >> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice.

    >
    > d-h is very expensive to set up. it's even a tiny bit worse than tcp. it
    > would, as i said at the outset, be important for both stubs and RDNS' to keep
    > state. however, since it's application layer state, rather than kernel state,
    > it's reasonable to consider it for an RDNS serving millions of stubs. which
    > bitswizzler is used in the various one-way transforms inside the D-H is just a
    > detail at this stage of the discussion.
    >
    > wrt DTLS (http://en.wikipedia.org/wiki/Datagra...Layer_Security or
    > http://crypto.stanford.edu/~nagendra...dtls/dtls.html have background
    > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm
    > concerned about two elements of that protocol. first, it appears that the
    > handshake can be made to fail using spoofed ICMP-Unreach messages, which may
    > not be a problem for most protocols, but in our case the fallback is UDP/53
    > and so this is a downgrade vector. this is because the first 64 octets of
    > the IP payload, which means the UDP headers and the start of the UDP payload,
    > do not include the randomized bits (so, DTLS' nonce is not within ICMP's
    > nonce). second, and less troubling, DTLS has message secrecy as a goal,
    > which is a red herring that will cause huge debates if we try to standardize
    > on DTLS for stub/RDNS transactions.


    So, I asked Eric Rescorla about this (copied) and he responds that:

    a) The ICMP unreachable message includes 64 _bits_ of the payload,
    according to RFC 792, not 64 bytes, so only the UDP header is covered,
    and so all UDP protocols have this issue.

    b) TLS and DTLS support non-confidential modes, e.g. TLS_RSA_WITH_NULL_SHA.

    > i'd like it very much if a DTLS expert could show me how the initial handshake
    > messages put highly random content into the part of the IP datagram that must
    > be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS
    > will fallback to UDP/53 on DTLS failure means that some other handshake will
    > have to be designed to carry the D-H exchange.


    If RFC 792 is wrong and you are right, then Eric informs me that DTLS
    has randomness at byte 33 in the payload (i.e. byte 41 in IP payload) so
    its covered.

    --
    http://www.apache-ssl.org/ben.html http://www.links.org/

    "There is no limit to what a man can do or how far he can go if he
    doesn't mind who gets the credit." - Robert Woodruff

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  8. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    Paul Vixie wrote:
    > [ Moderators note: Post was moderated, either because it was posted by
    > a non-subscriber, or because it was over 20K.
    > With the massive amount of spam, it is easy to miss and therefore
    > delete relevant posts by non-subscribers.
    > Please fix your subscription addresses. ]
    >
    > bert hubert writes:
    >
    >> On Fri, Jul 18, 2008 at 10:16:27PM +0200, Florian Weimer wrote:
    >>> Diffie-Hellman is probably too expensive for key agreement (and the ECC
    >>> variants too encumbered by patents).

    >> CURVE25519 perhaps? I'm no crypto expert, but to my eyes it looks nice.

    >
    > d-h is very expensive to set up. it's even a tiny bit worse than tcp. it
    > would, as i said at the outset, be important for both stubs and RDNS' to keep
    > state. however, since it's application layer state, rather than kernel state,
    > it's reasonable to consider it for an RDNS serving millions of stubs. which
    > bitswizzler is used in the various one-way transforms inside the D-H is just a
    > detail at this stage of the discussion.
    >
    > wrt DTLS (http://en.wikipedia.org/wiki/Datagra...Layer_Security or
    > http://crypto.stanford.edu/~nagendra...dtls/dtls.html have background
    > and http://tools.ietf.org/html/draft-rescorla-dtls-05 has the details), i'm
    > concerned about two elements of that protocol. first, it appears that the
    > handshake can be made to fail using spoofed ICMP-Unreach messages, which may
    > not be a problem for most protocols, but in our case the fallback is UDP/53
    > and so this is a downgrade vector. this is because the first 64 octets of
    > the IP payload, which means the UDP headers and the start of the UDP payload,
    > do not include the randomized bits (so, DTLS' nonce is not within ICMP's
    > nonce).


    BTW, the obvious (I think!) defence against this would be to operate
    DTLS over the same port, so unreachable causes complete failure.

    A downgrade attack would still potentially be possible by a MitM, but
    not by spoofing. However, you have argued elsewhere that MitM is
    actually a design feature (not sure I agree!).

    Also, a knowledgeable user should be able to insist on DTLS if they know
    the properties of their resolver.

    > second, and less troubling, DTLS has message secrecy as a goal,
    > which is a red herring that will cause huge debates if we try to standardize
    > on DTLS for stub/RDNS transactions.
    >
    > i'd like it very much if a DTLS expert could show me how the initial handshake
    > messages put highly random content into the part of the IP datagram that must
    > be present in an ICMP-Unreach message. if not, then the fact that stub/RDNS
    > will fallback to UDP/53 on DTLS failure means that some other handshake will
    > have to be designed to carry the D-H exchange.



    --
    http://www.apache-ssl.org/ben.html http://www.links.org/

    "There is no limit to what a man can do or how far he can go if he
    doesn't mind who gets the credit." - Robert Woodruff

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  9. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    > a) The ICMP unreachable message includes 64 _bits_ of the payload,
    > according to RFC 792, not 64 bytes, so only the UDP header is covered,
    > and so all UDP protocols have this issue.


    oops. my apologies, as usual, for displaying my ignorance so readily.

    so, either there can be no fallback, or there must be additional configuration
    information for the stub/RDNS relationship (beyond the RDNS's IP address; for
    example it could include a TSIG shared-secret.)

    all forms of complex setup including DTLS and TKEY are subject to the same
    spoofed-ICMP downgrade attack, if there is a fallback.

    TCP however is not subject to this kind of spoofed-ICMP induced failure. so
    perhaps i've been overthinking this. what if we use TKEY-over-TCP/53 to set
    up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter,
    and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working?

    be it noted, there is still no authentication here. the stub won't know what
    actual entity is speaking from its RDNS' IP address. but the stub could be
    certain that it was the same entity from setup onward throughout. that's my
    bugaboo.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  10. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    Paul Vixie wrote:
    >> a) The ICMP unreachable message includes 64 _bits_ of the payload,
    >> according to RFC 792, not 64 bytes, so only the UDP header is covered,
    >> and so all UDP protocols have this issue.

    >
    > oops. my apologies, as usual, for displaying my ignorance so readily.
    >
    > so, either there can be no fallback, or there must be additional configuration
    > information for the stub/RDNS relationship (beyond the RDNS's IP address; for
    > example it could include a TSIG shared-secret.)


    There can be fallback, it just has to use the same port.

    > all forms of complex setup including DTLS and TKEY are subject to the same
    > spoofed-ICMP downgrade attack, if there is a fallback.
    >
    > TCP however is not subject to this kind of spoofed-ICMP induced failure. so
    > perhaps i've been overthinking this. what if we use TKEY-over-TCP/53 to set
    > up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter,
    > and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working?


    So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53?

    > be it noted, there is still no authentication here. the stub won't know what
    > actual entity is speaking from its RDNS' IP address. but the stub could be
    > certain that it was the same entity from setup onward throughout. that's my
    > bugaboo.
    >



    --
    http://www.apache-ssl.org/ben.html http://www.links.org/

    "There is no limit to what a man can do or how far he can go if he
    doesn't mind who gets the credit." - Robert Woodruff

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  11. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    At Sun, 20 Jul 2008 15:59:25 +0000,
    Paul Vixie wrote:
    >
    > > a) The ICMP unreachable message includes 64 _bits_ of the payload,
    > > according to RFC 792, not 64 bytes, so only the UDP header is covered,
    > > and so all UDP protocols have this issue.

    >
    > oops. my apologies, as usual, for displaying my ignorance so readily.
    >
    > so, either there can be no fallback, or there must be additional configuration
    > information for the stub/RDNS relationship (beyond the RDNS's IP address; for
    > example it could include a TSIG shared-secret.)


    True. Though it could also just contain the one bit of information
    that the server will do a secure channel, right?


    > all forms of complex setup including DTLS and TKEY are subject to the same
    > spoofed-ICMP downgrade attack, if there is a fallback.
    >
    > TCP however is not subject to this kind of spoofed-ICMP induced failure.


    Because the ISN is in the first 64 bits and ISNs are hard to predict?



    > so
    > perhaps i've been overthinking this. what if we use TKEY-over-TCP/53 to set
    > up the trust relationship, and then TSIG-over-UDP/53 for queries thereafter,
    > and go back and do a new TKEY-over-TCP/53 if the TSIG ever stops working?
    >
    > be it noted, there is still no authentication here. the stub won't know what
    > actual entity is speaking from its RDNS' IP address. but the stub could be
    > certain that it was the same entity from setup onward throughout. that's my
    > bugaboo.


    Without taking a position on this particular design, I think
    there's a high order question about whether you'd like to
    authenticate the server of just get continuity, right? If
    you do, then you should do the initial key establishment via
    some public key authentication mechanism, at minimum SSH-style
    leap of faith.

    On a slightly different note, wouldn't another possibility be
    to simply ignore ICMP unreachables and rely on timeouts? As
    you know, enough firewalls and NATs block ICMP that you can't
    trust them anyway, so you have to be prepared to fall back
    to timeout. And if you were to cache the initial information
    that the server was/wasn't prepared to do the new security protocol
    (a la SSH), then you would only have timeout issues when
    you contacted a new server. (You could reprobe periodically...)

    -Ekr




    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  12. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    > So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53?


    because TKEY already exists. see RFC 2930.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  13. Re: transaction security in the last mile

    > From: Eric Rescorla
    >
    > Paul Vixie wrote:
    > > so, either there can be no fallback, or there must be additional
    > > configuration information for the stub/RDNS relationship (beyond the
    > > RDNS's IP address; for example it could include a TSIG shared-secret.)

    >
    > True. Though it could also just contain the one bit of information
    > that the server will do a secure channel, right?


    in for a dime, in for a dollar. it's not the number of new bits, it's
    that the number of new bits is zero or not.

    > > TCP however is not subject to this kind of spoofed-ICMP induced failure.

    >
    > Because the ISN is in the first 64 bits and ISNs are hard to predict?


    that's my hope, but since i thought it was bytes not bits, it could be
    that the ISN isn't in the first 64 quatloos, and TCP can be shot in the
    head by spoofed ICMP just as easily as UCP can.

    > > so perhaps i've been overthinking this. what if ...
    > >
    > > be it noted, there is still no authentication here. ...

    >
    > Without taking a position on this particular design, I think there's a
    > high order question about whether you'd like to authenticate the server
    > of just get continuity, right?


    there is no question that all i care about here is continuity, since the
    larger problem of endpoint authentication already has plenty of solutions
    and all of them have high cost and most of that high cost is due to the
    fact that there are a nonzero number of new bits of configuration data.

    > If you do, then you should do the initial key establishment via some
    > public key authentication mechanism, at minimum SSH-style leap of faith.


    i don't see microsoft or apple adopting that approach for their stubs. it
    is not reasonable to present an end user with a popup that asks them for
    input they know they are not qualified to give. so, that's why i'm not
    trying to do an SSH-style leap of faith on this.

    > On a slightly different note, wouldn't another possibility be to simply
    > ignore ICMP unreachables and rely on timeouts?


    that tends to be a kernel change rather than an application change. there
    may even be a setsockopt() that does this on some BSD-like or Linux-like
    operating systems, or on WIN32-like operating systems, but not on all of
    them. if we offer a new mechanism that's only secure after a change to
    the kernel's UDP stack, then we'll never be sure what got deployed, but we
    can safely bet that it won't be universal.

    note, i have posted a new problem statement, analysis, and proposal, under
    the name, "dns hop by hop transaction security for queries", Message-ID:
    <55957.1216574145@nsa.vix.com>. if you're not on namedroppers, i can send
    you a copy, just ask.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  14. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    Paul Vixie wrote:
    >> So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53?

    >
    > because TKEY already exists. see RFC 2930.


    I think it would be fair to say that DTLS already exists, too, and
    provides properties TKEY does not.

    --
    http://www.apache-ssl.org/ben.html http://www.links.org/

    "There is no limit to what a man can do or how far he can go if he
    doesn't mind who gets the credit." - Robert Woodruff

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  15. Re: transaction security in the last mile

    > >> So why not DTLS-over-UDP/53 falling back to plain-over-UDP/53?
    > >
    > > because TKEY already exists. see RFC 2930.

    >
    > I think it would be fair to say that DTLS already exists, too, and provides
    > properties TKEY does not.


    DTLS would be a new protocol for stubs and RDNS to speak, but i'll ask,
    features does DTLS have that TKEY doesn't have and do we need those?

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  16. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    At Sun, 20 Jul 2008 18:43:10 +0000,
    Paul Vixie wrote:
    >
    > > From: Eric Rescorla
    > >
    > > Paul Vixie wrote:
    > > > so, either there can be no fallback, or there must be additional
    > > > configuration information for the stub/RDNS relationship (beyond the
    > > > RDNS's IP address; for example it could include a TSIG shared-secret.)

    > >
    > > True. Though it could also just contain the one bit of information
    > > that the server will do a secure channel, right?

    >
    > in for a dime, in for a dollar. it's not the number of new bits, it's
    > that the number of new bits is zero or not.


    Well, I agree that there's a qualitative difference between 0 and 1,
    but I think there's still a pretty big difference between 1 and 160.


    > > If you do, then you should do the initial key establishment via some
    > > public key authentication mechanism, at minimum SSH-style leap of faith.

    >
    > i don't see microsoft or apple adopting that approach for their stubs. it
    > is not reasonable to present an end user with a popup that asks them for
    > input they know they are not qualified to give. so, that's why i'm not
    > trying to do an SSH-style leap of faith on this.


    So, I'm not saying that l-o-f will necessarily work here, but
    I don't think it's necessary to prompt the user. Rather, you
    can just accept the first key you see...


    > > On a slightly different note, wouldn't another possibility be to simply
    > > ignore ICMP unreachables and rely on timeouts?

    >
    > that tends to be a kernel change rather than an application change. there
    > may even be a setsockopt() that does this on some BSD-like or Linux-like
    > operating systems, or on WIN32-like operating systems, but not on all of
    > them. if we offer a new mechanism that's only secure after a change to
    > the kernel's UDP stack, then we'll never be sure what got deployed, but we
    > can safely bet that it won't be universal.


    Maybe I'm missing something, but why do you need to change the kernel?
    As I recall, UDP sockets, unlike TCP sockets, don't die just because
    an ICMP message is received. Can't the application just ignore
    the error?

    -Ekr

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  17. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    > From: Eric Rescorla
    >
    > ... Rather, you can just accept the first key you see...


    yes, that's what i'm proposing. we're ensuring identity continuity between
    the entity who could hear and speak from an IP at session initialization
    time and the entity who can later transmit responses from that IP.

    > Maybe I'm missing something, but why do you need to change the kernel?
    > As I recall, UDP sockets, unlike TCP sockets, don't die just because an
    > ICMP message is received. Can't the application just ignore the error?


    if the socket is connected, then read() will show an error if an ICMP
    arrives that was putatively due to a previous write(). it's a mess. yes,
    you can ignore all ICMP-causable errors from read() or write() (or sendto()
    or recvfrom(), etc). or you can just not bother to connect() the socket
    in which case you should never see ICMP-causable errno values. but i'm
    only speaking from a BSD sockets perspective, i don't know how STREAMS does
    it, or WIN32 sockets, or linux sockets, or embedded system sockets. is it
    safe to design with application-layer ignore-ICMP as an implementation
    requirement? (i really don't know if these errors are ever sticky on some
    platforms.)

    ignoring ICMP during TKEY is testable, but is not necessary for
    interoperability, so it's a strange kind of requirement to specify. but
    if it means we could forget the TCP requirement for TKEY, it means we were
    even closer to already having a working solution than i'd thought we were.

    note, we're already designing with the assumption that ICMP redirect will
    be ignored by the kernel, since that kind of spoofing has already been done
    and unlike ARP spoofing it's a spoofable protocol element we could afford
    to declare to be a bad idea in general and stop honouring it, which we did.

    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  18. Re: transaction security in the last mile

    [ Moderators note: Post was moderated, either because it was posted by
    a non-subscriber, or because it was over 20K.
    With the massive amount of spam, it is easy to miss and therefore
    delete relevant posts by non-subscribers.
    Please fix your subscription addresses. ]

    Eric Rescorla wrote:
    > At Sun, 20 Jul 2008 18:43:10 +0000,
    > Paul Vixie wrote:
    >>> From: Eric Rescorla
    >>>
    >>> Paul Vixie wrote:
    >>>> so, either there can be no fallback, or there must be additional
    >>>> configuration information for the stub/RDNS relationship (beyond the
    >>>> RDNS's IP address; for example it could include a TSIG shared-secret.)
    >>> True. Though it could also just contain the one bit of information
    >>> that the server will do a secure channel, right?

    >> in for a dime, in for a dollar. it's not the number of new bits, it's
    >> that the number of new bits is zero or not.

    >
    > Well, I agree that there's a qualitative difference between 0 and 1,
    > but I think there's still a pretty big difference between 1 and 160.
    >
    >
    >>> If you do, then you should do the initial key establishment via some
    >>> public key authentication mechanism, at minimum SSH-style leap of faith.

    >> i don't see microsoft or apple adopting that approach for their stubs. it
    >> is not reasonable to present an end user with a popup that asks them for
    >> input they know they are not qualified to give. so, that's why i'm not
    >> trying to do an SSH-style leap of faith on this.

    >
    > So, I'm not saying that l-o-f will necessarily work here, but
    > I don't think it's necessary to prompt the user. Rather, you
    > can just accept the first key you see...


    And prompt them when it changes?

    --
    http://www.apache-ssl.org/ben.html http://www.links.org/

    "There is no limit to what a man can do or how far he can go if he
    doesn't mind who gets the credit." - Robert Woodruff

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  19. Re: transaction security in the last mile

    At Mon, 21 Jul 2008 05:44:25 +0100,
    Ben Laurie wrote:
    >
    > Eric Rescorla wrote:
    > > At Sun, 20 Jul 2008 18:43:10 +0000,
    > > Paul Vixie wrote:
    > >>> From: Eric Rescorla
    > >>>
    > >>> Paul Vixie wrote:
    > >>>> so, either there can be no fallback, or there must be additional
    > >>>> configuration information for the stub/RDNS relationship (beyond the
    > >>>> RDNS's IP address; for example it could include a TSIG shared-secret.)
    > >>> True. Though it could also just contain the one bit of information
    > >>> that the server will do a secure channel, right?
    > >> in for a dime, in for a dollar. it's not the number of new bits, it's
    > >> that the number of new bits is zero or not.

    > >
    > > Well, I agree that there's a qualitative difference between 0 and 1,
    > > but I think there's still a pretty big difference between 1 and 160.
    > >
    > >
    > >>> If you do, then you should do the initial key establishment via some
    > >>> public key authentication mechanism, at minimum SSH-style leap of faith.
    > >> i don't see microsoft or apple adopting that approach for their stubs. it
    > >> is not reasonable to present an end user with a popup that asks them for
    > >> input they know they are not qualified to give. so, that's why i'm not
    > >> trying to do an SSH-style leap of faith on this.

    > >
    > > So, I'm not saying that l-o-f will necessarily work here, but
    > > I don't think it's necessary to prompt the user. Rather, you
    > > can just accept the first key you see...

    >
    > And prompt them when it changes?


    Good question. Probably retry via the original channel. I agree it's
    not a real adequate answer...

    -Ekr

    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


  20. Re: transaction security in the last mile

    > > And prompt them when it changes?
    >
    > Good question. Probably retry via the original channel. I agree it's not
    > a real adequate answer...


    in Message-ID: <55957.1216574145@nsa.vix.com> which is the top of the thread
    whose subject is "dns hop by hop transaction security for queries", i wrote:

    ... if at least one TSIG signed query transaction succeeds to a
    responder, and then later transactions fail with TSIG errors
    (BADSIG) then TKEY over TCP/53 should be repeated. if no TSIG
    signed query ever succeeds, then after some small number of
    retries, the TKEY should be discarded and no longer used. ...

    in case this wasn't clear, there is no great answer, but my proposal is that
    if a key stops working, you renegotiate a new key with whoever now operates
    the internet radio station at the address you're trying to use as your RDNS.

    this points up an obvious but inevitable and necessary weakness, which is
    that an on-path MiTM can insert himself into your trust with no barriers.
    i'm not worried about this, since off-path IP spoofing attacks are the
    problem i'm trying to solve, and on-path MiTM already has so many non-DNS
    powers that i really think anyone worried about on-path MiTM is already
    going to be using one of the authenticated protocols like DNSSEC, SIG(0),
    GSS-TSIG, or some kind of VPN.


    --
    This message has been scanned for viruses and
    dangerous content by MailScanner, and is
    believed to be clean.


    --
    to unsubscribe send a message to namedroppers-request@ops.ietf.org with
    the word 'unsubscribe' in a single line as the message text body.
    archive:


+ Reply to Thread
Page 1 of 2 1 2 LastLast