|
Hallvard,
Authmeth-16 is no longer using the term "graceful closure". I believe this issue is now adequately resolved. Please let me know if you disagree.
I don't recall Kurt requesting text about ciphersuite renegotiations and channel bindings in the recent past. If he is still looking for something in this area, I'd appreciate some suggestions from him ASAP.
Roger
>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 10/13/05 3:19 pm >>>
Roger Harrison writes:
>>>>>> Hallvard B Furuseth <h.b.furuseth@usit.uio.no> 09/22/05 4:26 pm >>>
>>>>> 3.1.4. Discovery of Resultant Security Level
>>>> (...)
>>>> The server too can close the connection. I don't remember what's the
>>>> use of such a def what the server can do.
>>>
>>> In reviewing [Protocol] section 4.13.3.1, I believe that this is
>>> adequately covered there. I have deleted the last sentence of this
>>> paragraph.
>>
>> You seem to be reading an old [Protocol] draft. Protocol$,1rq(B31 does not
>> mention graceful TLS closure at all. Protocol$,1rq(B31 StartTLS is section
>> 4.14, not 4.13.
>>
>> If I remember correctly, it was decided some time ago to move several
>> protocol$,1rq(Blike issues involving TLS from [protocol] to [authmeth].
>> Don't remember why.
>
> In the end, we decided to keep protocol issues in [Protocol]. Section
> 4.14.3 of [Protocol] covers removal of TLS layers. The last paragraph
> explicitly allows either protocol peer to terminate the LDAP session after
> sending or receiving a TLS closure alert, so I believe this issue is
> resolved.
Just use the same terminology, not "graceful" closure. That's what I
searched [protocol] for and didn't find.
What happened to text about ciphersuite renegotiations and channel
bindings, whatever that is, which Kurt has requested sometimes?
--
Hallvard
|