Re: [TLS] [Syslog] Missing dead peer detection in DTLS

[Michael Tuexen <[e-mail]>]

Hi Tom,

understood. Thanks for the clarification.

Best regards
Michael

On Aug 2, 2009, at 11:11 AM, tom.petch wrote:

> Reply inline, twice
>
> Tom Petch
>
> ----- Original Message -----
> From: "Michael Tuexen" <[e-mail]>
> To: "tom.petch" <[e-mail]>
> Sent: Thursday, July 30, 2009 5:24 PM
>
> a question in-line.
>
> Michael
>
> On Jul 30, 2009, at 11:44 AM, tom.petch wrote:
>
>> Gerhard
>>
>> Thank you for pointing this out; it had escaped me.
>>
>> What I had thought though was that the lack of flow control with
>> DTLS over UDP
>> is a problem, and that the lack of this with syslog over UDP led the
>> syslog RFC
>> [RFC5424] to make syslog over TLS the RECOMMENDED transport, not, as
>> might be
>> expected, syslog over UDP.
>
> So I think it is actually congestion control what you are looking
> for, which is provided by TCP when using SYSLOG/TLS/TCP/IP, right?
>
> <tp>
> For myself, no, I was not looking for or caring about congestion  
> control, rather
> security.
>
> But when the syslog I-D got to the IESG, they did care about  
> congestion, and so
> the syslog I-D was modified to make syslog over TLS the RECOMMENDED  
> transport,
> not because it might or might not improve security but because it
> offered congestion control, which UDP by itself does not.
> </tp>
>>
>> This in turn led me to expect that syslog over DTLS over UDP would
>> not be
>> acceptable to the IESG, rather that syslog over DTLS over SCTP would
>> become the
>> RECOMMENDED transport.
>
> This would mean, that
> * SYSLOG/TLS/TCP/IP
> * SYSLOG/DTLS/SCTP/IP
> * SYSLOG/DTLS/DCCP/IP
> are in principle acceptable, whereas
> * SYSLOG/DTLS/UDP/IP
> is not.
> You would (from the congestion control perspective) have the same
> classification when taking out the DTLS or TLS layer, right?
>
> <tp>
> I am unclear about your second sentence, but the first one, yes, I  
> would expect
> the first three to be acceptable to the IESG (which is rather  
> important if you
> want an I-D to become an RFC) and the last one not to be.  TLS (by  
> using TCP),
> SCTP, DCCP have acceptable congestion control, DTLS and UDP do not.
>
> Tom Petch
>
>> So; several thoughts.
>>
>> This is an update to the extensions RFC, RFC4366, which itself is
>> being updated
>> by the TLS working group (hence my addition of them to the list) and
>> I would
>> much rather have one extensions RFC rather than several.  This is a
>> good concept
>> and fills a need; perhaps the TLS working group would take this on.
>>
>> Flow control remains an issue which I do not think that this  
>> extension
>> addresses.
>>
>> Is this a security exposure? or just, like syslog over UDP, an
>> inconvenient
>> truth?
>>
>> The petch-gerhards draft allows the recipient of the unidirectional
>> flow to
>> initiate the DTLS 'connection', and so enables it to re-establish
>> the connection
>> when anything goes wrong.  This would seem an alternative to  
>> consider.
>>
>> Tom Petch
> <snip>
>
>