Re: transaction security in the last mile - DNS

This is a discussion on Re: transaction security in the last mile - DNS ; [ 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 25 of 25

Thread: Re: transaction security in the last mile

  1. 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.

    >
    > 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?


    Obviously the main one is for certificate hierarchies. Whether we need
    those is another question - they sounds like a useful optional extra to
    me :-)

    I haven't studied TKEY in detail - there may be others.

    --
    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:


  2. Re: transaction security in the last mile



    Eric Rescorla wrote:

    > At Mon, 21 Jul 2008 05:44:25 +0100,
    > Ben Laurie wrote:
    >
    >>Eric Rescorla wrote:
    >>
    >>>
    >>>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...
    >


    This is the pervasive question for almost all security schemes. How does
    a client system establish, and then "maintain", trust in a remote party
    which you (the designer, with your opinion perhaps reflected reflected
    in a "policy") assume equiped with more skills in IT security management.

    DNSEXT revisits this question because ... because what, I don't know.
    Actually the question belongs to the IT security community of experts
    which never addressed the question for what it is, i.e. pervasive for
    almost all security schemes.

    Thanks to Eric for joining the discussion and bringing it to this point.

    --

    - Thierry Moreau

    CONNOTECH Experts-conseils inc.
    9130 Place de Montgolfier
    Montreal, Qc
    Canada H2M 2A1

    Tel.: (514)385-5691
    Fax: (514)385-5900

    web site: http://www.connotech.com
    e-mail: thierry.moreau@connotech.com


    --
    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

    On Sun, 20 Jul 2008, Ben Laurie wrote:
    >
    > 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.


    It's the IP header (20 bytes) plus 64 bits (8 bytes) of the IP payload,
    which is just enough to cover the whole UDP header, or the port numbers
    and sequence number from the TCP header.

    RFC 4884 allows the amount of payload to be greater than this minimum.

    Tony.
    --
    f.anthony.n.finch http://dotat.at/
    FISHER: NORTH OR NORTHWEST 5 TO 7. ROUGH OR VERY ROUGH DECREASING MODERATE OR
    ROUGH. SHOWERS. MODERATE OR GOOD.

    --
    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

    In article , Tony Finch
    wrote:

    > On Sun, 20 Jul 2008, Ben Laurie wrote:
    > >
    > > 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.

    >
    > It's the IP header (20 bytes) plus 64 bits (8 bytes) of the IP payload,
    > which is just enough to cover the whole UDP header, or the port numbers
    > and sequence number from the TCP header.
    >
    > RFC 4884 allows the amount of payload to be greater than this minimum.


    Excuse me while I delurk (and attract a "massive amount of spam" header).

    RFC 792 seems to say "the IP header + 64 bits" rather than "20 bytes of
    IP header + 64 bits". If you could get your security stuff into an IP
    option that might be preserved in the ICMP.

    Sam
    --
    Sam Wilson
    Network Team, IT Infrastructure (formerly Computing Services)
    Information Services, The University of Edinburgh
    Edinburgh, Scotland, UK


  5. Re: transaction security in the last mile

    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. ]
    >
    >> 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.)


    Win32 sockets have problems with "ICMP port unreachable" on recvfrom
    when sendto is used on the same socket and gets a failure. After that
    you are forced to close and reopen the socket to use it again. Microsoft
    provided a workaround but from my point of view it really is a workaround.

    Danny

    --
    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 2 of 2 FirstFirst 1 2